Skip to content

Sign - GCP

The sign gcp module provides a GCP KMS implementation of the sign interface so that the underlying implementation can be swapped out as a runtime dependency.

Overview

The benefit of using this module when running on GCP is that the KMS service is responsible for protecting the private key. The private key is therefore able to be used for signing without being exposed to the application.

flowchart LR
    subgraph gcpproject[GCP Project]
        ServiceAuthCentral

        subgraph KMS
            PrivateKey[Private Key]
            PublicKey[Public Key]
        end

        DataModel[(Data Model)]

        ServiceAuthCentral -- Get Client/Authorization--> DataModel

        ServiceAuthCentral -- Get Public Key--> PublicKey
        ServiceAuthCentral -- Sign --> PrivateKey
    end

    ResourceServer[Resource Server]
    ResourceServer -- JWKS --> ServiceAuthCentral

    Client -- Request Token --> ServiceAuthCentral

GCP Configuration

This implementation only supports the RSA_SIGN_PKCS1_2048_SHA256 signing algorithm. Therefore the GCP KMS key must have a purpose of Asymmetric sign and an algorithm of 2048 bit RSA - PKCS#1 v1.5 padding - SHA256 Digest.

Configuration

This module is enabled by setting the SPRING_PROFILES_ACTIVE to include the profile sign-gcp.

The following properties are used by the GCP KMS module:

Property Required Description
google.cloud.project Yes GCP Project name
sac.sign.gcp.key.ring Yes KMS Key Ring Name
sac.sign.gcp.key.name Yes KMS Key Name
sac.sign.gcp.key.location No (default: global) KMS Key Ring Location
sac.sign.gcp.cache.jwks.seconds No (default: 3600) Length of time keys are cached
sac.sign.gcp.cache.safety.multiple No (default: 24) Multiple of cache before key use

Key Rotation and Caching Considerations

Public keys are retrieved from KMS and cached to avoid redundant API calls which may result in throttling. The default amount of time for caching is 1 hour, but this can be configured using sac.sign.gcp.cache.jwks.seconds.

Due to this caching precautions must be taking when rotating keys. KMS's built in ability to create and delete keys is utilized allowing multiple keys to be active at a time. The problem arises when a new key is added, if it was immediately used for signing clients would not have the public key and would fail to verify it, therefore a period of time must elapse after it is created but before it can be used.

This period of time is configured using the sac.sign.gcp.cache.safety.multiple which has a default of 24 and is multiplied by sac.sign.gcp.cache.jwks.seconds whose default of 1 hour means that new keys will not be used for 1 day after they are created. The exception to this is when only 1 key is available, it will be use regardless of when it was created.

After this time elapses the key will be selected and used for signing and the older keys can be scheduled for deletion once any outstanding JWTs have also expired.

This procedure allows for key rotations without a production impact as long as clients are configured to not cache the JWKS response for longer than this configured