devspace unauthorized kubectl is not

[mathus13]

devspace is reporting is it not authorized to preform any action in a specific context (AWS EKS cluster) while kubectl has no issue at the same time.

What happened?

s_barratt@pop-os:~/code/caves-validator$ devspace use context pre-prod2
[done] √ Successfully set kube-context to 'pre-prod2'

s_barratt@pop-os:~/code/caves-validator$ devspace use namespace sb
[info]   The default namespace of your current kube-context 'pre-prod2' has been updated to 'sb'
         To revert this operation, run: devspace use namespace 

[done] √ Successfully set default namespace to 'sb'

s_barratt@pop-os:~/code/caves-validator$ devspace dev
[info]   Using namespace 'sb'
[info]   Using kube context 'pre-prod2'
[fatal]  Unable to create namespace: get namespace: Unauthorized

s_barratt@pop-os:~/code/caves-validator$ kubectl get namespace sb
NAME   STATUS   AGE
sb     Active   98d

What did you expect to happen instead? Connect to cluster

Local Environment:

• DevSpace Version: 5.18.2
• Operating System: linux
• ARCH of the OS: AMD64 Kubernetes Cluster:
• Cloud Provider: aws
• Kubernetes Version: 1.21

/kind bug

[FabianKramm]

@mathus13 thanks for creating this issue! Could you post your devspace.yaml, this error usually occurs if you try to deploy into a different namespace than the original one or try to use kaniko / buildkit for a different namespace.

[masterful]

Chiming in on this one because I also ran into this issue and ended up figuring out why (at least for me) it was happening. The repository I was developing in used a .env (and some dotenv or equivalent library) to load some environment variables and they'd inserted placeholder values for the AWS_---_KEY credentials. I happened to be deploying into an EKS cluster, which requires token generation, and devspace would attempt to create a token using these credentials, which would fail (this was in no way obvious that it was what was happening, but it's 100% the case). kubectl does not load this .env file - and so the auth would always be fine for those commands.

My solution was to remove those AWS_ definitions from the .env file.

I'm guessing something in the devspace dependency chain loads the .env file and then the AWS library uses those credentials over other avenues - but I haven't looked too far into it.

[FabianKramm]

@masterful thanks for your input! We decided to turn the .env loading default off as its causing a lot of confusion for people. In v6 you can use the following pattern to load the .env file or any other file with that format:

version: v2beta1
vars:
  DEVSPACE_ENV_FILE: '.env' # or any other file path here