alexellis / registry-creds Goto Github PK

Is your feature request related to a problem? Please describe.
Yes, Using a Helm Chart or similar where by a custom Service Account is required/enforced or you just need a SA with very fine grained set of RBAC permissions, it is not easily possible to use this controller without implementing/copying said imagePullSecrets from the default Service Account.

Describe all possible solutions, and which you suggest
I have/had a few ways of solving this:

• Skip Namespace watching and only watch SA's - but this causes issues with disabling the entire namespace or not.
• Watch and Apply to all Service Accounts in Namespaces - Does add a little more overhead, but allows for this feature to work
• Watch and Apply to Select Service Accounts in Namespaces - This is the solution I think will work the best, keeping overheads to a minimum and easily patchable to apply the imagePullSecrets to those that truly require them.

Describe alternatives and workarounds that you've considered
Manually copying imagePullSecrets from default sa to custom.

Additional context
Quoting from #6

The use case for this, was that I have multiple namespaces and deployments all using their own ServiceAccounts, while the original controller works with a many pull policies to one service account, my contribution allows for a Many:Many relationship of ImagePullPolicies to many ServiceAccounts.

A better example would be that a helmchart in which requires no ability to customise the ServiceAccount in which is used (enforced new SA) - I'm unable to pull images from a private repository.

With the patch/contribution applied, I'm able to patch said SA with the annotation alexellis.io/registry-creds.include=CLUSTERPULLSECRETNAME and now able to pull from said private repository.

Describe the bug
While working on PR #10, I noticed that, if we create a ServiceAccount before the CRD applied operator works fine and ServiceAccount updated as it's supposed to be, but If we are creating a ServiceAccount after the CRD applied this reconciler will not update the ServiceAccount because we are not observing ServiceAccount Events.

To Reproduce
Steps to reproduce the behavior:

Step 1 : $ eval $(minikube docker-env)

Step 2: $ make docker-build

Step 3: $ make install deploy

Step 4: $ arkade install ingress-nginx

Step 5: $ arkade install cert-manager

Step 6: $ kubectl create secret docker-registry registry-creds-secret \
  --namespace kube-system \
  --docker-username=$USERNAME \
  --docker-password=$PW \
  --docker-email=$EMAIL

Step 7: $  echo -n "apiVersion: ops.alexellis.io/v1
kind: ClusterPullSecret
metadata:
  name: dockerhub
spec:
  secretRef:
    name: registry-creds-secret
    namespace: kube-system" | k apply -f -

Step 8: $ kubectl get serviceaccounts default -oyaml  # you notice that "imagePullSecrets" added.

Step 9: $ $ kubectl create serviceaccount demo-sa 

Step 10: $ kubectl get serviceaccounts demo-sa -oyaml # you notice that "imagePullSecrets" not added, but if we'd done that before applying CRD (Step 7.), this would work fine.

Expected behavior
If we create a ServiceAccount after the CRD applied to the cluster, imagePullSecrets should be added to that ServiceAccount.

Screenshots or console output
If applicable, add screenshots to help explain your problem.

Operating system and version:
macOS 10.15.6

List all possible solutions, and your suggested option
We need to create an additional reconcile loop for the ServiceAccount that observes the events as we did already at namespace_watcher.go.

Currently if you want to exclude particular namespace(s) you need to add annotation:

kubectl annotate ns mynamespace alexellis.io/registry-creds.ignore=1

In case there are hundreds or more namespaces it requires to develop script with list of namespaces which should have that annotation added.
In addition to the above (and I think it would be more scalable solution) add white/black list to the config YAML file specifying which namespaces should or shouldn't have secrets created. Ideally with regexp so we could add i.e.: all namespaces starting with test- should have secret(s) created.

As requested in #29, investigate what would happen if we removed any prefix/suffix from secret created across namespaces.

This will be a breaking change for existing users and may affect the seed secret used as a source for the other namespaces.

Describe the bug
K8s clusters tested on ARM from v1.18 thru v1.21, x86 vanilla with the same versions - and multiple Tanzu cluster versions, this failure is also described in the PR #31 in which is fails on IKS on IBM Cloud.

When applying the manifest.yaml via the following - the system will never start up with a failed leader election:

k apply -f https://raw.githubusercontent.com/alexellis/registry-creds/master/manifest.yaml

