feat(terraform)!: access backend behind firewall #261
Conversation
|
Good stuff 😄 I think this needs to be done for both the Also to clarify, as far as I understand this wouldn't help with managing resources behind a firewall, but it'll allow you to use a backend with behind firewall. Also remember to pin untrusted Actions to commit, ref. |
sebastianlolv
changed the title
.github/workflows/terraform.yml
Outdated
| subscription: | ||
| description: The subscription to deploy in | ||
| type: string | ||
| required: true | ||
|
|
There was a problem hiding this comment.
Is this not just a duplicate of the secret AZURE_SUBSCRIPTION_ID?
There was a problem hiding this comment.
Can you use the subscription id on --resource-group tag inline command, if so, yes I think we can scrap that then.
There was a problem hiding this comment.
Can rather rename it to project_name or something similar? Since we need to reference it in the key vault name?
There was a problem hiding this comment.
Didn't even notice that we're talking about a Key Vault here, and not a Storage account 😅
How would this work if you're running a Terraform config with multiple or no Key Vaults? 🤔
There was a problem hiding this comment.
No idea 😅 I think I might have read this wrong, looks like they whitelist it in the tfstate storage accounts when I look at Radix's version of it. 😅 I can turn it into something like what they have done.
Where would you put the Revoke step in the terraform-plan job? |
|
I think it would be a good a idea to add the IP at the start of each job, then remove it again at the end of each job. If not, then you might leave the firewall disabled for a very long time if the Apply job is not run right after the Plan job 🙂 |
.github/workflows/terraform.yml
Outdated
| container_name: tfstate | ||
| key: ${{ inputs.environment }}.${{ inputs.project }}.terraform.tfstate | ||
| resource_group_name: ${{ inputs.project_id }}-tfstate | ||
| storage_account_name: st${{ inputs.project }}infra${{ inputs.environment }} |
There was a problem hiding this comment.
Maybe we could consider updating the terraform-backend.sh script to store the backend config in a file, then pass that to this workflow so that the backend config can be read from it?
Then we could pass that same file to our Terraform config, using partial backend config: https://developer.hashicorp.com/terraform/language/settings/backends/configuration#partial-configuration
There was a problem hiding this comment.
Would remove duplication of backend configuration, since with the proposed approach, we'd define backend config in both Terraform and GitHub Actions, if that makes sense 🤷
hknutsen
changed the title
|
Pushed some WIP code. |
|
Please note that this would require the service principal to be assigned role |
|
Linter currently throws error on duplicate code, which was expected. Will look into a more elegant solution. |
hknutsen
changed the title
|
After some testing, I'm starting to think that this might not be the best idea.
Maybe it would be possible to get a dispensation for Storage Accounts used as Terraform backends? Or maybe wait for this? github/roadmap#614 |
|
We could wait for that feature and try it, it looks like its in the Q4 2023 roadmap and could be released within the next months |
|
Considering this as stale for now. |
Temporarily whiteliet github runner IP to firewall protected key vaults incase you need to create secrets etc. with Terraform.