serverless (function/container/namespace): import resources with secret environment variables

[norbjd]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Context

We can't really import serverless resources (namespaces, functions, containers) who have secret environment variables. By their nature, secret environment variables are sensitive, and therefore, not returned in plain text when GETting the resource.

However, a value hashed with Argon2id algorithm is returned by the API (see for example the documentation for functions):

{
  "name": "func1",
  "secret_environment_variables": [
    {
      "key": "env_var_1",
      "hashed_value": "$argon2id$v=19$m=65536,t=1,p=2$c29tZXNhbHQ$RdescudvJCsgt3ub+b+dWRWJTmaaJObG"
    }
  ]
}

Sadly, instead of leveraging this hashed value, the current implementation of the Terraform provider discards the secret environment variables: after importing a resource, the secret_environment_variables field will always be null.

This is unfortunate, as running terraform import followed by terraform apply will redeploy the resource, as secret_environment_variables changed from null to a non-null value. Thus, it will always trigger an unnecessary deployment, in the case of function and container. Or even worse, in the namespace case, as updating secrets of a namespace will redeploy all functions/containers inside.

After the first apply and the "unnecessary" redeployment, the secret environment variables will be stored in the state, so the next apply operations will behave correctly though, because now the variables are stored in the state. However, another issue is that these variables values are stored in plain text in the state, while we can technically reuse the hashed value to compare, and this would simplify managing the secrets in the import case.

Description

We could actually solve both issues (import does not set secrets + secrets values stored in plain text in the state) at the same time:

1. instead of storing the real secret value in the state, store its hashed value returned by the API
2. when importing a resource with secrets, just fill the secret_environment_variables field with the values returned by the API
3. when updating a resource, check if the secrets match the existing ones. As the hashed values are hashed with Argon2 algorithm, we can use this library and ComparePasswordAndHash method to decide if one of the values has changed. If a single value of a secret has changed, we can update the secrets; if not, we don't have to update

I don't think that changing the state internal values is a breaking change (but I might be wrong).

New or Affected Resource(s)

• scaleway_function_namespace
• scaleway_function
• scaleway_container_namespace
• scaleway_container

Potential Terraform Configuration

Experience should be the same as today.