Error from the pod:

E1210 14:13:51.146061       1 leaderelection.go:335] error initially creating leader election record: configmaps is forbidden: User "system:serviceaccount:registry-creds-system:default" cannot create resource "configmaps" in API group "" in the namespace "registry-creds-system"

To Reproduce
Create KinD cluster:

$ kind create cluster --image=kindest/node:v1.19.11@sha256:07db187ae84b4b7de440a73886f008cf903fcf5764ba8106a9fd5243d6f32729

Creating cluster "kind" ...
 ✓ Ensuring node image (kindest/node:v1.19.11) 🖼
 ✓ Preparing nodes 📦
 ✓ Writing configuration 📜
 ✓ Starting control-plane 🕹️
 ✓ Installing CNI 🔌
 ✓ Installing StorageClass 💾
Set kubectl context to "kind-kind"
You can now use your cluster with:

kubectl cluster-info --context kind-kind

Not sure what to do next? 😅  Check out https://kind.sigs.k8s.io/docs/user/quick-start/

$ kubectx kind-kind
Switched to context "kind-kind".

$ k get po -A
NAMESPACE            NAME                                         READY   STATUS    RESTARTS   AGE
kube-system          coredns-f9fd979d6-7zxdq                      1/1     Running   0          63s
kube-system          coredns-f9fd979d6-8z6xq                      1/1     Running   0          63s
kube-system          etcd-kind-control-plane                      1/1     Running   0          71s
kube-system          kindnet-bnjnl                                1/1     Running   0          63s
kube-system          kube-apiserver-kind-control-plane            1/1     Running   0          71s
kube-system          kube-controller-manager-kind-control-plane   1/1     Running   0          71s
kube-system          kube-proxy-vfd7l                             1/1     Running   0          63s
kube-system          kube-scheduler-kind-control-plane            1/1     Running   0          71s
local-path-storage   local-path-provisioner-547f784dff-mrcn8      1/1     Running   0          63s

Install reg-creds:

$ k apply -f https://raw.githubusercontent.com/alexellis/registry-creds/master/manifest.yaml
namespace/registry-creds-system created
customresourcedefinition.apiextensions.k8s.io/clusterpullsecrets.ops.alexellis.io created
role.rbac.authorization.k8s.io/registry-creds-leader-election-role created
clusterrole.rbac.authorization.k8s.io/registry-creds-registry-creds-role created
rolebinding.rbac.authorization.k8s.io/registry-creds-leader-election-rolebinding created
clusterrolebinding.rbac.authorization.k8s.io/registry-creds-registry-creds-rolebinding created
deployment.apps/registry-creds-registry-creds-controller created

$  kubens registry-creds-system
Context "kind-kind" modified.
Active namespace is "registry-creds-system".

$ k get po -w
NAME                                                        READY   STATUS              RESTARTS   AGE
registry-creds-registry-creds-controller-68468bd469-dtjxf   0/1     ContainerCreating   0          8s
registry-creds-registry-creds-controller-68468bd469-dtjxf   1/1     Running             0          12s

Check reg-creds pod logs:

