Changelog

The hash at the front of each changelog entry communicates which container hash the change was made in. There will only ever be multiple hashes in a single changelog if the underlying image was rebuilt to fix a security vulnerability.

v2.1.0

  • (6944df682377) Enables key leasing feature within the TSP. Key leasing must be enabled on a per-KMS configuration basis for leased keys to be used. By default, upgrading to this version of the TSP will have no effect until a KMS configuration is updated to allow for key leasing.

v2.0.2

  • (95ef07958b78) Fixes unwrap of certain Azure keys which do not contain an embedded version header.

v2.0.1

  • (db9325e6212a) Fix bug that caused KMS config request interval to fail if the Config Broker couldn't be reached. Now an error message will be logged but the TSP will retry the request to the Config Broker on the next planned interval.
  • (db9325e6212a) Fixes behavior of TSP if the configuration/keys of a running container are revoked within the Config Broker. In this case the TSP will fully exit as it is no longer in an valid state.

v2.0.0

  • (145bc3064d7b) Add batch unwrap and wrap endpoints to the service.
  • (145bc3064d7b) Logging improvements.
  • (145bc3064d7b) Rewrite of the TSP in Rust for performance, stability, and binary size improvements

Note

Key leasing has been pushed to a later release once event logging is completed, 2.0.0 is production ready.

v2.0.0-beta.1

  • (d92361cb9c72) Add key leasing.

Warning

Don't use in production until audit logging for leased keys is introduced, as tenant KMS logs won't reflect how the keys are actually being used.

v2.0.0-beta.0

  • (5e7a0f3012c8) Add batch unwrap and wrap endpoints to the service.

v1.4.5

  • (67d1ddefcf67) Add retries on KMS configuration decrypts to cut down on intermittent issues impacting customers.

v1.4.4

  • (dbe1b50d97cb) Add extra logging traces for configuration decrypt calls that fail.

v1.4.3

  • (eee58fccb6ad) Fixed issue with Azure versioned keys.
  • NOTICE on upgrading to this version, any Azure EDEKs should be batch decrypted and re-encrypted to avoid future issues with Azure key versioning.

v1.4.2

  • (1e018f5c32d5) Improved error handling for some classes of Azure KMS authentication errors.

v1.4.1

  • (dc7d20ab52ea) Fixed a replay security vulnerability with API calls to the Config Broker.
  • (6a4f1213f68d) Dropped base image from Alpine 3.10 to Alpine 3.9 now that it is vulnerability free and since 3.10 was sometimes causing segfault problems.

v1.4.0

  • (a5acc4786755) Added additional error codes which provide better granularity about why requests to the tenants KMS failed to succeed. These new error codes are covered in more detail within the Tenant Security Client changelog.
  • (a5acc4786755) Added a single level of retry for when a KMS cannot be reached. If the network is down or some other networking problem occurs, the Proxy will automatically attempt a single retry of the request in case the network was only temporarily unreachable.
  • (f7a276a31e92) Dropped base image from Alpine 3.10 to Alpine 3.9 now that it is vulnerability free and since 3.10 was sometimes causing segfault problems.

v1.3.0

  • (cc1a117eb269) Add caching of KMS SDK clients to prevent authorization rate limiting errors. Clients credentials will be refreshed every time configurations are pulled from the Config Broker.
  • (649aa01c5ccb) Dropped base image from Alpine 3.10 to Alpine 3.9 now that it is vulnerability free and since 3.10 was sometimes causing segfault problems.

v1.2.0

  • (73122ce2d6c1) Renamed container to tenant-security-proxy.

v1.1.0

  • Changed permissions for and moved PM2 to run within app directory.

v1.0.0

Initial release.


Versioning Policy

The Tenant Security Proxy Docker container follows normal Semver style versioning. A change in version of the Proxy means that there was some code change that occurred within the image. However, in order to follow best practices and address possible security vulnerabilities within the underlying image used in the container, we will also periodically update the base image of one or more tagged versions. This will cause the container hash to change, but the tag to remain the same.

The following policy will be used. The primary goal of this policy is to communicate changes when they occur within the Proxy, quickly address and fix vulnerabilities in current/old versions, and to avoid hosting tagged, vulnerable images within our registry.

  • Docker image tags WILL change if there are code changes within the image. This means that between 1.4.1 -> 1.4.2 there are direct code changes between the two images.
  • Docker image tags WILL change if we modify the underlying base image to move to a completely different image, i.e. alpine -> slim or something similar.
  • Docker image tags WILL NOT change if all that is changing is the base image to fix a container vulnerability.
  • Tagged Docker images will never be removed from our public registry with the exception of pre-release/beta tags (those in the form x.y.z-betaN).
  • Untagged images with or without vulnerabilities will continue to live in GCR for some time period, but may eventually be removed after a grace period.

Features

We Are For

Trust Center

Contact Us

Follow Us