I'm trying to solve a problem with AWS IAM policies.
I need to allow certain users to only delete/modify resources that are tagged with their particular username (This I've solved) while also being able to create any new aws resource.
The part I haven't solved is need to be able to create resources without ability modifying any existing resources (unless they have the right tag).
Is there an existing AWS policy example that allows a user to create any resource (without granting delete/modify)? Is there a way to allow this without having to list every single aws offering and continuously update it for new offerings?
AdministratorAccess will give all rights to create all services.
See https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html#jf_administrator
I managed to solve this problem with a rather ugly solution, but as far as I can tell it's the only solution.
I found a list of all aws actions: https://github.com/rvedotrc/aws-iam-reference
I then parsed out potentially troubling functions like anything with Delete or Terminate in the action name. I used vim/grep for this.
After that I broke that up into multiple aws_iam_group_policy statements. Each statement was attached to a corresponding group. The target users are then added to each of those groups.
Unfortunately, this is pretty ugly and required 5 different groups and policies, but it's the solution I arrived at.
Related
I need to recreate a new User Pool with exactly the same settings as another one and I am wondering what is the best way to do it, or if it is a standard way that I am not aware of. (maybe a faster way than using the AWS console)
My guess is, using AWS CLI :
Get user pool details: describe-user-pool
Then create a new one with the same details : create-user-pool
Any thoughts?
You should first import the resource to CloudFormation, then copy the template and deploy it as a new stack. This will give you better control over the desired configuration of the resources. Ensure you set the retention policy to retain. Losing a user pool is no fun.
It seems there is still no support for importing Cognito user pools into CloudFormation. My recommendation remains that you should be maintaining your infrastructure as code, particularly if you wish to replicate it across environments. How you accomplish it is a little more convoluted but you should just iterate on your CFN template until the configuration matches. Or if you are up for it, terraform has tooling to help you import resources
So! To answer my own question after some time gaining related experience.
The best way to go is like #AndrewGillis said:
Hold your Infrastructure As Code.
My preference I use Terraform.
If given the correct permissions, Lambda functions will automatically create CloudWatch log groups to hold log output from the Lambda. Same for LambdaEdge functions with the addition that the log groups are created in each region in which the LambdaEdge function has run and the name of the log group includes the name of the region. The problem is that the retention time is set to forever and there is no way to change that unless you wait for the log group to be created and then change the retention config after the fact.
To address this, I would like to create those log groups preemptively in Terraform. The problem is that the region would need to be set in the provider meta argument or passed in the providers argument to a module. I had originally thought that I could get the set of all AWS regions using the aws_regions data source and then dynamically create a provider for each region. However, there is currently no way to dynamically generate providers (see https://github.com/hashicorp/terraform/issues/24476).
Has anyone solved this or a similar problem in some other way? Yes, I could create a script using the AWS CLI to do this, but I'd really like to keep everything in Terraform. Using Terragrunt is also an option, but I wanted to see if there were any solutions using pure Terraform before I go that route.
When building lambdas for example using cloudformation. It is easy to start allowing a little too much by allowing * on resources and eventually ending up hardening/tightening your security. Is it somehow possible to view which permissions actually are in use? And by that way, figuring out what the minimal set of permissions that is needed.
This is a popular request. One option is to leverage Netflix's Aardvark and RepoKid. Another is to ensure that CloudTrail Logs are enabled and then find a way to query them (for example using Athena).
Have you tried:
AWS Policy Simulator
I have not seen anything exactly as you described, but I believe this tool would actually in the end give you what you need and also make you more and more familiar with all of the policies in IAM.
By looking at the documentation on DynamoDB, I was able to find some examples of restricting item access for users based on the table's primary key. However, all of these examples only cover restricting access to a single user. Is there a way to allow access only for a group of users? From what I've read, this would come down to creating IAM groups/roles, but there is a limit on how many of each can be created, and it doesn't seem like doing so programmatically for each item would work well.
Your guess is correct; you would need an IAM policy per shared row.
There are no substitution variables currently available as far as I know to get the group(s) a user is part of, so no single IAM policy will be able to cover your use case.
Not only that, only the partition key can be matched with conditions in the IAM policy, so unless your partition key has a group name as part of it (which implies that users can never change groups) you will require, as you imply, an IAM policy per row in the database, which won't scale.
It could be acceptable if you have controls in place to limit the number of shared items, and are aggressive about cleaning up the policies for items that are no longer shared.
I don't think using AWS's built-in access controls to allow group access is going to work very well, though, and you'll be better off building a higher-level abstraction on top that does have the access control you need (using AWS Lambda, for example).
There are similar questions around but none seem to quite answer me directly (or I'm too new with AWS to connect the dots myself.) Apologies if this was easily searchable. I've been trying for many days now.
I want to create a policy that I can assign to IAM users for my Glacier that will allow any IAM user the right to create a vault and then allow them access to most rights for the vaults that they've created. (basically all but delete)
The use case/scenario is this: I have multiple Synology NASes spread at multiple sites. I presently have them all backing up to the glacier account each using their own IAM creds. So far so good.
The problem becomes when they need to do a restore (or even just a list vaults) they see all vaults in the account. I do not want them to see other NAS's vaults/backups as it can be confusing and is irrelevant to that site.
So far I'm simply doing all Glacier ops myself but this will not scale for us. (We intend to add about 25 more NASes/sites, presently running about 8-10)
My assumption is that I should be able to do this somehow with a condition statement and some variant of vaults/${userid} but not quite finding/getting it.
I can't affect anything at vault creation (like adding a tag) because it's the Synology Glacier app creating the vault so no way to mod that.
I've seen some solutions for like EC2 that use post-hoc tagging. I'd prefer not to go that route if I can avoid it as it involves other services we don't use and I know little to nothing about (CloudStream(?), CloudWatch(?) and Lambda I think).
I've also thought of multiple and linked accounts which, if it's the only way then I will, but with no ability to move vaults to the new account - meaning gotta start over for these 8 - it's a less attractive option.
Seems like a policy for this should be easy enough. Hoping it is and it's just a few clicks over my current Policy writing skills.