tobybellwood/lagoon-token-rotate.md

## lagoon-token-rotate.md

      
    Raw
  

              lagoon-token-rotate.md
            
          
    Rotating lagoon-remote tokens in the Lagoon API

This is the process that run when a lagoon-remote token requires rotating in the Lagoon API.
Whilst this process was possible previously, it required some advanced GraphQL manipulation.
With the most recent releases of Lagoon and Lagoon-CLI, it is much more straightforward.
Requirements:

lagoon-cli - version v0.15.1 onwards
lagoon-core - version v2.10.0 onwards

Service account tokens in lagoon-remote

Lagoon creates two service accounts (and associated Cluster Role Bindings) in lagoon-remote (note the first part may change by installed namespace):

lagoon-remote-kubernetes-build-deploy - this is a legacy, and will be deprecated from Lagoon in a coming release
lagoon-remote-lagoon-build-deploy - this is the main one, created by the lagoon-build-deploy helm chart/subchart

Backup the existing tokens from the Lagoon API

LAGOON_CLI="lagoon -l YOUR_CLUSTER_CONFIG_NAME"
${LAGOON_CLI} list deploytargets --output-json | jq > /path/to/backup.json

Rotating the credentials in lagoon-remote

Safest method is to remove both service accounts tokens that lagoon-remote and lagoon-build-deploy helmcharts create
To rotate your lagoon credential for use in the Lagoon API, you need to delete the two created service accounts tokens,
and kubernetes will create new ones and the old ones will be invalid
NAMESPACE=lagoon
# delete the old tokens
kubectl -n ${NAMESPACE} delete secrets $(kubectl -n ${NAMESPACE} get secrets | grep "lagoon-build-deploy-token" | awk '{print $1}')
kubectl -n ${NAMESPACE} delete secrets $(kubectl -n ${NAMESPACE} get secrets | grep "kubernetes-build-deploy-token" | awk '{print $1}')
# retrieve the new token to be added to the Lagoon API
LAGOON_NEW_TARGET_TOKEN=$(kubectl -n ${NAMESPACE} get secrets $(kubectl -n ${NAMESPACE} get secrets | grep "lagoon-build-deploy-token" | awk '{print $1}') -o json | jq -r '.data.token' | base64 --decode)
# retrieve the cluster targetname
LAGOON_TARGET_NAME=$(kubectl -n ${NAMESPACE} get deployment $(kubectl -n ${NAMESPACE} get deployment | grep "lagoon-build-deploy" | awk '{print $1}') -o json | jq -r '.spec.template.spec.containers[] | select(.name =="manager").env[] | select(.name == "LAGOON_TARGET_NAME").value')

Update the credentials in the Lagoon API

Use the given LAGOON_TARGET_NAME and LAGOON_NEW_TARGET_TOKEN to update the correct deploytarget in the Lagoon API.
# retrive the cluster id
LAGOON_TARGET_ID=$(${LAGOON_CLI} list deploytargets | grep ${LAGOON_TARGET_NAME} | awk '{print $1}')
# update the token in the target
${LAGOON_CLI} update deploytarget --id ${LAGOON_TARGET_ID} --token ${LAGOON_NEW_TARGET_TOKEN}

Conclusion

Eventually, once the SSH-Portal work has been completed, there will be no need for these tokens in the API, as communication between lagoon-core and lagoon-remotes will be via NATS instead of direct kubectl access.