$ k logs registry-creds-registry-creds-controller-68468bd469-dtjxf
2021-12-10T14:13:51.132Z	INFO	controller-runtime.metrics	metrics server is starting to listen	{"addr": ":8080"}
2021-12-10T14:13:51.133Z	INFO	setup	starting manager with the version %s and commit %s	{"0.3.0-rc4": "5883ef9ba8e72563b3c4ceee23647ed27c7713fb"}
I1210 14:13:51.133985       1 leaderelection.go:242] attempting to acquire leader lease  registry-creds-system/8bdecb1a.alexellis.io...
2021-12-10T14:13:51.134Z	INFO	controller-runtime.manager	starting metrics server	{"path": "/metrics"}
E1210 14:13:51.146061       1 leaderelection.go:335] error initially creating leader election record: configmaps is forbidden: User "system:serviceaccount:registry-creds-system:default" cannot create resource "configmaps" in API group "" in the namespace "registry-creds-system"
E1210 14:13:54.603970       1 leaderelection.go:335] error initially creating leader election record: configmaps is forbidden: User "system:serviceaccount:registry-creds-system:default" cannot create resource "configmaps" in API group "" in the namespace "registry-creds-system"
E1210 14:13:58.869250       1 leaderelection.go:335] error initially creating leader election record: configmaps is forbidden: User "system:serviceaccount:registry-creds-system:default" cannot create resource "configmaps" in API group "" in the namespace "registry-creds-system"
E1210 14:14:02.471738       1 leaderelection.go:335] error initially creating leader election record: configmaps is forbidden: User "system:serviceaccount:registry-creds-system:default" cannot create resource "configmaps" in API group "" in the namespace "registry-creds-system"
E1210 14:14:05.531691       1 leaderelection.go:335] error initially creating leader election record: configmaps is forbidden: User "system:serviceaccount:registry-creds-system:default" cannot create resource "configmaps" in API group "" in the namespace "registry-creds-system"
E1210 14:14:08.557895       1 leaderelection.go:335] error initially creating leader election record: configmaps is forbidden: User "system:serviceaccount:registry-creds-system:default" cannot create resource "configmaps" in API group "" in the namespace "registry-creds-system"
E1210 14:14:12.215142       1 leaderelection.go:335] error initially creating leader election record: configmaps is forbidden: User "system:serviceaccount:registry-creds-system:default" cannot create resource "configmaps" in API group "" in the namespace "registry-creds-system"
E1210 14:14:14.381499       1 leaderelection.go:335] error initially creating leader election record: configmaps is forbidden: User "system:serviceaccount:registry-creds-system:default" cannot create resource "configmaps" in API group "" in the namespace "registry-creds-system"
E1210 14:14:16.763812       1 leaderelection.go:335] error initially creating leader election record: configmaps is forbidden: User "system:serviceaccount:registry-creds-system:default" cannot create resource "configmaps" in API group "" in the namespace "registry-creds-system"
E1210 14:14:19.005162       1 leaderelection.go:335] error initially creating leader election record: configmaps is forbidden: User "system:serviceaccount:registry-creds-system:default" cannot create resource "configmaps" in API group "" in the namespace "registry-creds-system"

Expected behavior
The leader election to succeed and the system to run.

List all possible solutions, and your suggested option

Removing the lines:

Solves the issue instantly:

E1210 14:22:31.466596       1 leaderelection.go:335] error initially creating leader election record: configmaps is forbidden: User "system:serviceaccount:registry-creds-system:default" cannot create resource "configmaps" in API group "" in the namespace "registry-creds-system"
E1210 14:22:34.726013       1 leaderelection.go:335] error initially creating leader election record: configmaps is forbidden: User "system:serviceaccount:registry-creds-system:default" cannot create resource "configmaps" in API group "" in the namespace "registry-creds-system"
E1210 14:22:36.976019       1 leaderelection.go:335] error initially creating leader election record: configmaps is forbidden: User "system:serviceaccount:registry-creds-system:default" cannot create resource "configmaps" in API group "" in the namespace "registry-creds-system"
<!!!!! ------ kubectl edit role registry-creds-leader-election-role - executed here to remove the above lines ------- !!!!!>
I1210 14:22:39.356030       1 leaderelection.go:252] successfully acquired lease registry-creds-system/8bdecb1a.alexellis.io
2021-12-10T14:22:39.356Z	DEBUG	controller-runtime.manager.events	Normal	{"object": {"kind":"ConfigMap","namespace":"registry-creds-system","name":"8bdecb1a.alexellis.io","uid":"b1805b5f-0c0e-40a8-a555-fbc91916d2b7","apiVersion":"v1","resourceVersion":"2102"}, "reason": "LeaderElection", "message": "registry-creds-registry-creds-controller-68468bd469-dtjxf_13eadec4-12c6-44aa-8b2c-bf9107cf5df3 became leader"}
2021-12-10T14:22:39.357Z	INFO	controller-runtime.controller	Starting EventSource	{"controller": "serviceaccount", "source": "kind source: /, Kind="}
2021-12-10T14:22:39.358Z	INFO	controller-runtime.controller	Starting EventSource	{"controller": "clusterpullsecret", "source": "kind source: /, Kind="}

My comment here shows the same response as this being the fix for multiple users: #16 (comment)

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe all possible solutions, and which you suggest
A clear and concise description of what you want to happen.

Describe alternatives and workarounds that you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

I have just deployed registry-cred - by the way - thank you for this - it is really useful !

