Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrading from v1 to v3 error #87

Closed
stuarthendren opened this issue Oct 14, 2022 · 3 comments
Closed

Upgrading from v1 to v3 error #87

stuarthendren opened this issue Oct 14, 2022 · 3 comments
Labels
idle Inactive for 14 days question Further information is requested

Comments

@stuarthendren
Copy link

stuarthendren commented Oct 14, 2022

I've been using v1 in my github actions with no problems but started to get a warning from github that node 12 was deprecated and I should update this action. So I tried to move to v3 but can not get it to work so I can run kubectl command successfully.

The v1 set up was:

   - uses: azure/aks-set-context@v1
        with:
          creds: "${{ secrets.CREDENTIALS }}"
          cluster-name: ${{ secrets.CLUSTER_NAME }}
          resource-group: ${{ secrets.RESOURCE_GROUP }}

the v3 set up - I've tried all combinations of admin and use-kubelogin for example:

      - name: Azure Login
        uses: azure/login@v1
        with:
          creds: "${{ secrets.CREDENTIALS }}"

      - name: Azure kubelogin
        run: |
          curl -LO https://github.com/Azure/kubelogin/releases/download/v0.0.9/kubelogin-linux-amd64.zip
          sudo unzip -j kubelogin-linux-amd64.zip -d /usr/local/bin
          rm -f kubelogin-linux-amd64.zip
          kubelogin --version
      
     - uses: azure/aks-set-context@v3
          with:
            cluster-name: ${{ secrets.CLUSTER_NAME }}
            resource-group: ${{ secrets.RESOURCE_GROUP }}
            admin: "false"
            use-kubelogin: "true"

With these there is no error during login or via the aks-set-context but I get the error

Error from server (Forbidden): pods "my-pod-0" is forbidden: User "xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" cannot get resource "pods" in API group "" in the namespace "my-namespace": User does not have access to the resource in Azure. Update role assignment to allow access.

This user does have access - supported by the fact it works in the v1 case.

I'm not sure the problem lies with this action? but if not do you know why this could happen?

@stuarthendren stuarthendren added the need-to-triage Requires investigation label Oct 14, 2022
@OliverMKing
Copy link
Collaborator

Hi @stuarthendren! Thanks for the issue.

The v1 scenario can be emulated by using the admin: true flag.

     - uses: azure/aks-set-context@v3
          with:
            cluster-name: ${{ secrets.CLUSTER_NAME }}
            resource-group: ${{ secrets.RESOURCE_GROUP }}
            admin: "true"

Does this work for you?

If not try bumping the kubelogin version to the latest one with

      - name: Azure kubelogin
        run: |
          curl -LO https://github.com/Azure/kubelogin/releases/download/v0.0.20/kubelogin-linux-amd64.zip
          sudo unzip -j kubelogin-linux-amd64.zip -d /usr/local/bin
          rm -f kubelogin-linux-amd64.zip
          kubelogin --version

@OliverMKing OliverMKing added question Further information is requested and removed need-to-triage Requires investigation labels Oct 17, 2022
@stuarthendren
Copy link
Author

Hi @OliverMKing - Adding admin fixed it.

I had tried that already but because the script still failed I just put it down to the context being incorrect. However, I had missed that it changes the cluster name to **-admin, that caused later things to fail and I mistakenly thought it still wasn't logged in correctly. I see the logic behind changing the cluster-name I just didn't notice it the first time. I also see that most of the time this would be just set in the config and kubectl would pick it up correctly and everything would work. It was only that I had a part of the downstream tasks that used the cluster name separately that it failed.

Maybe this change should be mentioned in the readme? But I'm happy for you to close this issue, thanks for your help.

@github-actions
Copy link

github-actions bot commented Nov 3, 2022

This issue is idle because it has been open for 14 days with no activity.

@github-actions github-actions bot added the idle Inactive for 14 days label Nov 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
idle Inactive for 14 days question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants