Kubectl: Allow [kubectl config set-cluster] to specify certificate-authority data in command.
Currently kubectl only allows a certificate to be specified from the filesystem, it's possible to embed the certificate in the configuration file.
I'd like to be able to pass the certificate base64 encoded directly with kubectl config set-cluster.
This will allow me to generate a configuration command without having to write the cert to the filesystem.
@k8s-mirror-cli-feature-requests
neoel
All 26 comments
Totally agree! As a workaround, there is a somewhat non-obvious way to do it already:
kubectl config set clusters.<name-of-cluster>.certificate-authority-data $CADATA
Still think this should be a set-cluster operation, though.
carlpett
on 22 Jul 2018
/kind feature
/sig cli
/area kubectl
/priority P2
seans3
on 26 Sep 2018
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
on 25 Dec 2018
/remove-lifecycle stale
nikhita
on 25 Dec 2018
I'm also looking for this feature 馃憤
zedtux
on 15 Jan 2019
2019 and kubectl still wants the files physically on the disk. This is not automation friendly :-)
bluemalkin
on 3 Feb 2019
I would like to use this but also provide client key and client cert data from the command as well. This will make automating the creation on conf files easier without having to write and manage extra files on disk. Reason is we use an external certificate provider and can hold the data in member when generating the conf file if this was available.
mitchellmaler
on 26 Feb 2019
The feature is there. Try this:
# Embed certificate authority data for the e2e cluster entry
kubectl config set-cluster e2e --certificate-authority=~/.kube/e2e/kubernetes.ca.crt --embed-certs=true
So if you have your cluster certificate just as data (AWS EKS for example), just create temp file, put your data into it and run the set-cluster with --embed-certs=true flag.
In automation you always can create files with the following snippet:
cat > my_temp_cert.crt << EOL
DATA1234567890
EOL
vgarmash-chwy
on 14 Mar 2019
@vgarmash-chewy we know about this, but this issue is exactly to not have to do what you described.
Feel free to read again the issue.
zedtux
on 15 Mar 2019
https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#define-clusters-users-and-contexts
Some times you may want to use base64 encoded data here instead of the path of the certification files, then you need add the suffix -data to the keys. For example, certificate-authority-data, client-certificate-data, client-key-data.
in kubectl v1.14.1 I get error: Unexpected args: for using certificate-authority-data.
Although it doesn't explicitly say it can be used with kubectl config set-cluster (and I suppose they mean doing so by writing to the file) I found it confusing.
wesley-c42
on 7 May 2019
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
on 5 Aug 2019
/uninstall-fejta-bot now
zedtux
on 6 Aug 2019
/remove-lifecycle stale
zedtux
on 6 Aug 2019
If zsh is available it supports creating temporary files from a process' output using =(some command), in addition to the usual fifo version <(another command) supported by sh/bash/etc... so if you have zsh available this does work:
kubectl config set-cluster xyz --embed-certs --certificate-authority =(cat <<'EOF'
-----BEGIN CERTIFICATE-----
xxxxx
-----END CERTIFICATE-----
EOF
)
if kubectl was modified to work with fifos and not just files this would be much more portable.
NathanHowell
on 27 Sep 2019
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
on 25 Dec 2019
/remove-lifecycle stale
marlonstoops
on 27 Dec 2019
/remove-lifecycle stale
davidwter
on 28 Feb 2020
/assign
brianpursley
on 10 Apr 2020
Totally agree! As a workaround, there is a somewhat non-obvious way to do it already:
kubectl config set clusters.<name-of-cluster>.certificate-authority-data $CADATAStill think this should be a set-cluster operation, though.
Trying to cleanup the issue list.
Can this issue be closed?
This has been open for almost a couple of years and I don't think a change to set-cluster will occur since there is a pretty simple way to accomplish the same thing as you mentioned...
kubectl config set clusters.<name-of-cluster>.certificate-authority-data $CADATA
Unless there is a compelling reason, I would propose we just close this with the above statement noted as the recommended way to accomplish this if you really need to not write the data out to a temporary file.
brianpursley
on 13 May 2020
@brianpursley the fix seems pretty small, assuming I'm reading the code right. I don't know go well enough to propose a solution. the CA file appears to be read twice, which doesn't work with a fifo.
run calls validate which reads the file once:
then calls modifyCluster which reads it again:
NathanHowell
on 13 May 2020
@NathanHowell OK, thanks for the explanation. I didn't realize there was an underlying issue with multiple reads which would affect fifo. I must have glossed over the point of your comment above, but I think I understand now.
Let me see if I can revisit the PR in a way that can fix the underlying issue...
brianpursley
on 13 May 2020
The PR that was merged will allow you to use process substitution with the --certificate-authority command line option, so you will be able to do this:
kubectl config set-cluster xyz --embed-certs --certificate-authority <(echo $CACERT)
@brianpursley thanks for pushing this through
NathanHowell
on 21 May 2020
Great news, thank you very much !!
zedtux
on 21 May 2020
@brianpursley may we have the same for two other properties?
client-key-data
The following workaround works though
kubectl config set users.<user>.client-certificate-data $CLIENT_CERTIFICATE_DATA
kubectl config set users.<user>.client-key-data $CLIENT_KEY_DATA
malferov
on 31 May 2020
@brianpursley may we have the same for two other properties?
client-key-data
@malferov The merged PR fixes those too. https://github.com/kubernetes/kubernetes/pull/91077/files#diff-e7b8759abac71d5e887c99a90de266c6L423-L431
brianpursley
on 1 Jun 2020
Related issues
adambro
路
3Comments
ameukam
路
5Comments
J-Siu
路
4Comments
ihoegen
路
5Comments
hershkoy
路
4Comments
Most helpful comment
Totally agree! As a workaround, there is a somewhat non-obvious way to do it already:
kubectl config set clusters.<name-of-cluster>.certificate-authority-data $CADATAStill think this should be a set-cluster operation, though.