Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: require valueFrom secrets to be marked as "allowed to be used" #127

Open
applejag opened this issue Apr 24, 2024 · 0 comments
Open

Comments

@applejag
Copy link

Taking inspiration from a very similar operator: https://github.com/mittwald/kubernetes-replicator

In that operator, they allow you to pull secrets from one namespace into another. But only if you mark the source secret with a special annotation. This is to prevent someone who has access to create Secret resources in any namespace to just pull any secrets data from any other namespace.

Applying this to ClusterSecret would be quite straight forward.

Borrowing their example from the kubernetes-replicator's README, it could look like this:

apiVersion: v1
kind: Secret
metadata:
  annotations:
    clustersecret.io/replication-allowed: "true"
    # Optional annotation to only allow its data to be synced into certain namespaces
    clustersecret.io/replication-allowed-namespaces: "my-ns-1,namespace-[0-9]*"
data:
  key1: <value>

As this would be a breaking change, this would need an opt-in. Such as via environment variable or via command-line flag.

Edge case: bypassing via multiple ClusterSecrets

One way to bypass the clustersecret.io/replication-allowed-namespaces annotation would be to use ClusterSecret to load data of the secret, create a new secret into a namespace that is allowed, and then use a second ClusterSecret to load the new secret but with the namespaces annotation removed.

To counter this, any secrets created by ClusterSecret would forcefully have the clustersecret.io/replication-allowed: "false" annotation set. No matter what annotations the ClusterSecret resource says the secret should have.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant