Hi! There's been a change to

<http://providers.tf|providers.tf>

rolled out to many AWS Security Suite components (AWS Config/GuardDuty/SecurityHub), which broke my legacy GitOps Atmos workflow. More details here: • https://github.com/cloudposse-terraform-components/aws-guardduty/issues/56 I did not make a PR as I'd like to know if it's my stack that is outdated w.r. to newest Atmos best practices, or if that is a genuine regression. Thanks so much 🙏 cc: @Andriy Knysh (Cloud Posse)

@Alek I'd say "that is a genuine regression" We created the major versions of the security and compliance components with two changes: • Make the

account-map

optional (the user would provide the static account map in a variable - we are making the same change to all our components) • Use Atmos Auth (https://atmos.tools/cli/commands/auth/usage) to provide credentials at run-time The second item works when you use Atmos Auth, but it broke it for you (apologies for that). Let us discuss internally how do we proceed in this case. You can do one of the following for now: • Don't use the major versions of the components yet (stay at the previous versions for now) • Use the new major versions, but don't vendor the

provider.tf

files, use your local

provider.tf

(you can add it manually, or using

atmos vendor pull

from a remote or local location) • Consider using Atmos Auth (that's a major undertaking depending on what you are using now) We'll discuss that, maybe we will create new releases that support both ways. We'll let you know. Thanks

Thanks for letting me know! 🙏 For context, we are running a legacy GitOps model with per-account

terraform

roles and central

identity

roles living in

core-identity

. We're also consuming the account map dynamically via outputs. Our entire AWS deployment has been build with Atmos about two years ago, and completely abandoned since. So many of our components are locked on old versions, and I've been upgrading them to newest versions whenever possible (often resolving breaking changes). > Use the new major versions, but don't vendor the

provider.tf

files This is what I am doing right now -

provider.tf

is patched to support legacy assume role flow on newer component versions. Ideally, I'd love for both auth strategies to be supported so we can vendor the upstream. > Consider using Atmos Auth I don't yet fully grasp what it will take to migrate our infra to Atmos Auth, but if that's a "gold standard", we would prefer using that.

I would say

atmos auth

has gone platinum 😉

> We use it everywhere, but it could be a big lift if the infra is that old I personally am a happy user of

aws-vault

and Nix, and am not even using the Geodesic shell. This is my conscious choice and I Atmos worked well with this stack so far. But I am open to try

atmos auth

, especially if it's required with newer component versions. That said, having proper migration guides, deprecation notices, and visibility would go a long way here - even something as simple as "This component version requires Atmos Auth. To use it, please follow a migration guide here." in

README.md

, release notes, or even a commit message/PR, would clarify things a lot for legacy tooling users (given the migration path is clear/possible for legacy stacks). I only worked with Atmos for six months, but so far this is the first time where a component upgrade requires foundational change to tooling/IAM structure.

This component version requires Atmos Auth. To use it, please follow a migration guide here.

@Andriy Knysh (Cloud Posse) in the release notes of the major version update, we should call this out. Technically atmos uath is not required, but we're moving all role assumption out of terraform, so the caller can decide how to obtain credentials. Atmos auth solves that.

Thank you for the article. 🙏 It is exactly what I needed.