Skip to content

Copy pull secrets from one namespace into one or more other namespaces

Notifications You must be signed in to change notification settings

PeterGrace/pull-secret-operator

Repository files navigation

pull-secret-operator

This operator will copy an identified dockerconfigjson-based secret from a source namespace to one or more destination namespaces

How it works

The operator sets up a series of watches on objects in the Kubernetes environment: PullSecrets and Secrets.

Given a Secret object defined in the PullSecret spec, it will copy the secret to one or more namespaces.

Example:

apiVersion: vsix.me/v1
kind: PullSecret
metadata:
  name: example-pull-secret
spec:
  source:
    namespace: jenkins
    name: dreg-registry
  targetNamespaces:
    - mayan
    - monitoring
    - pso

This example will copy the secret "dreg-registry" in the jenkins namespace, to the "mayan", "monitoring", and "pso" namespaces.

The target secrets will be stripped of annotations and labels, but will retain the same data and type as their source.
In a future release, I may expand the spec to enable selective copying of labels and annotations.

The system watches both the PullSecret and source Secret objects for changes. The operator will add or remove secrets from namespaces as the PullSecret changes, as well as update the value of the secrets if the source secrets change.

How to install

Kustomize

The kustomize folder contains a simple raw yaml deployment, generated using helm template and default values.

Helm

There is a helm chart in the charts/pull-secret-operator directory of this repository. It will deploy the CRD and a Deployment spec, as well as setup very liberal RBAC rules that give it access to read and edit all secrets in your deployment.

I may adjust the chart to have configurable namespaces enabled in the RBAC at a later date.

Speaking of RBAC, isn't this insecure?

I wrote this tool because of the following concerns:

  • I run a publicly accessible docker registry, that requires auth.
  • I don't want to litter my GitOps configuration with a ton of SOPS-encoded docker pull secrets
  • To setup or update node-wide docker pull secrets, you need to restart the dockerd/containerd daemons, which requires draining a node.
  • having a difficult and tedious process to keep pullsecrets up to date, decrease the chances that you will practice good password hygiene with regards to refreshing passwords on a schedule.

That being said, pull-secret-operator needs to have access to read and write secrets cluster-wide. If you want to limit that scope to only specific namespaces, be my guest -- the tool will operate with no permissions and will error when it cannot edit a secret. Keep an eye on the logs and only create RBAC entries for the things you want it to edit.

Currently, pull-secret-operator is engineered to fail if you feed it any secret type that isn't a dockerconfigjson. This is to attempt to reduce the chances a bad actor might exfiltrate an Opaque secret from one namespace to the other. I may someday add TLS cert support as well, but I'm on the fence about that.

Finally: the pull-secret-operator itself uses a Cluster-scoped CRD, which means that only people with appropriately cluster-scoped RBAC rules will be able to edit it. At that point,they have access to exfiltrate the secret anyway.

About

Copy pull secrets from one namespace into one or more other namespaces

Resources

Stars

Watchers

Forks

Packages

No packages published