Hey everyone! I'm new to AWS IAM and I want to add a novice user to my development account. The goal is for them to run Terraform to manage resources like EC2 and S3. I'm planning to give them access to the AWS console so they can create their own access keys instead of me sending them one directly, just trying to stick to best practices here. However, I don't want them to have full access to mess with these resources through the console.
I've placed them in my TerraformDev group, which has the TerraformDev policy attached. Now, I want to create an additional policy to explicitly deny access from the console. I tried implementing `aws:CalledVia`, but I couldn't find a suitable service name to utilize. I created a policy that denies access to various resources, but it ended up blocking access from the command line as well.
Here's the policy I tried:
```
{
"Sid": "DenyInfraInConsole",
"Effect": "Deny",
"Action": [
"ec2:*",
"s3:*",
"rds:*",
"eks:*",
"lambda:*",
"dynamodb:*"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ViaAWSService": "false"
}
}
}
```
What's the right way to restrict console access while still allowing limited command-line usage? Or is there a more effective way to achieve what I'm after? Appreciate any guidance!
4 Answers
Just a heads up, IAM users can create access keys even without console access. If they need console access just to check on deployments, consider giving them read-only permissions instead.
Instead of using IAM users and having them create their own credentials, consider adopting IAM Identity Center (previously known as AWS SSO). This way, they can authenticate via the browser, which eliminates the need for long-lived credentials. It's a much more secure method. Plus, in the long run, think about setting up a CI/CD pipeline to manage Terraform runs, as that would further secure things.
True! IAM Identity Center can handle temporary keys for you, which streamlines the process.
Honestly, the best approach is to have a CI service handle running Terraform for your developers. This removes the need for restricting access altogether, though it does mean they can't run their own local experiments. You could also try setting a condition on `aws:UserAgent` to match the Terraform user agent, but be aware that it's not foolproof since user agents can be spoofed.
Got it, thanks! I’ll focus on getting my CI workflow sorted out properly.
I also struggle with using code blocks on forums like this!
Thanks! I wanted to avoid the initial complexity of SSO, but if it’s the only option, I guess I’ll dive into it. I’m almost ready to switch to a pure pipeline for Terraform; I've just been dealing with minor hiccups when running it locally. An extra command line access could still be handy though.