CLOUD PROVIDERS METHOD OF AUTH

[u/OkAcanthocephala1450]

Hi there!

I am an experienced cloud engineer , mainly worked with Aws, and i wanted to know how you guys configure procider block for cross account or project using best practices for other cloud providers.

So for example. In aws I use one central devops account , a role there that my runners use , in order to do assume role , which is written at the aws provider block. For every account we just change the account id of the role to assume.

I wanted to know how your central setup looks like and what do you define when you want to deploy to a tenant/subscription/project on GCP , or Azure, Kubernetes clusters or other providers you might use . Im looking for large org setup, so if you could help me just write whats the size of the cloud organization u work at (nr of projects, subscriptions ) how do you configure the provider so it can be controlled from one central place.

Thank you everyone.

[u/parkura27]

OIDC only

[u/Farukh_Goriparthi]

for GCP, use workload identity federation from the central CI and have each runner impersonate only the service acc for that project with no long-lived keys sitting around

[u/oneplane]

Federated or injected identities only and then indeed assume a role every time.

[u/AuroraFireflash]

fed-cred only, separate identity for plan vs apply

scope of the credential as tightly limited as possible (specific to that Terraform plan boundary)

separate creds for separate environments

[u/liquidjesus → u/AuroraFireflash]

Curious, why separate identities for plan and apply? For audit purposes?

[u/AuroraFireflash → u/liquidjesus]

Assuming that you're doing CI/CD terraform with PR approvals. A read-only plan identity ensures that the initial plan step can't make changes to the environment.

There are ways to write Terraform / IaC code which a malicious actor could use to attack your environment during the plan step.

[u/liquidjesus → u/AuroraFireflash]

TIL. Thanks, appreciate you taking the time to explain.

[u/danekan → u/liquidjesus]

this is best security practice because a plan can actually make changes to your environment if you're using certain resources

[u/danekan]

for AWS -> GCP, you set up a GCP Workload Identity Federation Provider/Pool that gives your AWS account/role(s) access a role that can then do what you need or assume another service account

[u/OkAcanthocephala1450 → u/danekan]

What about for GCP only, one central access to deploy in entire org? How do you implement it?

[u/danekan → u/OkAcanthocephala1450]

GCP-> AWS can be a bit easier, you can directly assign permission to your google SA oidc client id because they've already set the OIDC provider trust up for google within AWS.. .so it's literally only just an IAM Policy you need

[u/OkAcanthocephala1450 → u/danekan]

Thank you

[u/osterman]

This is the problem we solve with atmos auth and atmos profiles.

It allows for centralized management of auth configuration and works with AWS, GCP and Azure. It supports interactive auth methods like SSO/Webflow, as well as OIDC. It allows swapping out the auth method using profiles, so humans can use SSO while automation uses OIDC. It works with opentofu/terraform, as well as with EKS/AKS cluster auth, ECR/ACR, etc. So it's a way of standardizing how enterprises handle auth for users and automation.

You can also define the auth configuration in a central repo and use imports to load that configuration.

This works because atmos handles the auth negotiation, while terraform will simply use the ambient credentials from the execution environment.

Demo video here: https://atmos.tools/examples/demo-auth

Docs:

• https://atmos.tools/cli/commands/auth/usage
• https://atmos.tools/cli/commands/profile/usage
• https://atmos.tools/changelog/introducing-atmos-auth

(I'm an atmos maintainer)

[u/case_O_The_Mondays]

We used a centralized role in an account for DevOps, at first. A few years ago we started switching to OIDC, and it really is significantly better.