I have configured and deployed it successfully. However I have noticed that when I use the following YAML manifest:

apiVersion: ops.alexellis.io/v1
kind: ClusterPullSecret
metadata:
  name: docker-registry-1
spec:
  secretRef:
    name: docker-registry-cred
    namespace: ns1

it adds "registrycreds" to all secrets' name in each namespace and their name are:

docker-registry-1-registrycreds

Is it possible to opt out of it ?

Scanned docker image with grype.
Facing the vaularability issue.

❯ grype thirdparty-app-reg-crds
✔ Vulnerability DB [no update available]
✔ Loaded image athena-thirdparty-app-reg-crds:latest
✔ Parsed image sha256:1af2ea6f88c4c6e49b2bbdbe0d31cb781c4f748618ca9f651b6238ada0878c2c
✔ Cataloged contents 7d1168fa380f44f6050f6f8d069b8ce31c88b0407b48d49fdcfd1c96bb46f235
├── ✔ Packages [63 packages]
├── ✔ File digests [1,205 files]
├── ✔ File metadata [1,205 locations]
└── ✔ Executables [1 executables]
✔ Scanned for vulnerabilities [9 vulnerability matches]
├── by severity: 0 critical, 1 high, 2 medium, 0 low, 0 negligible (6 unknown)
└── by status: 1 fixed, 8 not-fixed, 0 ignored
[0001] WARN unable to read dynamic symbols from elf file error=no symbol section
[0001] WARN unable to read dynamic symbols from elf file error=no symbol section
[0001] WARN some package(s) are missing CPEs. This may result in missing vulnerabilities. You may autogenerate these using: --add-cpes-if-none
NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY
google.golang.org/protobuf v1.30.0 1.33.0 go-module GHSA-8r3f-844c-mc37 Medium
stdlib go1.21.3 go-module CVE-2023-45285 High
stdlib go1.21.3 go-module CVE-2023-39326 Medium
stdlib go1.21.3 go-module CVE-2024-24785 Unknown
stdlib go1.21.3 go-module CVE-2024-24784 Unknown
stdlib go1.21.3 go-module CVE-2024-24783 Unknown
stdlib go1.21.3 go-module CVE-2023-45290 Unknown
stdlib go1.21.3 go-module CVE-2023-45289 Unknown
stdlib go1.21.3 go-module CVE-2023-45288 Unknown
A newer version of grype is available for download: 0.77.0 (installed version is 0.74.5)

Solution:

• Update go version to 1.21 in go.mod file
• Update google.golang.org/protobuf v1.30.0 --> 1.33.0

Describe the bug
A clear and concise description of what the bug is.
We are upgrading from k8s 1.21 -> 1.26 soon. I recently ran a scan of packages that need to be updated/upgraded. Here are the results:

CustomResourceDefinition clusterpullsecrets.ops.alexellis.io apiextensions.k8s.io/v1beta1 apiextensions.k8s.io/v1 (1.16.0)

These api versions need to be upgraded.

To Reproduce
Steps to reproduce the behavior:
kubent {cluster}

Expected behavior
A clear and concise description of what you expected to happen.
kubent doesnt pick up any api deprecations

Are you a GitHub Sponsor (Yes/No?)
NO

Issues from sponsors get prioritised and a quicker response.

Check at: https://github.com/sponsors/alexellis

• Yes
• [X ] No

Screenshots or console output
If applicable, add screenshots to help explain your problem.

Operating system and version:

List all possible solutions, and your suggested option
I have a PR in fork that I can raise when issue gets accepted. Can tag new version

Additional context
Add any other context about the problem here.

If you use this software at work, become a sponsor.

Why? In exchange for the time you are saving, the effort you expect me to put into maintaining this and the support you'll receive. I'll leave the tier up to you.

https://github.com/sponsors/alexellis

We should add version and commit SHA to the binary just like with the inlets-operator in its Dockerfile and GH Action

Having a version printed out on start-up helps with user issues and knowing which version is being run.

Describe the bug
A clear and concise description of what the bug is.

Somehow i faced an issue with some EKS clusters where it was perfectly working before

• kubernetes 1.23.x (3 differnts minor versions)
• custom ubunutu 22.04 EKS images

To Reproduce
Steps to reproduce the behavior:

