One of the most requested features is to managed secrets in atmos. We're starting to think about it and how we would support it. We would like to support full CRUD operations on secrets to make it as easy as using Vercel/Heroku, but using cloud backends like ASM/SSM/SOPS/etc but fully extensible (with other backends supported through a registry pattern). It will tie in to the new atmos auth identity system, so you can have different credentials to access different secrets stores, and would support GitHub OIDC out of the box (since that's already supported by atmos auth). On top of that, you'd be able to initialize secrets, with an interactive configuration flow. The write up is here. Please feel free to leave comments. https://github.com/cloudposse/atmos/blob/osterman/secrets-management/docs/prd/secrets-management.md

This is the (literal?) million dollar question. My team currently uses AWS Secrets Manager for CI/IAC purposes. However, I am curious how other teams manage secrets in the cloud with, or without, being concerned about vendor lock (e.g. AWS Secrets Manager is great when you're in AWS, but what happens in the business needs to support, or flat out migrate to, another cloud) 🤔

IMO, you don't generalize for the LCD, but instead you use the corresponding product in that cloud.

if you support secrets in atmos, are you talking about reading and writing? because I can see myself doing

!terraform.stage vpc vpc-id| dev-secret-store dev-vpc/vpc-id

The idea, in the initial release, is to focus on full CRUD on the command line, with !secret read access in the YAML