Enable non-default service accounts

[goffinf]

Typically we use different service accounts for pods that are assigned explicitly and provide context for a number of lifecycle and access control aspects (including but not only imagePullSecrets). As a best practice we do not make use of the default service account since that doesn’t provide sufficiently granular separation of concerns for shared, mixed workload clusters.

We deal with imagePullSecrets much as you have described as part of deployment automation, however, I like the premise of this project and I think it could be easily adapted to support our needs and those of many other who operate similarly.

Would you consider exposing the service account so that this doesn’t have to be a fixed constant (you could still maintain ‘default’ as the default value for those that want that) ?

Kind Regards

Fraser.

[billjh]

Hi @goffinf, thanks for your feedback!

It's definitely possible to expose an argument to replace the service account name instead of using "default". However, the use case might be a bit more complicated for customized service accounts:

1) All namespaces have the service account with the same name 2) Each namespace has a different service account name 3) A namespace has more than one service account in use (including default)

I wonder what your potential use case is. If it's 1), providing an argument to replace "default" will work for you.

[goffinf]

It’s definitely 3.

With a few exceptions, we always configure an explicit service account for a deployment since that account determines the access control for a number of other resource APIs. For example, a container in the pod may need to read or write values to/from our secrets backed (HashiCorp Vault), it may need to access Cloud resources (so is bound to an IAM role and policies), it may need to access the K8s API, it may be named as a subject in a PSP, and, as you have mentioned, it certainly needs to be able to pull images from our private registry. As you can see the service account defines an identity that needs to be configurable to provide a very specific security context, hence why we don’t use default nor necessarily the same service account in all namespaces (although that will normally be the case for the same application).

We manage this pretty well through automation today, but I am always looking to remove the overhead of maintaining custom code.

HtHs

Fraser.

[billjh]

Thanks for your detailed explanation.

My current idea to support multiple service accounts is by listing and patching all service accounts for each namespace. It will be quite aggressive, so there might be a configuration option for that.

But I am not sure if in any use case, exclusions will be needed. The configuration can be implemented in a few ways in my first thought:

1. Through the visibility of the IAM role from the service account that runs imagepullsecret-patcher itself (no need to change code)
2. Explicit annotation to the namespaces or service accounts, eg. "imagepullsecret-patcher-exclude: true"
3. Read configmap in some format, eg. "exclude-namespaces: product-a, service-b"

[billjh]

da0e8e2a7152f702aa5613d54c16441661c8e2ca

[billjh]

A new config option -allserviceaccount / CONFIG_ALLSERVICEACCOUNT was added in release v0.9.

If enabled, it will list and patches all service accounts instead of just "default". It is aggressive, so by default it is turned off.

The exclusions mechanism is skipped because of not receiving any requests yet.

[billjh]

I will close this issue for now, thanks for the feedback @goffinf