Hi Piotr,
The answer to this question influences the answer to your other questions:
Why these components cannot be multi-space scoped?
The simplest explanation is because Certificates, Accounts, and Library Variable Sets can be scoped to environments, tenants, and tenant tags. Each space can have different environments, tenants, and tenant tags.
For example, in the Default space you have Development, Test, Staging, and Production as the environments. In the RandomQuotes space you have Test, UAT, and Production as the environments.
For simplicities sake, let’s focus on Accounts (you’ll encounter the same issue for Certificates and Variable Sets variables). In this example you have three accounts in the default space:
- Dev/Test Account: Scoped to
Development and Test
- Staging Account: Scoped to
Staging
- Production Account: Scoped to
Production
In this scenario, you want to share Accounts with both the Default space and the RandomQuotes space. But, there is a delta between the two spaces.
- Dev/Test Account: The environment
Test appears in both spaces, but not Development. Should this account be skipped because the environments don’t match? Should it be copied over but only scoped to Test in the RandomQuotes space? Or, should it be skipped?
- Staging Account: The environment
Staging does not appear in the RandomQuotes space. However, it has UAT. Is that the same thing? Should it be copied over without any scoping? Or should it be skipped?
- Production Account: Both spaces have
Production, this is easy, copy it over.
That was a simple example, Variables are much, much, much more complex due to the fact that:
- A variable name can have multiple values (with different scoping)
- A variable value can be scoped to 0 to N items (environments, tenant tags, targets, target roles). Making detecting when a “new” variable very tricky.
We don’t have plans to solve this particular problem in the near future.
Please note: Step templates don’t have this problem as they are not scoped to anything.
One of our ideas is use (for example) Octopus Terraform Provider and sync each space with data that should be shared and keep it in the version control system.
That probably would work assuming all spaces you wish to sync have the same environments and tenant tags and you don’t assign anything directly to a tenant.
We are about to embark on this very thing for our samples instance.
However, some items to consider:
- Accounts by their very nature contain sensitive data. I’d leverage a key vault + TF vars to keep those items secure and out of source control.
- Certificates can contain passwords. Again, I’d use a key vault + TF vars to keep those items secure and out of source control.
- Variables can be marked as sensitive. Just like before, use a key vault + TF vars to keep those items secure.
You might be asking how can I use a key vault plus variables? I’d recommend using a runbook to run your terraform scripts. We have step templates that integrate with various key vaults. Using Azure Key Vault with Octopus - Octopus Deploy
I hope that helps!