nabsul / k8s-ecr-login-renew Goto Github PK

Hi,

I'm just testing out your tool following the instructions on Readme, I'm running this on K3s and trying to connect ECR in the af-south-1 region but I'm getting InvalidEndpointURL error. Here are the logs from the pod:

panic: InvalidEndpointURL: invalid endpoint uri
caused by: parse "https://api.ecr.af-south-1\n.amazonaws.com/": net/url: invalid control character in URL

goroutine 1 [running]:
main.checkErr(...)
/app/main.go:19
main.main()
/app/main.go:38 +0x7b7
Fetching auth data from AWS... %

Is this a me issue or is this something that you could perhaps assist in resolving?

Thanks for your help in advance.

Hi,
I'd like your tiny tool to create the ECR secret in EVERY namespace EXCEPT those contained in a blacklist.
Is it difficult to implement?

Thanks for your attention

These builds are surprisingly slow. I wonder if there's any way to speed them up?

A common scenario for utilizing this tool involves refreshing AWS ECR credentials within a Kubernetes deployment outside of AWS. Presently, the deployment assumes the presence of the ACCOUNT_ID environment variable, as if it were operating within AWS, and relies on its proper configuration. However, this assumption doesn't hold for deployments on other cloud platforms. It would greatly enhance flexibility to allow configuring this variable through Helm values during installation.
Of course, "registries" can be used as a workaround.

I am trying to use the project with following config:

---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: staging
  name: ecr-credentials-role
rules:
  - apiGroups: ["staging"]
    resources: ["secrets"]
    verbs: ["get", "delete"]
  - apiGroups: [""]
    resources: ["secrets"]
    verbs: ["create"]
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: ecr-credentials-service
  namespace: staging
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  name: ecr-credentials-role-binding
  namespace: staging
subjects:
  - kind: ServiceAccount
    name: ecr-credentials-service
    namespace: staging
roleRef:
  kind: Role
  name: ecr-credentials-role
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  namespace: staging
  name: cron-ecr-credentials-helper
spec:
  schedule: "0 */6 * * *"
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 5
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          serviceAccountName: ecr-credentials-service
          containers:
            - name: ecr-renew
              image: nabsul/k8s-ecr-login-renew:latest
              imagePullPolicy: "IfNotPresent"
              env:
                - name: DOCKER_SECRET_NAME
                  value: eu-west-1-ecr-registry
                - name: TARGET_NAMESPACE
                  value: staging
                - name: AWS_REGION
                  value: eu-west-1
                - name: AWS_ACCESS_KEY_ID
                  value: <key>
                - name: AWS_SECRET_ACCESS_KEY
                  value: <key>

then i create job to perform cronjob instantly

sudo kubectl create job --from=cronjob/cron-ecr-credentials-helper ecr2

But the container does not want to finish its job

$ sudo kubectl get jobs
NAME   COMPLETIONS   DURATION   AGE
ecr    0/1           5m52s      5m52s
ecr2   0/1           3m9s       3m9s

All i get is

$ sudo kubectl logs ecr-ql9fw
Running at 2020-06-15 18:16:25.248476379 +0000 UTC

This behavior is present from about 2 hours (only one run was successful), however when I was trying to run the container few hours ago it finished its job correctly in like 5 seconds.

I guess it may be related to the lack of checking if AWS API is up (I am going to investigate it more soon)

Hi,

I am having an issue to install this chart on my cluster.
Here is the values I used:

aws:
  secretKeys:
    accessKeyId: <XYZ>
    secretAccessKey: <XYZ>+<XYZ>+
  secretName: k8s-ecr-login-renew-aws-secret
awsAccessKeyId: null
awsRegion: eu-west-1
awsSecretAccessKey: null
cronjob:
  failedJobsHistoryLimit: 5
  schedule: 0 */6 * * *
  startingDeadlineSeconds: null
  successfulJobsHistoryLimit: 3
  terminationGracePeriodSeconds: 0
dockerSecretName: k8s-ecr-login-renew-docker-secret
forHelm: true
names:
  clusterRole: k8s-ecr-login-renew-role
  clusterRoleBinding: k8s-ecr-login-renew-binding
  cronJob: k8s-ecr-login-renew-cron
  job: k8s-ecr-login-renew-job
  serviceAcount: k8s-ecr-login-renew-account
podAnnotations: {}
registries: null
targetNamespace: default

When installing within Rancher GUI, I get the following error message:

