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.


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{tag}

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


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{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.


File Descriptor Limits

When performing batch operations within the Proxy, caution should be used if the batch size is large enough to cause many requests to be made to a tenants KMS. When a batch operation is performed, multiple parallel requests will be made to the tenants KMS, one for each key to wrap. If the batch size is large enough, this can cause the number of file descriptors in use on the container to be maxed out and create errors. By default on Linux the file descriptor limit is 1024 so it is best to keep the number of items in a batch operation to less than 1000 at a time.

File descriptor limit errors may also show up if you have enough concurrent traffic to a single TSP deployment. If you notice these errors in the logs and are not submitting large batches, you need to either increase the file descriptor limit on that TSP or horizontally scale and load balance the traffic.


We Are For

Trust Center

Contact Us

Follow Us