search

uselagoon / remote-controller

A group of controllers for handling Lagoon builds and tasks in Kubernetes or Openshift
5 stars 1 forks source link

refactor: support for legacy and bound serviceaccount tokens #186

Closed shreddedbacon closed 2 years ago

shreddedbacon commented 2 years ago

Checklist

The lagoon-deployer service account token is not created in kubernetes 1.24 via kind: Secret anymore. Kubernetes has supported bound tokens for a few versions now.

This PR supports mounting the legacy token if it exists (for clusters and environments created prior to kubernetes 1.24), but will still provide the bound token via projected volume mounts by running the pod with the lagoon-deployer service account.

The following PRs address changing the location for the bound token, but still allowing for legacy to be used.

These will have to exist for some time for transitioning

Closing issues

closes #151

shreddedbacon commented 2 years ago

The 1.24 test will fail until https://github.com/uselagoon/build-deploy-tool/pull/140 is merged, this is because the deployer-token doesn't get created, and the current latest image does not support the new volume location

shreddedbacon commented 2 years ago

Looks good to the eye, I think I understand all the implications/background - but happy to zoom about this if you'd like.

The main changes are that here we no longer block a build from starting if no serviceaccount token is found. This is because in kubernetes 1.24+, this token secret is not created automatically anymore. Prior versions automatically created a lagoon-deployer-token-xxx secret.

If an existing token is found, we mount it here so it is made available to the build pod, but if there is no existing serviceaccount token found, we now always set the serviceaccount name in the podspec, then the token is mounted using volume projection (which handles all the goodies like rotating it if its about to expire etc), and the token is then made available at this location /var/run/secrets/kubernetes.io/serviceaccount/token

We do similar for advanced tasks too if they require the deployer token. Standard tasks don't need this, so they remain unchanged.

The other problem is that all our builds and tasks reference this old path for consuming the token, not the new path. So have had to update other tools/code to check for both tokens now.