1. Deploy 0.3.2 on cluster
2. Pods will be in CrashlloopBack with the message "unable to load in-cluster config"

Expected behavior
A clear and concise description of what you expected to happen.

From what I understand the token file is needed (at least) to create lease at startup
There might be some policies (in 1.23 PSP are still there) that prevent some worload to have one by default

I worked on a fix that is just adding automountServiceAccountToken: true to the pods (PR opened)

Are you a GitHub Sponsor (Yes/No?)

• Yes
• No

Screenshots or console output
If applicable, add screenshots to help explain your problem.

Operating system and version:
Linux ubuntu 22.04

List all possible solutions, and your suggested option

Merge the PR ?

Additional context
Add any other context about the problem here.

Describe the bug
The default RBAC permissions requested in manifest.yaml (and config/rbac/) are much wider than needed. E.g. there's no need to have write permissions (create/delete/patch/update) for namespaces.

To Reproduce
Steps to reproduce the behavior:

1. kubectl apply -f https://raw.githubusercontent.com/alexellis/registry-creds/master/manifest.yaml
2. Look at the created Role and ClusterRole

Expected behavior

The default manifest only requests the minimum permissions needed to operate.

Screenshots or console output
N/A

Operating system and version:
N/A

List all possible solutions, and your suggested option
I did a combination of audit2rbac on a local kind cluster as well as some code inspection, and came up with this:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: registry-creds-leader-election-role
  namespace: registry-creds-system
rules:
- apiGroups: [""]
  resourceNames: [8bdecb1a.alexellis.io]
  resources: [configmaps]
  verbs: [create, get, patch, update]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: registry-creds-registry-creds-role
rules:
- apiGroups: [""]
  resources: [namespaces]
  verbs: [get, list, watch]
- apiGroups: [""]
  resources: [secrets]
  verbs: [create, get, list, watch]
- apiGroups: [""]
  resources: [serviceaccounts]
  verbs: [get, list, patch, update, watch]
- apiGroups: [ops.alexellis.io]
  resources: [clusterpullsecrets]
  verbs: [get, list, watch]

Additional context

