Kubectl: Allow kubeconfig to be Base64 encoded string

[webdeb]

FEATURE REQUEST

kubectl --kubeconfig=$K8S_CONFIG_BASE64 [do something]

Would be nice, if you could just pass the whole kubeconfig as base64 string to kubectl command.
The main reason for this is to use kubectl in CI/CD pipelines, where people are storing their kubeconfig in some sort of settings/variables (like gitlabs secrets). Also if you use some kind of kubectl container to run kubectl.

AFAIK the mainly used workaround is to decode that string, create a tmp/file, and then executing the command.

[webdeb]

Just an idea that could be implemented very easily:

--kubeconfig="base64:$K8S_CONFIG"

[seans3]

/sig cli
/area kubectl
/kind feature

[waldbeerlein]

+1

[webdeb]

@seans3 please check out my PR

[mishushakov]

You could just:

1. Copy your kubeconfig to clipboard as base64 string:
   cat ~/.kube/config | base64 | pbcopy

2. On your CI pipeline, create a environment variable kube_config and paste your base64 string

3. Encode your base64 variable back to kubeconfig environmental variable:
   echo ${kube_config} | base64 -d > ${KUBECONFIG}

4. Set context with kubectl:
   kubectl config use-context <name of your context>

5. Execute your commands
6. Done!

[webdeb]

@mishushakov yes, thats exactly what I already wrote. these are 4 commands you have to put inside your ci/cd scripts, and unfortunately this method does not work if you store the variable in gitlab secrets because it prevents secrets to be printed.

[mishushakov]

@webdeb on GitLab you can connect your cluster and have access to k8s environment variables (https://gitlab.com/help/user/project/clusters/index#deployment-variables), in this case we actually need the KUBECONFIG variable:

[cbluth]

I have been looking for something like this, to execute kubectl commands against different clusters progamatically without having to deal with KUBECONFIG files on the filesystem.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[jdamata]

/reopen

[k8s-ci-robot]

@jdamata: You can't reopen an issue/PR unless you authored it or you are a collaborator.

In response to this:

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[unixfox]

Can someone reopen this issue? Some people are still interested into this feature.

[webdeb]

Just a hint for everyone who needs this for the GitLab CI.

You can define your Variable as File
https://docs.gitlab.com/ee/ci/variables/#custom-environment-variables-of-type-file

The Variable can then be used directly with kubectl
without creating a file manually in the scripts.

kubectl ... --kubeconfig="${K8S_CONFIG}"