Better document how to get service account tokens on modern Kubernetes

[chadlwilson]

In newer Kubernetes versions, indefinite lifetime service account tokens appear to have gone out of fashion, and there is no automation creation of a Secret for a token. If you want such a thing you need to create one with something like the below (using a GoCD instance and secrets in the gocd namespace, and re-using its default service account):

https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/

kind: Secret
apiVersion: v1
metadata:
  name: gocd-sa-secret
  namespace: gocd
  annotations:
    kubernetes.io/service-account.name: gocd
type: kubernetes.io/service-account-token

The plugin could do with documenting this better, including removing the misleading stuff on the configuration? Arguably should support retrieval of tokens dynamically. Yikes.

See gocd/gocd-kubernetes-based-secrets-plugin#167

Basic script to do this (assumes install into gocd namespace, with serviceaccount called gocd similar to the helm chart.

# Create a non-expiring token attached to the GoCD servers service account
kubectl apply -f - <<EOF
kind: Secret
apiVersion: v1
metadata:
  name: gocd-sa-secret
  namespace: gocd
  annotations:
    kubernetes.io/service-account.name: gocd
type: kubernetes.io/service-account-token
EOF

# Extract the token
kubectl get secret gocd-sa-secret -o json | jq -r '.data.token' | base64 --decode

# ^^^ Paste this into the security token field https://github.com/gocd/kubernetes-elastic-agents/blob/master/docs/configure_cluster_profile.md

# Get the cluster CA cert while you are at it
kubectl get secret gocd-sa-secret -o json | jq -r '.data."ca.crt"' | base64 --decode

# ^^^ Paste this into the Cluster CA Cert field https://github.com/gocd/kubernetes-elastic-agents/blob/master/docs/configure_cluster_profile.md

[brandonvin]

Arguably should support retrieval of tokens dynamically.

Big +1 on that. That sounds somewhat related to #44, where it's suggested to read the /var/run/secrets/kubernetes.io/serviceaccount/token file to populate the token when it isn't provided in the cluster profile. Grabbing the token from that file would solve this for a GoCD server running inside a Kubernetes pod, I think.

[chadlwilson]

Yeah, I'm unsure why reading the token file wasn't done in the original plugin design to make it easier to configure. But yes #44 is relevant, thanks for linking.

[chadlwilson]

Keeping notes for myself here - I think the default Fabric Kubernetes Client we use will actually handle this the most gracefully with its auto-configuration approach, as it can read tokens, CA cert etc from the file system project auto-mounted values. These tokens are only valid for an hour by default now, and will be renewed on the filesystem by the kubelet, so need to make sure it re-reads the value periodically, and make sure any client caching doesn't get in the way of this.

If so, we'd probably just need to make the security token optional from the plugin perspective (so it defaults to auto-configuration), improve the in-plugin help and documentation, and update the Helm chart to be consistent with the modern approach.

Some more discussion at gocd/helm-chart#98 (comment) where I remind myself of all of the pain here (and fix a related bug with CA cert handling)

[chadlwilson]

This is both better documented and better handled through more secure defaults that don't rely on a long lived token now with v4.0.0-505, especially when using with the GoCD Helm chart which already configures a valid service account for the "normal" case.