mittwald/kubernetes-replicator

Namespace Whitelist for Source Objects

BWagenerGenerali opened this issue · 7 comments

BWagenerGenerali commented

Is your feature request related to a problem? Please describe.
Currently there is no way to limit where a source object can be created. This allows any tenant in a multi-tenant cluster to affect other tenants' resources.
Example:
Tenant A has a regular secret "proxy-config" containing proxy configuration. They reference this secret in a Deployment to set proxy environment variables.
Tenant B creates a source secret with the same name, the replicator would then copy the source secret's content from tenant B and merge/override tenant A's secret's content. This can potentially break tenant A's configuration or may be used to maliciously affect the deployment to use a proxy under tenant B's control.

Deploying a kubernetes-replicator for each tenant and limiting the controllers access to only each tenant's namespaces respectively using RBAC is a solution that would allow each tenant to take advantage of this controller for their purposes.

However, another use-case for the controller which is the reason we are writing this issue, is the option to centrally manage common resources and replicate them to all namespaces while limiting the namespaces from which source objects are processed. This would allow preventing a scenario described in the above example.

Describe the solution you'd like

  • an allowlist of sorts could be made configurable to allow cluster-wide operation of this controller while preventing the problematic scenario described above

Describe alternatives you've considered

  • #41 would solve this, provided that going forward CRs are the ONLY way to replicate resources. A CR based solution allows RBAC control over who can create ReplicationConfig objects. However reading the discussion in #41 it seems like an add-on solution is desired
mittwald-machine commented

There has not been any activity to this issue in the last 14 days. It will automatically be closed after 7 more days. Remove the stale label to prevent this.

mittwald-machine commented

There has not been any activity to this issue in the last 14 days. It will automatically be closed after 7 more days. Remove the stale label to prevent this.

mittwald-machine commented

There has not been any activity to this issue in the last 14 days. It will automatically be closed after 7 more days. Remove the stale label to prevent this.

mittwald-machine commented

There has not been any activity to this issue in the last 14 days. It will automatically be closed after 7 more days. Remove the stale label to prevent this.

gnunn1 commented

Bump as I'm just looking at this, in a multi-tenant cluster isn't this a serious concern? What's preventing tenants from using replicator to copy arbritary secrets into system namespaces?

I believe that replicator won't overwrite an existing secret in the target namespace, but some systems may work based on selectors versus a straight secretRef and this is potentially dangerous in those cases.