I'm using these permissions locally on my cluster, and haven't observed any errors yet (I've tried creating and deleting ClusterPullSecrets). I'm happy to open a PR to change things, but I see you want an issue reported first, so here's that.

Describe the bug
Registry-creds tags become unavailable on "ghcr.io":

$ docker pull ghcr.io/alexellis/registry-creds:0.2.6
Error response from daemon: manifest unknown

$ docker pull ghcr.io/alexellis/registry-creds:0.2.7
Error response from daemon: manifest unknown

$ docker pull ghcr.io/alexellis/registry-creds:0.3.1-1
Error response from daemon: manifest unknown

To Reproduce
Try to pull some image tags which worked before

Expected behavior
Image tag pull expected to be working

Are you a GitHub Sponsor (Yes/No?) No

Describe the bug
Experiencing OOMKilled with out of memory when applying default manifest

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior

Screenshots or console output
If applicable, add screenshots to help explain your problem.

Operating system and version:

List all possible solutions, and your suggested option

• increase the default requests and Limits
• Add Helm charts where individuals can override the values.

Additional context
We don't want to download the file locally and update the manifest as we would like to keep up to date with latest changes from this manifest.

Describe the bug
on mac you cant change the $USERNAME value for some reason
so when you copy+paste the readme code it deploys using the laptops username instead of what you set

To Reproduce
Steps to reproduce the behavior:

Simon@SiMacBookPro Kubernetes % echo $USERNAME
Simon
Simon@SiMacBookPro Kubernetes % export USERNAME=si458
Simon@SiMacBookPro Kubernetes % echo $USERNAME
Simon
Simon@SiMacBookPro Kubernetes % 

Expected behavior
$USERNAME was to be set as my dockerhub user which it wasnt

Screenshots or console output

Simon@SiMacBookPro Kubernetes % echo $USERNAME
Simon
Simon@SiMacBookPro Kubernetes % export USERNAME=si458
Simon@SiMacBookPro Kubernetes % echo $USERNAME
Simon
Simon@SiMacBookPro Kubernetes % 

Operating system and version:
Mac 10.15.7

List all possible solutions, and your suggested option
change value in read to say UN instead of USERNAME

Additional context
Add any other context about the problem here.

Task

Remove pull secret reference from ServiceAccounts upon ClusterPullSecret deletion

This isn't being done at present.

@andersonnicholaskc hinted at this in #4 - however the PR is too large, this feature should be implemented as a single PR.

Describe the bug
Cannot make "registry-creds" operator work under Kubernetes 1.20.x.
The created ClusterPullSecret resource has empty fields in "secretRef" that cannot be initialized.

To Reproduce
Steps to reproduce the behavior:

1. Install Kubernetes 1.20.x
2. Install "registry-creds" operator and set ClusterPullSecret
3. Check ClusterPullSecret created, compare to one installed on earlier Kubernetes versions (e.g. 1.19.x)
4. Check controller logs

Expected behavior
ClusterPullSecret should be funny initialized, controller shouldn't have errors

Are you a GitHub Sponsor (Yes/No?)

Check at: https://github.com/sponsors/alexellis

• Yes
• No

Screenshots or console output

$ kubectl -n registry-creds-system get clusterpullsecrets
NAME             SECRETNAME   SECRETNAMESPACE
hub-docker-com               

The controller has errors in logs:

2021-04-13T18:20:23.835Z    DEBUG    controller-runtime.controller    Successfully Reconciled    {"controller": "clusterpullsecret", "request": "/hub-docker-com"}
2021-04-13T18:20:24.922Z    INFO    controllers.ClusterPullSecret    Found: hub-docker-com
2021-04-13T18:20:24.922Z    INFO    controllers.ClusterPullSecret    Found 8 namespaces
2021-04-13T18:20:24.922Z    INFO    controllers.ClusterPullSecret    Getting SA for: kube-node-lease
2021-04-13T18:20:24.922Z    INFO    controllers.ClusterPullSecret    Found error: no valid secretRef found on ClusterPullSecret: hub-docker-com.
2021-04-13T18:20:24.922Z    INFO    controllers.ClusterPullSecret    Getting SA for: default
2021-04-13T18:20:24.922Z    INFO    controllers.ClusterPullSecret    Found error: no valid secretRef found on ClusterPullSecret: hub-docker-com.
2021-04-13T18:20:24.922Z    INFO    controllers.ClusterPullSecret    Getting SA for: ingress-nginx
2021-04-13T18:20:24.922Z    INFO    controllers.ClusterPullSecret    Found error: no valid secretRef found on ClusterPullSecret: hub-docker-com.
2021-04-13T18:20:24.922Z    INFO    controllers.ClusterPullSecret    Getting SA for: metallb-system
2021-04-13T18:20:24.922Z    INFO    controllers.ClusterPullSecret    Found error: no valid secretRef found on ClusterPullSecret: hub-docker-com.
2021-04-13T18:20:24.922Z    INFO    controllers.ClusterPullSecret    Getting SA for: kubernetes-dashboard
2021-04-13T18:20:24.922Z    INFO    controllers.ClusterPullSecret    Found error: no valid secretRef found on ClusterPullSecret: hub-docker-com.
2021-04-13T18:20:24.922Z    INFO    controllers.ClusterPullSecret    Getting SA for: registry-creds-system
2021-04-13T18:20:24.922Z    INFO    controllers.ClusterPullSecret    Found error: no valid secretRef found on ClusterPullSecret: hub-docker-com.

Operating system and version:
CentOS 7, Kubernetes 1.20.4, containerd.

Is your feature request related to a problem? Please describe.
As mentioned in TODO list:

• Propagate alterations/updates to the primary ClusterPullSecret in each namespace when the secret value changes (the work-around is to delete and re-create the ClusterPullSecret)

Now there is no feature to do the automation secret update, which is not convenient, even that we have the workaround.

Describe all possible solutions, and which you suggest

Now have one idea is similar to other watchers, like namespace, serviceaccount. We could create a new watcher for seed secret, and when it is updated, the controller will get the event, to re-trigger reconciling for ClusterPullSecretReconciler to update all the secrets in the namespaces.

Describe alternatives and workarounds that you've considered
None

Additional context
None

Describe the bug
It looks like the operator does not react when a new ServiceAccount is created after the operator has been installed.

To Reproduce
Steps to reproduce the behavior:

1. Create new kind cluster
2. Follow instructions to install registry-creds, create seed secret, and add the ClusterPullSecret CRD
3. create a private image on dockerhub by pulling nginx:latest, retag, and push to your private dockerhub repo
4. Create a new basic helm chart with helm create foobar - which creates by default a new ServiceAccount and deployment of library/nginx
5. Change the repository and tag in values.yaml to your new private image
6. Run helm install foobar ./foobar
   1. A ServiceAccount is created in the default namespace, that the registry-creds operator does not react to and add the imagePullSecret
   2. A deployment is created that fails with ImagePullBackoff
7. Delete the registry-creds pod (and let it be recreated)
8. foobar deployment successfully pulls, since new registry-creds pod now sees the new ServiceAccount

Full recreation:

mkdir recreate-issue

cd recreate-issue

kind create cluster

kubectl apply -f https://raw.githubusercontent.com/alexellis/registry-creds/master/manifest.yaml

kubectl create secret docker-registry registry-creds-secret --namespace registry-creds-system --docker-username=rothandrew --docker-password=[REDACTED] [email protected]

cat <<EOF | kubectl apply -f -
apiVersion: ops.alexellis.io/v1
kind: ClusterPullSecret
metadata:
  name: docker-registry
spec:
  secretRef:
    name: registry-creds-secret
    namespace: registry-creds-system
EOF

helm create foobar

helm install foobar ./foobar --set image.repository=rothandrew/testprivate --set image.tag=test1

# foobar deployment is now in ErrImagePull with following error:
# Failed to pull image "rothandrew/testprivate:test1": rpc error: code = Unknown desc = failed to pull and unpack image "docker.io/rothandrew/testprivate:test1": failed to resolve reference "docker.io/rothandrew/testprivate:test1": pull access denied, repository does not exist or may require authorization: server message: insufficient_scope: authorization failed

kubectl get pods -n registry-creds-system --no-headers=true | awk '/registry-creds-registry-creds-controller/{print $1}' | xargs kubectl delete -n registry-creds-system pod

# foobar pod will now get pulled successfully the next time k8s tries.

Expected behavior
The operator notices when new service accounts are created and adds the ImagePullSecret to them

Screenshots or console output
N/A

Operating system and version:
MacOS Mojave 10.14.6

List all possible solutions, and your suggested option
Not sure. I'm not familiar with this operator's functionality enough to make any educated guesses.

Additional context
none

Is your feature request related to a problem? Please describe.
No

Describe all possible solutions, and which you suggest
Ideally this project would provide a repo for helm to discover and install the registry-creds related assets. Willing to contribute if you'd like

Describe alternatives and workarounds that you've considered
We're currently hosting a local helm chart version of this project but it's downstream and requires manual work to keep in sync. Using the current provided solutions (arkade, kustomize) don't fit our internal tooling and workflows

Additional context
None

Describe the bug
When upgrading registry-creds using kubectl, the controller throws an error:

E0125 08:06:38.503340       1 leaderelection.go:330] error retrieving resource lock registry-creds-system/8bdecb1a.alexellis.io: leases.coordination.k8s.io "8bdecb1a.alexellis.io" is forbidden: User "system:serviceaccount:registry-creds-system:default" cannot get resource "leases" in API group "coordination.k8s.io" in the namespace "registry-creds-system"

To Reproduce
Steps to reproduce the behavior:

1. kubectl apply -f https://raw.githubusercontent.com/alexellis/registry-creds/master/manifest.yaml
2. Get the log from the controller

Expected behavior
The error should not happen and the leases should be updated.

Are you a GitHub Sponsor (Yes/No?)

Issues from sponsors get prioritised and a quicker response.

Check at: https://github.com/sponsors/alexellis

• Yes
• No

Screenshots or console output

E0125 08:06:38.503340       1 leaderelection.go:330] error retrieving resource lock registry-creds-system/8bdecb1a.alexellis.io: leases.coordination.k8s.io "8bdecb1a.alexellis.io" is forbidden: User "system:serviceaccount:registry-creds-system:default" cannot get resource "leases" in API group "coordination.k8s.io" in the namespace "registry-creds-system"

Operating system and version:
EKS running Kubernetes 1.21

List all possible solutions, and your suggested option
Add the required rule to the Role:

  - verbs:
      - get
      - create
      - update
      - patch
    apiGroups:
      - coordination.k8s.io
    resources:
      - leases

Additional context
N/A