Deploying to EKS, need credentials passed

[tdonovic]

Hi there,
I am attempting to deploy some helm chart to my EKS cluster.
In order to do that, I believe I have configured aws-iam-authenticator properly, since I get the following log:

helm upgrade seed-java helm/seed-java --install --wait --atomic --namespace=feat-SYS-1027-CD-core-dev --set=app.name=seed-java --values=./values.yml
could not get token: NoCredentialProviders: no valid providers in chain. Deprecated.
	For verbose messaging see aws.Config.CredentialsChainVerboseErrors

Which is created by:

 51          uses: 'deliverybot/helm@master'
 52          with:
 53            namespace: ${{ steps.helmvars.outputs.namespace}}
 54            chart: ${{steps.helmvars.outputs.chart}}
 55            token: ${{ github.token }}
 56            value_files: "[ ${{steps.helmvars.outputs.values_static}}, ${{steps.helmvars.outputs.values_ns}}]"
 57            helm: 'helm'
 58            release: ${{ steps.helmvars.outputs.release }}
 59          env:
 60            KUBECONFIG_FILE: '${{ secrets.KUBECONFIG }}'

Does this mean that the AWS_ACCESS_KEY_ID etc are not being properly passed into the container that is being executed? I am at a bit of a loss.

I know that the credentials work, and are available to prior steps in the workflow, since I push the containers I seek to deploy to ECR.

Any ideas?

Thanks!

[raj-shekhar1]

@tdonovic you are using helm3 or helmv2x?

[colinjfw]

Yep I believe that the credentials are not being passed in, what I think you need is the following:

 51          uses: 'deliverybot/helm@master'
 52          with:
 53            namespace: ${{ steps.helmvars.outputs.namespace}}
 54            chart: ${{steps.helmvars.outputs.chart}}
 55            token: ${{ github.token }}
 56            value_files: "[ ${{steps.helmvars.outputs.values_static}}, ${{steps.helmvars.outputs.values_ns}}]"
 57            helm: 'helm'
 58            release: ${{ steps.helmvars.outputs.release }}
 59          env:
 60            KUBECONFIG_FILE: '${{ secrets.KUBECONFIG }}'
 +++           AWS_ACCESS_KEY_ID: '${{ secrets.MY_KEY }}'
 +++           AWS_SECRET_ACCESS_KEY: '${{ secrets.MY_KEY }}'

[tdonovic]

@raj-shekhar1 I am running helm 2.x
@colinjfw good point, I have tried this and see the same issue. I know that the creds are good, since I use them to push to ECR.

 50        - name: Helm Deploy
 51          uses: 'deliverybot/helm@master'
 52          with:
 53            namespace: ${{ steps.helmvars.outputs.namespace}}
 54            chart: ${{steps.helmvars.outputs.chart}}
 55            token: ${{ github.token }}
 56            value_files: "[ ${{steps.helmvars.outputs.values_static}}, ${{steps.helmvars.outputs.values_ns}}]"
 57            helm: 'helm'
 58            release: ${{ steps.helmvars.outputs.release }}
 59          env:
 60            KUBECONFIG_FILE: '${{ secrets.KUBECONFIG }}'
 61            AWS_ACCESS_KEY_ID: '${{ secrets.AWS_ACCESS_KEY_ID }}'
 62            AWS_SECRET_ACCESS_KEY: '${{ secrets.AWS_SECRET_ACCESS_KEY }}'

But I still get the same error:

could not get token: NoCredentialProviders: no valid providers in chain. Deprecated.

This is my first GH Actions project, should I expect more than just -e in -e AWS_ACCESS_KEY_ID? Because it looks like it passes the key, but does not pass the value? Or is this how it is rendered in the logs?

/usr/bin/docker run --name e87b52c1ffebf5b3a1429c9170f5fb8ee69444_a7c540 --label e87b52 --workdir /github/workspace --rm -e AWS_ACCESS_KEY_ID -e AWS_SECRET_ACCESS_KEY -e AWS_DEFAULT_REGION -e AWS_REGION -e KUBECONFIG_FILE -e INPUT_NAMESPACE -e INPUT_CHART -e INPUT_TOKEN -e INPUT_VALUE_FILES -e INPUT_HELM -e INPUT_RELEASE -e INPUT_VALUES -e INPUT_DRY-RUN -e INPUT_VALUE-FILES -e INPUT_SECRETS -e INPUT_VERSION -e HOME -e GITHUB_REF -e GITHUB_SHA -e GITHUB_REPOSITORY -e GITHUB_RUN_ID -e GITHUB_RUN_NUMBER -e GITHUB_ACTOR -e GITHUB_WORKFLOW -e GITHUB_HEAD_REF -e GITHUB_BASE_REF -e GITHUB_EVENT_NAME -e GITHUB_WORKSPACE -e GITHUB_ACTION -e GITHUB_EVENT_PATH -e RUNNER_OS -e RUNNER_TOOL_CACHE -e RUNNER_TEMP -e RUNNER_WORKSPACE -e ACTIONS_RUNTIME_URL -e ACTIONS_RUNTIME_TOKEN -e ACTIONS_CACHE_URL -e GITHUB_ACTIONS=true -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work/_temp/_github_home":"/github/home" -v "/home/runner/work/_temp/_github_workflow":"/github/workflow" -v "/home/runner/work/seed-java/seed-java":"/github/workspace" e87b52:c1ffebf5b3a1429c9170f5fb8ee69444

[colinjfw]

Hmm, I really don't know at this point. I haven't actually used this action myself with ecr. Maybe someone else can chime in?

I think the answer to the second question is that yes it is just how it's being rendered in the logs.

[tdonovic]

Really appreciate your help. Tried to dig a bit futher into how env vars are handled, but there is a bit of a lack of detail in the docs, or I'm not looking in the right place.
I think the next step is for me to try to get the creds working inside some other container, then make the changes to how this container is being called to match, and work. If its not me missing the point, that is

[rvichery]

We are facing a similar issue, it seems that the Docker image should include the aws-cli so it can execute the get-token within the kubeconfig. I am going to experiment in my own fork, will update here if it works and word with the maintainer to see if we can create another version of this action with support for EKS.

[aheifetz]

We are facing a similar issue, it seems that the Docker image should include the aws-cli so it can execute the get-token within the kubeconfig. I am going to experiment in my own fork, will update here if it works and word with the maintainer to see if we can create another version of this action with support for EKS.

if you post the link to the fork I'm happy to help test

[rvichery]

@aheifetz the PR has been merged to master. So you should be able to test directly from this repository.