Support for private gcr registries about kube-secrets-init HOT 9 CLOSED

I think I found the issue. I'm doing some tests and will post an update.

Temporary workaround: set the command and args for your container, even if they are specified in the Dockerfile.

containers:
- name: some-container
  image: 'private-org/some-image:latest'
  command: [ './server' ]
  args: [ 'run' ]

@awasilyev @AntonioCayulao @JTarball FYI

from kube-secrets-init.

Hey folks!

Since the original registry code is based on Bank Vaults from Banzai Cloud, I think I can offer a little bit of context here.

Let's start with the reason why kube-secrets-init needs registry access in the first place (and why @zenyui 's workaround works): in order to successfully prepend the secrets-init command to the container command (entrypoint), the webhook needs to know what it is. If you specify a command (and args) then the webhook can just mutate those fields, job done. But if not (in which case Kubernetes also falls back to the entrypoint and command in the container image) the webhook needs to look at the image to determine those parameters.

Now, the current code in this repo uses Heroku's "old" docker client that only supports username-password based credentials. Both Bank Vaults and kube-secrets-init used image pull secrets in the pod to try and authenticate against private registries.

Obviously, we also received complaints about this at Banzai Cloud, so we replaced the implementation with another one using Google's go-containerregistry library.

In addition to image pull secrets it also takes into account workload/cloud provider identity based registries as well (it supports ECR, GCR and ACR).

Given the registry implementation in kube-secrets-init is basically a 1:1 copy from Bank Vaults, I think it'd be relatively easy to do the same thing again and just copy the updated version using the new library.

(There are some changes, so if you decide to make the change keep out for those. Maybe first just diff the old registry implementation with the one in this library to see the differences first)

Hope this helps! If I get the time I might make the change myself, but I can't say when.

from kube-secrets-init.

Hi @awasilyev
How do you did to make a work around about this problem?
Do you also use workload-identity, right?
Any help that you can do I will really appreciate!
Greetings!

from kube-secrets-init.

Any updates on this issue? - I am experiencing the same problem

from kube-secrets-init.

I think I found the issue. I'm doing some tests and will post an update.

Temporary workaround: set the command and args for your container, even if they are specified in the Dockerfile.

containers:
- name: some-container
  image: 'private-org/some-image:latest'
  command: [ './server' ]
  args: [ 'run' ]

@awasilyev @AntonioCayulao @JTarball FYI

This did the trick for us but still a bit crap having to do it.

from kube-secrets-init.

@brtknr yeah, dont love it either, just sharing our hack.

my team forked the repo and will spend some cycles trying to see if we can add logs and sort out why the service account permissions aren't being used. will post an update when we sort it.

from kube-secrets-init.

@sagikazarmark my team would be interested in contributing. I'll take a look soon and reach out with questions!

from kube-secrets-init.

@zenyui Sure, happy to help!

from kube-secrets-init.

Is there due to be a new release at any point with this fix?

from kube-secrets-init.