FAQ | This is a LIVE service | Changelog

Update Sanctuary guidance

Description

Following our attempts to use this in Digital Admissions, we encountered the some issues related to the creating of secrets using Sanctuary. I've left the task list blank, would like folks who understand the intended process here better to review the problems we hit - I'm no terraform pro, and some of the issues may just be around documenting things better.

Creating secrets

  1. We needed to make a data.google_secret_manager_secret_version to pull in the latest version of our secret. If we didn't do this, terraform would not notice any changes to the secret to then apply to resources that use it. I think this needs documenting in the example.
  2. However, this did not appear to be able to be created through terraform until the secret already existed, forcing us to do a targeted terraform apply to create the secret. The best I could achieve on this was making the latest version depend on the "initial" one, but that still causes errors where we try and use the secret on plan. This may be fixable with clearer guidance of how to use the secret value at this point..?
│ Error: Invalid count argument
│ 
│   on /terraform_data/modules/webapp_secret_settings/main.tf line 17, in resource "google_secret_manager_secret_version" "secret":
│   17:   count = var.secret_data == null ? 0 : 1
│ 
│ The "count" value depends on resource attributes that cannot be determined until apply, so Terraform
│ cannot predict how many instances will be created. To work around this, use the -target argument to
│ first apply only the resources that the count depends on.
  1. If we are forced to do a targeted terraform apply to create the secret, then we get no value from creating the "initial" secret version. We can create the secret with a targeted apply, make the first version with sanctuary, and then run terraform normally. I don't think this is the intended practice from the docs.
  2. If we do have to create an initial version - the example in the doc has you set it to the empty string. This does not work, google's API rejects it. I believe this needs updating in the docs.

Using created secrets

  1. We couldn't use sanctuary to directly populate secrets we could use in our Django app, by the recommended route of loading in the secret through the secret URLs. This is because we could only use the field labels on 1Password - username/password. We had no way to map these to less generic values, e.g. "MAIL_HOST_USER".
  2. We were left loading in our secrets and using them to populate other secrets defined in terraform where we could then map them. This did give us more clear control of when the updated secret would be applied, but the complexity of updating secrets with sanctuary to then update other secrets using terraform is a little confusing.
  3. Guidance on the best practice ways to load in secrets would be appreciated (note: may exist now, since we started this task 2 months ago...).

Task list

  • Update sanctuary.md to create secret using DevOps gcp-secret-manager module with manage_secret_versions = false
  • Update sanctuary.md to include example of reading in latest version of secret using data.google_secret_manager_secret_version, if required to be used directly.
  • (Do we need to document the recommended strategies of using the secrets here too)
Edited by Paul Horrocks