I am using aws ecs-cli up command and want to restrict the role/group of the caller to the least privilege by using specific permissions.
Is there a flag or way to test run a cli command to validate if all required permissions are availabale to the caller, rather than say iam:*?
Additionally, is there a way to limit the permissions to partial wild-card resource, for example, below I have set * not knowing the full name in advance, so could I add myecs-* for example, that would restrict the resource to some degree?
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1555577550000",
"Effect": "Allow",
"Action": [
"iam:CreateRole"
],
"Resource": [
"*"
]
}
]
}
To validate, if all required permissions are available to IAM users, groups or roles in your AWS account. Following are some of the options;
Use Web-GUI based policy simulator from AWS.
Use simulate-principal-policy aws cli command i.e. aws iam simulate-principal-policy. Furthermore, if you would like to cover custom-policy use aws cli command i.e. aws iam simulate-custom-policy .
Use python based aws-iam-tester command.
You can use wild-card within your IAM policy statements for Resource or a NotResource. Please refer following reference about same;
IAM JSON policy elements - Resource.
This existing thread.
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.
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
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.
It looks like Amazon has a ready-built IAM role to grant instances CloudWatch write access. ( A more restrictive one could also be created if necessary)
But it appears you cannot attach an IAM role to a running instance.
Am I missing something? Do I really have to re-instantiate my whole fleet to enable CloudWatch? I'm reluctant to save plaintext credentials on each host for security reasons.
I assume you're talking about custom CloudWatch metrics. You don't have to restart any instances to enable them. You can create a group in IAM with the following policy and add a user to this group:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "****************",
"Effect": "Allow",
"Action": [
"cloudwatch:PutMetricData"
],
"Resource": [
"*"
]
}
]
}
Then you basically copy this user's credentials to awscred file and add the perl script to cron. Yes, I had to copy credentials to each machine where custom metrics collection is enabled.
Have you considered simply modifying the existing IAM role to enable writes to CloudWatch? That change should take effect immediately and does not require instance reboot or relaunch.
Here is what i want. I have a IAM user for whom i want to give read only access to a us-east-1 and that too only read metrics for particular ec2 instance. I have 3 instances runnning in us-east-1 but i want this user to have access to metrics of only 1 ec2 server.
I have written policy like below. which is giving access to all the metrics in all the region. I tried putting that instanceid in below code but it didn't work.
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"cloudwatch:Describe*",
"cloudwatch:Get*",
"cloudwatch:List*"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
I dont understand what i am missing here.
In short, this is not possible, according to the Cloudwatch docs:
You can't use IAM to control access to CloudWatch data for specific
resources. For example, you can't give a user access to CloudWatch
data for only a specific set of instances or a specific LoadBalancer.
Permissions granted using IAM cover all the cloud resources you use
with CloudWatch.
http://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/UsingIAM.html