I am checking the steps of setting up IAM auth in RDS: https://aws.amazon.com/premiumsupport/knowledge-center/users-connect-rds-iam/ And one of the steps is to attach the IAM role with proper permission: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.IAMPolicy.html
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds-db:connect"
],
"Resource": [
"arn:aws:rds-db:us-east-2:1234567890:dbuser:db-ABCDEFGHIJKL01234/db_user"
]
}
]
}
The resource follows this format:
arn:aws:rds-db:region:account-id:dbuser:DbiResourceId/db-user-name
If I understand correctly, as long as I know someone's account-id, DbiResourceId and db-user-name (or maybe db-user-name as I can use wildcard?), then I am able to connect to that DB instance, right?
This sounds insecure. Did I miss anything?
No this would not be possible. The only want to interact with this resource would be to assume a role in the target account.
You can use an IAM role to allow someone (a trusted principal) in a different account to access resources in your account. Roles are the primary way to grant cross-account access. However, with some AWS services, you can attach a policy directly to a resource (instead of using a role as a proxy). To learn the difference between roles and resource-based policies for cross-account access, see How IAM Roles Differ from Resource-based Policies in the IAM User Guide
Related
It seems to be impossible to allow developers to create Lambdas and create or maintain SAM Applications in AWS without essentially having AdministratorAccess policies attached to their developer's role. AWS documents a suggested IAM setup where everyone is simply Administrator, or only has IAMFullAccess, or a even more specific set of permissions containing "iam:AttachRolePolicy" which all boils down to still having enough access to grant the AdministratorAccess permission to anyone at will with just 1 API call.
Besides creating a new AWS Account for each SAM or Lambda deployment there doesn't seem to be any secure way to manage this, but I really hope I'm missing something obvious. Perhaps someone knows of a combination of tags, permission boundaries and IAM Paths that would alleviate this?
The documentation I refer to: https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-permissions.html which opens with:
There are three main options for granting a user permission to manage
serverless applications. Each option provides users with different
levels of access control.
Grant administrator permissions.
Attach necessary AWS managed policies.
Grant specific AWS Identity and Access Management (IAM) permissions.
Further down, a sample application is used to specify slightly more specific permissions:
For example, the following AWS managed policies are sufficient to
deploy the sample Hello World application:
AWSCloudFormationFullAccess
IAMFullAccess
AWSLambda_FullAccess
AmazonAPIGatewayAdministrator
AmazonS3FullAccess
AmazonEC2ContainerRegistryFullAccess
And at the end of the document an AWS IAM Policy document describes a set of permissions which is rather lengthy, but contains the mentioned "iam:AttachRolePolicy" permission with a wildcard resource for roles it may be applied on.
AWS has a PowerUserAccess managed policy which is meant for developers. It gives them access to most of the services and no access to admin activities including IAM, Organization and Account management.
You can create an IAM Group for developers (Say Developers) and add the managed policy PowerUserAccess to the group. Add developers to this group.
For deploying with SAM, the developers would need a few IAM permissions to create roles, tag roles. While rolling back a CloudFormation Stack, they may need a few delete permissions. While allowing the developers to create new roles for Lambda functions, you need to ensure they don't escalate privileges by using permissions boundary. A good starting point again would be to set the permissions boundary to PowerUserAccess. (until you figure out what is the right level of permissions)
Create a Policy something like this
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ReadRole",
"Effect": "Allow",
"Action": [
"iam:GetRole",
"iam:GetRolePolicy",
"iam:ListRoleTags"
],
"Resource": "arn:aws:iam::ReplaceWithYourAWSAccountNumber:role/*FunctionRole*"
},
{
"Sid": "TagRole",
"Effect": "Allow",
"Action": [
"iam:UntagRole",
"iam:TagRole"
],
"Resource": "arn:aws:iam::ReplaceWithYourAWSAccountNumber:role/*FunctionRole*"
},
{
"Sid": "WriteRole",
"Effect": "Allow",
"Action": [
"iam:DeleteRole",
"iam:DeleteRolePolicy",
"iam:AttachRolePolicy",
"iam:PutRolePolicy",
"iam:PassRole",
"iam:DetachRolePolicy"
],
"Resource": "arn:aws:iam::ReplaceWithYourAWSAccountNumber:role/*FunctionRole*"
},
{
"Sid": "CreateRoleWithPermissionsBoundry",
"Effect": "Allow",
"Action": [
"iam:CreateRole"
],
"Resource": "arn:aws:iam::ReplaceWithYourAWSAccountNumber:role/*FunctionRole*",
"Condition": {
"StringEquals": {
"iam:PermissionsBoundary": "arn:aws:iam::aws:policy/PowerUserAccess"
}
}
}
]
}
Note: It assumes the Lambda function names in the SAM template contains the word Function in them. (Replace the AWS Account Number in the ARNs).
Now you can attach the above policy to the Developers IAM Group. (This would give the SAM deployment permissions to all the developers)
Or you can create another IAM Group for SAM developers (Say SAM-Developers) and attach the above policy to the SAM-Developers group. Now add the appropriate developers (who need to deploy using SAM) to this new IAM group (SAM-Developers).
Define the Permissions Boundary in the SAM templates as well.
Here is an example PermissionsBoundary in SAM template.
Globals:
Function:
Timeout: 15
PermissionsBoundary: arn:aws:iam::aws:policy/PowerUserAccess
With that, the developers should be able to deploy using SAM provided they do not have any restrictive permission boundary.
You can set the permission boundary to AdministratorAccess for the developers or create a new Policy which combines the permissions of PowerUserAccess and the above defined policy for 'SAM' deployments. Then set this new Policy as the permission boundary for the developers.
This solution is for reference and you can build upon this. The PowerUserAccess has been set as the permissions boundary for the Lambda function roles. The PowerUserAccess is too permissive and you should further work on this to find out the right level of permission for your developers and the Lambda functions.
Sidenote: You can use this policy to allow the users to manage their own credentials.
Can a role be assumed if it does not have a Trust policy?
If a given IAM user has an attached identity based policy saying that he/she can call sts:AssumeRole for a given role (inside the same account), but the user is not described in the Trust policy of this role, will he/she be able to assume the role?
Usually only the resource based policy or the identity based policy should be enough to give rights for the user, but is it different for the roles?
Thanks
will he/she be able to assume the role?
Yes, of course she/he will be able to do it, as long the trust policy allows the account to assume the role. For example, a role has to have the trust policy of:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "<account-number>"
},
"Action": "sts:AssumeRole",
"Condition": {}
}
]
}
This way, your IAM user does not need to be explicitly listed in the trust policy, but trust policy is required and at least you should specify the account which can assume it. But the drawback is that any IAM user or role from the <account-number> account that has sts:AssumeRole permissions can assume the role.
it does not have a Trust policy?
Trust policy is required, so you can't have a role without such such a policy.
Update
Lets assume you have a role with a trust policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::xxxxxx:user/UserA"
},
"Action": "sts:AssumeRole",
"Condition": {}
}
]
}
The role can be assumed only by userA. UserB will not be able to assume this policy, regardless of his permissions.
A Trust Policy specifies the "Principal" which can assume the role it is attached to. That principal can be various different types of entity, such as an AWS service (e.g. to create a role applied to EC2 instances), or the identifier of another AWS account (to grant cross-account access). It cannot be omitted or be a wildcard.
If the principal identifies an AWS account, then it is trusting the AWS account as a whole. In a sense, all users in that account have been included in the trust policy, but to assume the role they also need permission to make the appropriate AssumeRole API call. This delegates responsibility to the administrator of the other AWS account to decide which users should be able to assume the role.
This can be used to create a hierarchical arrangement of accounts:
All users are created in a single AWS account, which has no other resources.
The actual resources - EC2 instances, S3 buckets, etc - are in separate AWS accounts.
Each account defines roles granting access to some of these services, with a trust policy listing the central account as the Principal. These roles do not list individual users or groups as trusted, they just define sets of permissions.
The users in the central account are each granted AssumeRole access to an appropriate subset of the roles in the different accounts. The effect is similar to using Groups or Managed Policies to grant multiple users the same access.
What is (or should be) the relationship between a S3 bucket policy and its designated administrator's user policy?
E.g. suppose I've newly created a bucket:
$ aws --profile admin --endpoint-url http://localhost:4572 s3 mb s3://foo
make_bucket: foo
I want user bucket_admin to be able to administer the bucket (not necessarily exclusively). To do this, should I create/apply a bucket policy along the lines of:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:*"],
"Principal": { "AWS": "arn:aws:iam::000000000000:user/bucket_admin" },
"Resource": "arn:aws:s3:::foo/*"
}
]
}
...or create/apply a user policy along the lines of:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect":"Allow",
"Action":["s3:*"],
"Resource":["arn:aws:s3:::foo/*"]
}
]
}
?
Your bucket policy applies to only one principle, the bucket_admin user. It can't be used by a role, other IAM user or a group, if you want to have more identities being able to administer the bucket.
The IAM policy does not have a principle by definition. It means you have to attach it to an identity, such as IAM role, user or group. This gives you more flexibility on how to distribute the permissions to the bucket. It can be only the bucket_admin, or you can create a group of bucket admins, or have role which can be assumed by an EC2 instance.
Also with IAM policy it is easier to check who/what is using it. You just go to IAM console, and to Policy Usage and you will get a list of all identities which use the policy. With bucket policies, you have to go manually over all buckets and inspect their policies to check who can be admin of buckets.
Good general comparison of resource vs IAM policies is here:
Identity-Based Policies and Resource-Based Policies
Also useful read as IAM policies can be attached to roles:
How IAM Roles Differ from Resource-based Policies
In addition to #Marcin's answer, which is great...
We use bucket policies mostly for bucket-level checks - ensure the traffic is SSL, ensure the traffic originates from a specific VPC, etc.
Using roles attached to IAM users is an easier way of controlling user access.
The exception is where a user is trying to access a bucket in another account - in this case, both a bucket policy and an IAM policy is needed https://docs.aws.amazon.com/AmazonS3/latest/dev/example-walkthroughs-managing-access-example2.html
I am trying to create an IAM user and I want to assign the user for Full S3 Access using IAM role (via console access). I know I can do that using Group or attaching the S3FullAccessPolicy directly to the user. I am unable to do this and could not find any help regarding this. The articles I come across describes how you can attach IAM policies to EC2 instance etc.
I managed to create a role and attached a trust policy as below. I also attached the policy "AmazonS3FullAccess" to the role.
But it never worked if I login using AWS management console (browser). It still denies all permission to the user for S3 access. The trusted entities policy looks like below - the IAM username I am trying to use is s3AdminUserWithRole. Th eAWS account id is 6XXXXXXXXXXX0
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::6XXXXXXXXXXX0:user/s3AdminUserWithRole",
"arn:aws:iam::6XXXXXXXXXXX0:root"
]
},
"Action": "sts:AssumeRole",
"Condition": {}
}
]
}
Is it not possible to do like this for AWS Management console for a user? We have to use only Groups /managed policies/ inline policies and NOT roles for this? Confused about the AWS documentation then.
Based on the comments, the solution is to use sts service and its assume-role API.
For Console there is Switch Role option.
I am new to AWS IAM and I am learning to do a security audit for AWS.
For a specific user in AWS the JSON permissions policy looks like this (Account no changed of course)
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": [
"arn:aws:iam::111111111111:role/APP-NonProd-BC",
"arn:aws:iam::111111111112:role/APP-nonProd-Admins",
"arn:aws:iam::123456789011:role/APP-nonProd-AdminAccess-Role",
"arn:aws:iam::111111111111:role/App-NonProd-S3Ops",
"arn:aws:iam::111111111111:role/APY-nonProd-EC2Admin"
]
}
}
My question is - Where I can find the permissions for each of the resources. Means, for APP-nonProd-BC resource : what kind of permissions apply?
For APP-nonprod-AdminAccess-Role : is it really have Admin Access or its just named as AdminAccess and where I Can find the permissions definitions ?
I searched in permissions but not able to find relevent for each of the resources "App-nonProd-BC" or App-nonprod-adminaccess-role" etc. Kindly help.
These are rules to allow the User to assume these roles. Look within the IAM roles defined and you should be able to see the associated permissions. Permissions can be given to roles, and then user allocated to the roles, so that you can change all the permissions at once and simplify the permission process.