-
Notifications
You must be signed in to change notification settings - Fork 714
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
no programmatic way to get discovery token ca hash #659
Comments
Have you tried recent version of kubeadm ?
|
its still not great - anyone trying to this use this programmatically will have to parse the command in order to extract both the token and discovery token hash. It would be better if we could specify an output form like json so we can parse it safely |
thanks, i didn't realize that there was a separate/new command for this. I agree, it would be nicer to have this in json. my previous workflow for 1.6 and 1.7, was kubeadm token generate, and then reuse that value when init'ing and join'ing, the kubeadm token generate was machine readable single value line delimited, but its now effectively a dead command since it lacks the cert hash (and not per se extensible due to that format). re why machine readable, i have additional parameters to pass for the join and some that i need to replace like dns for the ip. |
Yup, I had to dump the join-command to a file, and then use sed to add an ignore-preflight-errors flag, not awful but not particularly friendly either. |
So there is an ongoing effort to trim up phases to make it more programmatic and de-dupe the flags, this is only one user story. @fabriziopandini do you have a parent issue for this somewhere? |
@timothysc However, with regards to this issue, IMO we should open a dedicated umbrella issue to tackle the demand for machine readable output in a consistent way across all commands, because the request spans from WDYT? if it is ok for you, I will open the new umbrella issue ... |
I just hit this issue myself. I was able to calculate the sha256sum of the ca cert's public key using the following:
Not pretty... |
I use the regular expressions. I tested with Ansible.
Result:
|
Closing as there are several workarounds. |
This is not recommend but, In https://github.com/cablespaghetti/kubeadm-aws/blob/master/worker.sh#L45 |
on Azure, using tags for worker and master resources: masterPrivateIp=$(az network nic list -g $rg --query "[?tags.module == 'k8smasters'].ipConfigurations[0].privateIpAddress" -o tsv) joinCommand="kubeadm join $masterPrivateIp:6443 --token $tokenId --discovery-token-ca-cert-hash sha256:$tokenSHA" for ip in $(az network public-ip list -g $rg --query [?tags.module == 'k8sworkers'].ipAddress -o tsv) |
just in case somebody stumbles upon this, in ansible you can simplify @davemac30's approach significantly:
|
Note that
|
if your creating a token, via kubeadm token create .. or any other mechanism, there is no way to get the token ca certificate hash outside of trying to parse the human readable output (and thus non stable) of kubeadm init. There should a machine readable way of creating tokens with ca hashes, else one is forced to use --discovery-token-unsafe-skip-ca-verification even if there is desire to do the right thing (tm). Atm the alternatives are either parsing the likely to be changed human read output of kubeadm init or reimplementing the hash calculation of kubeadm over the ca. the later wouldn't be so bad if it didn't require reading the source as its not a simple as ie none of the outputs of cd /etc/kubernetes/pki && sha256sum * show the same sha as that output by kubeadm init.
The text was updated successfully, but these errors were encountered: