CMK Tenant Security Proxy

The Tenant Security Proxy is a Docker container that is run within your SaaS infrastructure. This container acts as a gateway between your application and your customer's cloud security infrastructure. It has the ability to communicate with multiple cloud KMS instances from AWS, GCP, and Azure, depending on which providers your tenants are using.

Installation

The Tenant Security Proxy Docker container is hosted publicly on the IronCore Labs Docker registry. Find the latest tag available and pull down the image by running

docker pull gcr.io/ironcore-images/tenant-security-proxy:{tag}

Once successful, you should be able to see the image listed in the docker images list.

Startup

In order to successfully start the Docker container, you need to provide it with a configuration generated from the Configuration Broker. Once you have this configuration, you can run

docker run --env-file config-broker-config.env -p 32804:7777 gcr.io/ironcore-images/tenant-security-proxy:{tag}

The exposed port 32804 can be changed to a different value of your choosing if you want to run the service on a different port. If the image starts successfully, then the API service is running locally on the provided port. You'll need to provide the full domain and port where the container is running when using the Tenant Security Client Libraries.

When the container starts, it immediately attempts to make a request to the Configuration Broker to retrieve and decrypt all of the KMS configurations that were created by each of your tenants. The decrypted configurations are kept in memory only.

Every 10 minutes, the container re-fetches the list of encrypted tenant configurations from the Configuration Broker. This allows the Tenant Security Proxy to get updates on any new or changed KMS configurations for your tenants, and it handles the case where one of your tenants has revoked your access to their sensitive data.

Once the container has successfully started, it can be accessed from your applications via the Tenant Security Client, allowing your apps to encrypt and decrypt your customers' data using keys they control.

Health and Liveness Checks

The Docker container also exposes endpoints for checking liveness and health of the container. The checks are implemented based on the Kubernetes lifecycle concepts. The exposed URLs and their meaning are

  • /health: Returns a 200 status code when the container is ready to accept requests. Returns a 500 status code when the server is shutting down or is still initializing.
  • /live: Returns a 200 status code when the container is not shutting down. Returns a 500 status code when the server is shutting down.
  • /ready: Returns a 200 status code when the container is ready to accept requests. Returns a 500 status code when the server is not ready to accept requests.

The container will not report as being "ready" until it has retrieved and decrypted the initial set of tenant KMS configurations from the Configuration Broker. Each of these health endpoints are running on port 9000 within the Docker image.