How to handle "sensitive terraform output" ? Hi, sorry to come back to this but after having read https://github.com/cloudposse/atmos/blob/osterman/secrets-management/docs/prd/secrets-management.md , I don't understand how to deal with terraform sensitive outputs, and pass them properly to • other terraform components • other helm or ansible components The secrets-management PRD does not seem to address this, as it focuses on manually defined secrets, using the atmos cli. I would expect a store-like mechanism that allows "connecting" stack outputs to stack inputs for sensitive information, leveraging some "safe intermediate storage". I feel like (am I wrong?) that SSM parameter store for example could maybe be an easy win, as it supports SecretStrings, and is supported as an atmos store already. Setting the parameter type as SecureString if the output is set as sensitive might be possible? Sure, it would change the definition/scope of atmos stores, but again, there is a gap here that secret-management does not fill.

We definitely plan support for this, but cannot comment on when we can begin the implementation.

@Erik Osterman (Cloud Posse), I see no clue in this PRD that it will address the concern/need I raise, as it clearly states it focuses on secrets as "cli-based human configuration", whereas I'm asking about secrets as stack sensitive outputs. If you do intend to address this, you might want to make it more explicit in the PRD. If you don't, please let me know how you would see this 🙂.

You’re right: the secrets management PRD intentionally scopes itself to human-provisioned secrets (API keys, tokens managed via CLI), and doesn’t cover sensitive Terraform outputs flowing between components.

Cool ❤️ ! Will they all be implemented at the same time, or is there a chance you take care of the ssm parameter store sensitivity soon(er)?

It's not yet scheduled for implementation. But I hope we can get to it in April.

Ok, thanks. For the record, in case it matters, I just tried to retrieve a manually created SecureString parameter with the ssm store, and it seems it currently retrieves the encrypted value, or at least, some blob rather than the expected value.

I can't recall exactly, but I believe we didn't implement secure store so it wouldn't be used insecurely.