Let the user choose which secret to update, or create a new secret.
Open the user's default editor, prepopulated with the decrypted secret if they are updating one, or empty if creating a new one.
After the editor is closed, let the use choose whether to use the same KMS key as last time, or choose from a list of KMS keys to use for encryption. The keys lookup could be performed in the background while the user is using the editor.
Encrypt the secret and update the Terraform code with the new payload.
The user is then responsible for checking the changes and committing them.
When creating new secrets, it is not clear which file they should be placed into. Perhaps let the user choose? Should it always write into the current directory (the user can decide to move the TF code around afterwards) or should it let the user choose the directory too?
When choosing KMS keys, it is not clear which KMS keys should be options. Perhaps choose from all alias/<name> keys?
The AWS credentials and AWS account used may differ between different directory levels, so a KMS key that works in the current directory might not work for sibling directories. It depends how the project is structured. For this reason, putting secrets higher up in the directory tree could result in keys that can't be decrypted by other directories. Perhaps this is a good reason to always write new secrets to the current directory where it is guaranteed to work. If the project has secrets defined at a higher directory level then it is likely that updating the secret with the same key will not break anything that was previously working.
When creating secrets, maybe look for a data.aws_kms_secrets.terraform data source and put it in there, or create a new data source with that name and put it in secrets.tf in the working directory. That is simpler than letting the user choose. This would rely on https://github.com/claranet/jinjaform/issues/4 so that the file is not clobbered by files in parent directories.
I would like an interactive command that manages https://www.terraform.io/docs/providers/aws/d/kms_secrets.html
It should:
When creating new secrets, it is not clear which file they should be placed into. Perhaps let the user choose? Should it always write into the current directory (the user can decide to move the TF code around afterwards) or should it let the user choose the directory too?
When choosing KMS keys, it is not clear which KMS keys should be options. Perhaps choose from all
alias/<name>keys?The AWS credentials and AWS account used may differ between different directory levels, so a KMS key that works in the current directory might not work for sibling directories. It depends how the project is structured. For this reason, putting secrets higher up in the directory tree could result in keys that can't be decrypted by other directories. Perhaps this is a good reason to always write new secrets to the current directory where it is guaranteed to work. If the project has secrets defined at a higher directory level then it is likely that updating the secret with the same key will not break anything that was previously working.
When creating secrets, maybe look for a
data.aws_kms_secrets.terraformdata source and put it in there, or create a new data source with that name and put it insecrets.tfin the working directory. That is simpler than letting the user choose. This would rely on https://github.com/claranet/jinjaform/issues/4 so that the file is not clobbered by files in parent directories.