Secret Management

This concept explores using the Google Secret Manager for the secrets related to apps in mobile engage.

Types of Secrets

Currently we have two types of secrets listed below but by using the Google Secret Manager it would be possible to unify these into a single secret.

The contact-info-secret was introduced since it could not handle being changed/rotated. With the Google Secret Manager it’s possibel to unify this into a single secret.
api_jwt_secret

This is used to sign and verify the the contact-token as well as the client-state token.

contact_info_secret

This is used to encrypted and decrypt the contact-information stored in the client-state for web-push clients.

Storing the version

We would store the version used to sign the tokens in the token itself. This means we would need to decode the client-state token and then verify in a second step once we have the version available.

In google secret manager a secret-version is quite long and contains the project along with name of secret.

We would not need to store the full string but only the actual version since the rest can be composed in the push-service when communication with google secret manager.

So if a version is actually projects/942049623025/secrets/foo/versions/2 we would only need to store 2 in the token.

Secret Manager Structure

In the secret-manager on google we will need to create a secret per app. This secret is created by the Push Service when the app is created.

Accessing Secrets

Inside Mobile Engage

To keep the access permissions and dependencies simple we would add a sub-resource to the application resource in push service that mobile engage services can use to any version of secret.

/applications/<app-code>/secrets/<version>

The application resource would include apiSecret and apiSecretVersion in the payload to simplify the version of tokens in services like the Device-event service and Inbox service.

By other services

Services outside of Mobile Engage that need access to the secret will use google secret manager API directly to access the secrets. The secrets will be hosted in the ems-mobile-engage(-staging) project and read-only access will be granted on a service level.

Secret Caching in Services

A service like client-service would cache the secret in redis.

secrets:<app-code>:<version-id>

This format would be used when requesting a specific version from push which would be the case when the latest version is not the same as the version in the token.

App Caching in Services

A service like client-service would cache the app in redis like now. This key would be set to expire every day which means that we could keep signing the response with an old version for up to 24h hours after the rotation took place. But since we have all the other versions as well this is not an issue.

Rollout

We need to setup access to the secret manager for the me-push service. It should be admin to be allowed to fully manage the secrets.

  1. Stop rotation of the api-jwt-secret in push-service

  2. Create entries in google secret manager based on the contact-info-secret entries in push-db

  3. In case of request without specified secret-version

    • Use secret from DB for contact-token verification

    • Use contact-info-secret from DB to decrypt contact-info

    • Sign and encrypt using the latest version of the managed secret