Some users may use token that expired after a specific number of days or date, so we should document the procedure to update the GitHub/GitLab token used to create the cluster, when needed. Here are the steps based on @johndietz's answer to a community user:
think it’s a pretty smooth story it’ll look long with all the words i use but the tl;dr is update the atlantis secret in vault, wait 4 minutes, open a pr and atlantis apply via pull request.
i don’t have an aws stack up right now so you’ll have to tell me how close i get. i think the story goes like this. you’ll need to generate a new ssh public/private keypair.
ssh-keygen -t ed25519 -C "your_email@example.com"
it’ll prompt you for location, and i recommend a new location. anyplace else will do, i wouldn’t want to mess with your local ssh keys that you may use. something like /Users/yourname/ed25519
it’ll ask you for a passcode twice as well, but leave blank with the enter key each time.
view the contents of these 2 files (look over your shoulder first, the first one is sensitive)
cat /Users/yourname/ed25519
cat /Users/yourname/ed25519.pub
next log into vault with any admin user, kbot will do if you have that handy. you’ll want to update the atlantis secret. you’ll be updating these 2 values:
https://github.com/kubefirst/gitops-template/blob/v2.4.8/aws-github/terraform/vault/secrets.tf#L100-L101
when you save the new secret version, external-secrets-operator will update the kubernetes secret automatically everywhere that uses it in gitops within 10s
the 3 use cases are cwft-git and cwft-kaniko
https://github.com/kubefirst/gitops-template/tree/v2.4.8/aws-github/templates/mgmt/components/argo-workflows/cwfts
and atlantis. atlantis is configured with a reloader annotation to automatically restart when that secret changes
https://github.com/kubefirst/gitops-template/blob/v2.4.8/aws-github/templates/mgmt/components/atlantis/application.yaml#L21
atlantis takes about a minute to restart, give it a second before you open the next pr.
so in order to propagate the secret beyond gitops and into your iac layer, you’ll need to make a pull request with a whitespace change in any .tf file in the entrypoint that use that secret. you can just add a newline to this file, but be sure to pull request it so that your atlantis plan kicks off.
https://github.com/kubefirst/gitops-template/blob/v2.4.8/aws-github/terraform/aws/main.tf
comment atlantis apply on your pull request if you like your plan and that will persist your secret into your iac layer.
from that point forward everything’s mint condition i think. test iac by ensuring your secret in vault remained the new version after the apply. test ci by adding a newline to metaphor. if it can still checkout and publish you’re good to go.
Code of Conduct
[X] I agree to follow this project's Code of Conduct
What type of suggestions?
Missing Information
What page is concerned?
No response
What version of the docs?
No response
What is the issue?
Some users may use token that expired after a specific number of days or date, so we should document the procedure to update the GitHub/GitLab token used to create the cluster, when needed. Here are the steps based on @johndietz's answer to a community user:
think it’s a pretty smooth story it’ll look long with all the words i use but the tl;dr is update the atlantis secret in vault, wait 4 minutes, open a pr and atlantis apply via pull request. i don’t have an aws stack up right now so you’ll have to tell me how close i get. i think the story goes like this. you’ll need to generate a new ssh public/private keypair. ssh-keygen -t ed25519 -C "your_email@example.com" it’ll prompt you for location, and i recommend a new location. anyplace else will do, i wouldn’t want to mess with your local ssh keys that you may use. something like /Users/yourname/ed25519 it’ll ask you for a passcode twice as well, but leave blank with the enter key each time. view the contents of these 2 files (look over your shoulder first, the first one is sensitive) cat /Users/yourname/ed25519 cat /Users/yourname/ed25519.pub next log into vault with any admin user, kbot will do if you have that handy. you’ll want to update the atlantis secret. you’ll be updating these 2 values: https://github.com/kubefirst/gitops-template/blob/v2.4.8/aws-github/terraform/vault/secrets.tf#L100-L101 when you save the new secret version, external-secrets-operator will update the kubernetes secret automatically everywhere that uses it in gitops within 10s the 3 use cases are cwft-git and cwft-kaniko https://github.com/kubefirst/gitops-template/tree/v2.4.8/aws-github/templates/mgmt/components/argo-workflows/cwfts and atlantis. atlantis is configured with a reloader annotation to automatically restart when that secret changes https://github.com/kubefirst/gitops-template/blob/v2.4.8/aws-github/templates/mgmt/components/atlantis/application.yaml#L21 atlantis takes about a minute to restart, give it a second before you open the next pr. so in order to propagate the secret beyond gitops and into your iac layer, you’ll need to make a pull request with a whitespace change in any .tf file in the entrypoint that use that secret. you can just add a newline to this file, but be sure to pull request it so that your atlantis plan kicks off. https://github.com/kubefirst/gitops-template/blob/v2.4.8/aws-github/terraform/aws/main.tf comment atlantis apply on your pull request if you like your plan and that will persist your secret into your iac layer. from that point forward everything’s mint condition i think. test iac by ensuring your secret in vault remained the new version after the apply. test ci by adding a newline to metaphor. if it can still checkout and publish you’re good to go.
Code of Conduct