📦Adding acm-member-portal deployment - #158
Conversation
…deployment via Terraform.
clee231
added
☁️ Azure
| special = false | ||
| } | ||
|
|
||
| resource "kubernetes_secret_v1" "portal" { |
There was a problem hiding this comment.
The README calls this out, but I think we should just fix it instead of documenting it. kubernetes_secret_v1 owns the whole portal-secrets object, so the SMTP/Discord/Windows keys added by hand get wiped on every apply and every rotation.
▎
▎ Easy fix is kubernetes_secret_v1_data with force = true. It only manages the keys declared here and leaves the rest alone (we're on provider 2.38 so it's available). Then the "re-add them after apply" paragraph in the README can go.
There was a problem hiding this comment.
I see nothing wrong with any changes made by hand getting overridden. In the spirit of Infrastructure as code, the state of the infrastructure should be defined... well... in code, so anything done to cause the infrastructure to drift should be reconciled by the IaC deployments.
There was a problem hiding this comment.
fair, but then the README shouldnt tell people to add the SMTP/Discord/Windows keys to that secret by hand. either pull them into terraform too (sensitive vars or a key vault data source) or give them their own secret the chart also mounts. right now the doc is describing drift on purpose
There was a problem hiding this comment.
🤦♂️Oh, good point. I get what you mean now.
Fixed in 3d09040. I took your suggestion and just added force = true and updated the README.
I think later on, the other secrets will be pulled from Vault and populated in the secret. (That won't be part of this PR though. 😉)
| } | ||
| } | ||
|
|
||
| resource "time_rotating" "rotation" { |
There was a problem hiding this comment.
Just checking, what happens to the running pods when the 180 day rotation fires? The password gets replaced (destroy then create) and the Secret updates, but the pods keep the old env value until they restart. The old password is gone at that point so Microsoft login would break until someone does a rollout.
▎
▎ Either create_before_destroy = true on the password so both are valid during the swap, or a Reloader / checksum annotation on the deployment so it picks up Secret changes. Probably worth a line in the README either way.
There was a problem hiding this comment.
Are you an AI bot? 😮
There was a problem hiding this comment.
It just doesn't seem like something you'd write, so I was confused. 🤔
But anyways, after the 180 days, the password will get rotated after the 180 day rotation occurs. The expectation is the operator will handle the credential switchover pretty shortly after the run, so we don't really need to have both passwords valid at a time.
Eventually, we'll get this automated, so we will soon™️be able to have a closed loop with no human intervention.
3 participants
Adding the acm-member-portal deployment. This is an Azure and Kubernetes deployment via Terraform.
This will require both access to Azure via a managed-identity and also on-prem access to deploy the Kubernetes secret.
This will likely not work until the on-prem runners are active again.