This operator will copy an identified dockerconfigjson-based secret from a source namespace to one or more destination namespaces
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.
The kustomize folder contains a simple raw yaml deployment, generated using helm template and default values.
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.
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.