Allow for multiple service accounts to have ImagePullSecrets applied about registry-creds HOT 11 CLOSED

Hi @alexellis,
Hope you are well and sorry for the ping but with docker hub introducing these rate limits from 2nd November, I'd like to get some thoughts/feedback on the above and linked PR going forward.

Thanks,
David

from registry-creds.

Hi David, thank you for creating an issue. I know you started with the PR without proposing the change first, so this fell off my radar whilst waiting.

I'll try to find some time to look into your request.

Alex

from registry-creds.

I would like you provide an example chart and any YAML files required so I can understand how to reproduce the issue.

It may be that I've not yet run into your usecase, which is why it isn't making sense. An example will help and will allow me to verify the patch now and going forward.

Alex

from registry-creds.

Is this just a case of:

Default SA (existing)
Deployment 1 - plus new non-default SA 1
Deployment 2 - plus new non-default SA 2

And then the result is that Deployment 1 and 2 cannot be pulled since their SAs do not have a pull secret?

from registry-creds.

Hi Alex, In its most simple description yes.

The use of a non-default SA causes ImagePullBackoff or simply doesn't use the imagePullSecret so would be enforced by the docker hub rate limits.

from registry-creds.

I am torn between these two options:

• 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.

The current behaviour applies the pull secret to the default ServiceAccount, but as you say, if you have others like "faas-controller" it wouldn't be able to pull images.

In #8 I extracted the code so that we can clearly see where the default SA is referenced. That is where I would see 1 or 2 being applied in a single PR, without any other changes or stylistic refactoring.

The question is what is less surprising as a developer experience? 1 or 2?

from registry-creds.

I am torn between these two options:

I can totally appreciate that, as I was during my initial implementation of the PR and during testing.

The question is what is less surprising as a developer experience? 1 or 2?

I think 1 gives the similar approach to the existing default SA workflow, but changes to "All Service Accounts in the namespace" (With the same exception of the exclude namespace)

With 2 - after further thought, I feel as though developers may easily forget about the annotation/label (what ever mechanism used to "select" the SA) and come under the impression that their image pulls are authenticated, when in fact they're not.
This is fine for public images, but could cause confusion when debugging private image pulls and involves additional steps to resolve.

from registry-creds.

In #8 I extracted the code so that we can clearly see where the default SA is referenced. That is where I would see 1 or 2 being applied in a single PR, without any other changes or stylistic refactoring.

Awesome, I'll take a look as soon as I can.

from registry-creds.

Hey @alexellis, facing similar issue, in my case prmoetheus and nginx have their own serviceaccounts and I tried your aproach from the githup creating regostry cred but its not working can you provide some suggestions on this? Thanks in advance
In detail
Problem Statement: nginx ingress controller and prometheus operator is trying to create their own Service Accounts in namespace and pods are using those service accounts. Our imagepullsecretereplicator fix is not able to add "docker premium" credentials in those non default serivce accounts instantly .....it is doing it after 10 seconds
question: will regcred operator be able to add "docker premium" credentials in those non default service accounts during their creation itself?

from registry-creds.

Hi @sushantsj,

Thank you for your interest.

Please can you raise your own issue? Fill out all this detail in the issue template and don't delete any part of it.

That would be most appreciated.

Alex

from registry-creds.

/lock: inactive, raise your own issue as a GitHub Sponsor

from registry-creds.