Update the token-auth example for getting-started. #4772
Conversation
Signed-off-by: Michael Nelson <minelson@vmware.com>
✅ Deploy Preview for kubeapps-dev ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
|
@absoludity when I try the instructions I see in the preview they are identical to what they were, There is no token being created. You have to create one explicitly it in a separate command:
token.yml: |
| cat <<EOF | kubectl apply -f - | ||
| apiVersion: v1 | ||
| kind: Secret | ||
| metadata: | ||
| name: kubeapps-operator-token | ||
| namespace: default | ||
| annotations: | ||
| kubernetes.io/service-account.name: kubeapps-operator | ||
| type: kubernetes.io/service-account-token | ||
| EOF | ||
| ``` |
There was a problem hiding this comment.
Given that we also have these instructions replictated in the website, I guess we would need to update this file as well: https://github.com/vmware-tanzu/kubeapps/blob/main/site/themes/template/layouts/partials/use-cases.html
There was a problem hiding this comment.
Done, I'll check the demo website once updated.
script/makefiles/cluster-kind.mk
Outdated
| @@ -6,6 +6,7 @@ | |||
| KUBE ?= ${HOME}/.kube | |||
| CLUSTER_NAME ?= kubeapps | |||
| ADDITIONAL_CLUSTER_NAME ?= kubeapps-additional | |||
| IMAGE ?= kindest/node:v1.24.0 | |||
There was a problem hiding this comment.
Kind recommends using the very exact image tag for each Kind version. However, as we can change it just setting IMAGE is not a big deal. Perhaps this image also works out of the box.
https://github.com/kubernetes-sigs/kind/releases
New Node images have been built for kind v0.12.0, please use these exact images (IE like ....
There was a problem hiding this comment.
Yep, I'll update to the exact image - easy to set in the Makefile and we can do what we like when we override (as I did to test out 1.21).
| @@ -48,7 +58,7 @@ kubectl get --namespace default secret $(kubectl get --namespace default service | |||
| Open a Powershell terminal and run: | |||
|
|
|||
| ```powershell | |||
| [Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($(kubectl get --namespace default secret $(kubectl get --namespace default serviceaccount kubeapps-operator -o jsonpath='{.secrets[].name}') -o jsonpath='{.data.token}'))) | |||
| [Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($(kubectl get --namespace default secret kubeapps-operator-token -o jsonpath='{.data.token}'))) | |||
There was a problem hiding this comment.
I'll give it a try soon just to double-check it works
There was a problem hiding this comment.
Thanks for checking the powershell :)
Signed-off-by: Michael Nelson <minelson@vmware.com>
Hi @Wouter053 . The instructions that I'd changed in my first commit were in the getting-started.md, but yes, I'd missed updating the similar section presented on the website (hence it not changing). I've done that in the second commit :) |
Signed-off-by: Michael Nelson minelson@vmware.com
Description of the change
With 1.24, token secrets are not created automatically for a service account. Updated our getting started to create the secret with the required annotation to be populated with a valid token, and update the instructions to just get that token (more simple anyway).
Verified this works both with k8s 1.24 and 1.21 .
Benefits
Avoid confusion with token auth moving forward as more people use 1.24
Possible drawbacks
Applicable issues
Additional information