I’m looking forward to Atmos secrets management. We use Sealed Secrets for our application layer since everything runs on Kubernetes. Managing secrets as code makes deployments much more portable across regions and accounts. However, for our infrastructure layer, secrets are stored in Secure SSM Parameters and Secrets Manager. The lack of portability has become a small pain point when managing a DR region, so I’ve been considering a move to SOPS. After another practice run of our DR runbook last week, I’m definitely making the switch soon. The timing of Atmos secrets management with SOPS support couldn’t have come at a better time.

Very cool!

OK, no problem. I plan on using SOPS with a multi region AWS KMS key. Is this possible with that Atmos ? I’ve only skim the documentation.

Thanks for kicking the tires. If you find any bugs let me know, and we'll get it sorted before the next release.

The DX using it with aws kms is not great. I have to wrap all my

atmos secret

commands that with

atmos auth exec

. It would be nice to if

atmos

internal sops calls can use the atmos identity via

-i

flag, stack's default identity, explicit identity set via atmos secrets config, or a combination of all of them.

on it!

Thank you. I submitted another bug report for

atmos secret list

. I did use AI to confirm my suspicions and draft a GH issue afterwards. I hope that isn't a problem. https://github.com/cloudposse/atmos/issues/2639

(I'm working on a fix for the other issue on how we handle KMS with SOPS)

Nice. I

git checkout

your branch, built

atmos

, and tested. The stack's default identity works.

We use Sealed Secrets for our application layer since everything runs on Kubernetes. Managing secrets as code makes deployments much more portable across regions and accounts.

So another thing coming out, hopefully in the next release, will be native Kubernetes manifest support

I have on our roadmap introducing atmos to our application repos. It's something I plan on working on once that gitops feature is released.

That's awesome and aligns well with our vision.

By emulators, do you mean floci/localstack/k3s? At this time, we do not run floci or localstack. As for k3s (or

kind

), we do use it. Our developers are basically abstracted away from k8s. Locally, we use tilt.dev (I cannot say enough good things about it) paired with k3s. Our application integration tests use it too. In short, I dont think emulation is a pain point here. However, I have been interested in most of atmos features released to this point, so I dont rule anything out.

I found your new Emulators PRD. I do like what I am reading. Especially, that you're not reinventing the wheel. It appears the intent is to abstract floci, localstack, k3s, etc similar to the way it abstracts terraform/opentofu. This might be very useful. I am very conservative when it comes to changing application developers workflows and tooling. A self imposed requirement is any changes that I push on to our developers must be meaningful improvement. Hence the reason I have yet to introduce

atmos

in our app repos. I think it's safe to say introducing

atmos

to our developers now will be a meaningful improvement. They can use atmos auth (to lesser extent), toolchain, workflows (both interactive and repeatable ones for local and ci env), and gitops. And eventually secrets management and emulator. Anyways, I could see myself testing it out on our app repository once I have introduce atmos to our application project.

Yes, exactly. Also, there's a lot of new features so it will probably take a little bit of burning in before all the kinks are worked out, but the goal is to provide the best possible DX from dev to prod, supporting the most common deployment patterns.