helm install --generate-name=true --namespace=default --timeout=10m0s --values=/home/shell/helm/values-k8s-ecr-login-renew-1.0.2.yaml --version=1.0.2 --wait=true /home/shell/helm/k8s-ecr-login-renew-1.0.2.tgz
creating 4 resource(s)
Error: INSTALLATION FAILED: CronJob.batch "k8s-ecr-login-renew-cron" is invalid: spec.jobTemplate.spec.template.spec.containers[0].env[1].valueFrom.secretKeyRef.key: Invalid value: "<XYZ>+<XYZ>+": a valid config key must consist of alphanumeric characters, '-', '_' or '.' (e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+')

Is the reason of the error because my secretAccessKey contains "+" characters?

I have seen many versions of this script where the default service account of each namespace would be updated with the image pull secrets to avoid replacing chart values

Maybe this could be added as an optional feature ?

kubectl patch serviceaccount default -p '{"imagePullSecrets":[{"name":"'$DOCKER_SECRET_NAME'"}]}'

Readme needs to be updated

As for now, I'm simply using a Helm pre-install/pre-upgrade hook for that purpose: a Pod with an identical container template as for the CronJob. This feels suboptimal tho... do you have any suggestions if this can be done differently?

For the sake of security! better not to run things as root in the cluster (esp. in a long-running CronJob, as opposed to e.g. one-off Helm hooks)

Is there any chance you could implement the ability for this app/chart to have the ability to leverage the aws-pod-identity-webhook which implements iRSA ? It should be pretty straight forward if you're using a relatively modern AWS SDK version. You would also have to remove the hard requirements for the AWS credential env vars.

This would get us the ability to have dynamic ecr credentials and not have to store AWS user credentials in the cluster. It would be a huge win and even better than the new kubernetes native image credential helper which requires AWS credentials on the nodes.

Running job using file from #8 results in

standard_init_linux.go:211: exec user process caused “exec format error”

when using K3s on arm devices (raspberry and orange pi, both failing)

Hi,

I am wondering how the pod or deployment is creating with imagepullsecret.

I have enabled the few namespace as target in cronjob and all the namespace there is secret updated. We have role and rolebinding in place.

Out of which only 2 namespace,If i create any pod or deployment it automatically passing the imagepullsecret . I don't know how. Can you please explain that.

Thanks for this package, been using it for a long time
Just noticed latest is no longer on docker hub.
Not sure if that's intentional or not, however, latest is pretty standard to always be there

Hello,

I was noticed that the metadata is lost when the new secret is created.

Hi Thank you for the great work on this

I have a query not a bug, I have found that I can only deploy images from the docker registry to the namespace where I deployed the ecr-login-renew

Is it possible to allow this to access multiple namespaces? if so how, apologies for the what is possibly just me not understanding how the permissions work.

Kind Regards,

Scott

We are rookies in k8s, and this may be a general k8s question, but we plan to use your nice, little thing, and we wonder if we need to grant more permissions to the Role to be able to create secrets in all the namespaces we put in TARGET_NAMESPACES...

https://aws.amazon.com/blogs/compute/authenticating-amazon-ecr-repositories-for-docker-cli-with-credential-helper/ => Amazon ECR Docker Credential Helper

Actually, how does this project relate to the Helper? Is Helper for some reason not easy to use for k8s authentication against ECR? 🤔

Hello.

I'm using your solution without any hassle on x86_64, great work!

I've installed K8s using the ubuntu project named microk8s on RPi 4 with ARMv8-A 64-bit CPU, and it seems that available docker image with compiled binary for ARM 32bit is not working on 64bit architecture.

In logs I can see:

standard_init_linux.go:207: exec user process caused "exec format error"

Will it be possible to add a new step to your build steps to compile also for ARM 64-bit CPU architecture?

Regards
Tom

what do you think about creating simple helm chart with cronjob/serviceaccount deployment and put it here in /deploy folder and maybe to some public chart museum.
it would be easier to install your tool, just copy the command from the readme helm install .... and thats it.

When awsSecretAccessKey contains / (slash) then authentication to AWS fails.

Running at 2023-03-15 06:23:38.555764306 +0000 UTC
panic: InvalidSignatureException: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.
	status code: 400, request id: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

goroutine 1 [running]:
main.checkErr(...)
	/go/src/app/main.go:22
main.main()
	/go/src/app/main.go:36 +0x5e9
Fetching auth data from AWS... %