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.
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.
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.
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.
73122ce2d6c1) Renamed container to
- Changed permissions for and moved PM2 to run within
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.2there 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.
slimor 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
- 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.