Simplify Security Compliance by bundling Redis-Server with the Registry container

[chuang-CE]

Currently, Redis-Server is deployed as a standalone container within the Registry stack. We should remove Redis from being its own container and instead integrate it into the Registry container from the Registry setup. This way, there will be one less pod to manage and it will significantly reduce the security surface area.

Expecting this to be about 4 hours or work, but let us know if you need more time.

[arielr-lt]

working on this

[arielr-lt]

@rohit-joy @chuang-CE, a few thoughts on this, I see some risks on this request, read on:

Redis runs as a StatefulSet for a reason: it keeps stable pod identities, persistent volumes, and ordered rollouts so the cache survives restarts. The Registry app runs as a Deployment, which is designed for stateless workloads that can be scaled up/down freely. Combining them means giving up the protections that StatefulSets provide—no stable storage, no guaranteed pod identity, no clean rolling updates—and forces Redis to inherit the Deployment’s stateless behavior. That raises the risk of data loss on restarts, makes upgrades fragile, and ties two very different lifecycle patterns together. Keeping Redis in its own StatefulSet while the app stays a Deployment is the safer design; merging them would defeat the purpose of both controllers.
Also Horizontal Pod Autoscaling (HPA) becomes tricky. Scaling the app means scaling Redis instances, which can lead to split brain or data loss unless you run Redis in pure ephemeral mode (no persistence) and accept cache wipes per replica.

It’s usually safer to keep Redis as its own pod (or move to a managed service) and tighten access controls there, rather than merging it into the application container.

Just wanted to make sure you understand some of the risks that it poses but you have the final decision on this.

[rohit-joy]

Thank you @arielr-lt. You bring up good points. I didn't realize sidekiq resumes work after Registry restarts rather than rolling back +abandoning the work. If this is true, then we have to keep Redis running separately.

For the separate instance we will need a more secure solution. To start with, we need to set up AuthN/Z for the Redis instance. Can you add this functionality? I think estimates for this would remain the same.

[jeannekitchens]

See #977