I have made a RDS instance and want to grant one of my user to access to that RDS instance. I'm wondering how I can give this permission.
I have granted RDSFULLACESS in attach policy of my IAM user then simulate it like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"rds:*",
"cloudwatch:DescribeAlarms",
"cloudwatch:GetMetricStatistics",
"ec2:DescribeAccountAttributes",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"sns:ListSubscriptions",
"sns:ListTopics",
"logs:DescribeLogStreams",
"logs:GetLogEvents"
],
"Effect": "Allow",
"Resource": "arn:aws:rds:eu-west-1:accountIDofIAMUser:db:instancename"
}
]
}
But my user still can not access to this RDS instance,what's the problem? he can make it himself but I don't want he makes another one!
Any help would be appreciated.
Please find below policy for single user single rds start-stop access.
Create below policy and give rds arn in the resource section.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"rds:AddTagsToResource",
"rds:ListTagsForResource",
"rds:DescribeDBSnapshots",
"rds:DescribeDBEngineVersions",
"rds:DescribeDBParameters",
"rds:DescribeDBParameterGroups",
"rds:StopDBInstance",
"rds:StartDBInstance"
],
"Resource": [
"arn:aws:rds:us-east-1:accountnumber:db:dbidentifier"
]
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"rds:DescribeDBClusterSnapshots",
"rds:DescribeDBInstances"
],
"Resource": "*"
}
]
}
Attach this policy to user whome you want to grant access.
If the policy above has the correct ARN for the database and is attached to the IAM user then it will allow full management actions on the RDS database, things like stopping the database or restoring a backup.
To explictly exclude the "Create" permissions, based on the list on this page
http://docs.aws.amazon.com/IAM/latest/UserGuide/list_rds.html
include all the permissions you do need, for example. In this context "Deny" always beats "Allow". "Create" permissions are ok vs. the already existing database but don't apply elsewhere.
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"rds:*",
"cloudwatch:DescribeAlarms",
"cloudwatch:GetMetricStatistics",
"ec2:DescribeAccountAttributes",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"sns:ListSubscriptions",
"sns:ListTopics",
"logs:DescribeLogStreams",
"logs:GetLogEvents"
],
"Effect": "Allow",
"Resource": "arn:aws:rds:eu-west-1:accountIDofIAMUser:db:instancename"
},
{
"Effect": "Deny",
"Action": [
"rds:Create*"
],
"NotResource": [
"arn:aws:rds:eu-west-1:accountIDofIAMUser:db:instancename"
]
}
]
}
I haven't tested this policy, it's just an example
If the user needs access to the database as a consumer of data then this is not managed in this way. They need to have two things for this
# network access to the RDS instance via correct networking and correctly setup security groups
# user account credentials for the database
For mysql the process of initially connecting is described here http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ConnectToInstance.html
Related
I am trying to create an IAM user that will have least privileges to be able to view enhanced monitoring for a particular RDS database. I have created a ROLE (Enhanced Monitoring) and attached a managed policy to it:'AmazonRDSEnhancedMonitoringRole'. This role is passed to RDS database using the passrole permission. The policy that I am attaching to this IAM user is as below:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"cloudwatch:PutMetricData",
"rds:*",
"cloudwatch:GetMetricData",
"iam:ListRoles",
"cloudwatch:GetMetricStatistics",
"cloudwatch:DeleteAnomalyDetector",
"cloudwatch:ListMetrics",
"cloudwatch:DescribeAnomalyDetectors",
"cloudwatch:ListMetricStreams",
"cloudwatch:DescribeAlarmsForMetric",
"cloudwatch:ListDashboards",
"ec2:*",
"cloudwatch:PutAnomalyDetector",
"cloudwatch:GetMetricWidgetImage"
],
"Resource": "*"
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"iam:GetRole",
"iam:PassRole",
"cloudwatch:*"
],
"Resource": [
"arn:aws:cloudwatch:*:accountnumber:insight-rule/*",
"arn:aws:iam::accountnumber:role/Enhanced-Monitoring",
"arn:aws:rds:us-east-1:accountnumber:db:dbidentifier"
]
}
]
}
As you can see,I have given almost every permission to this user, but still I am getting 'Not Authorized' error on the IAM user RDS dashboard for enhanced monitoring, although cloudwatch logs are displaying normally.
I managed to solve the error by modifying the policy. Since Enhanced Monitoring utilizes CloudWatch logs, I added a read-only cloudwatch logs policy(CloudWatchLogsReadOnlyAccess). This policy is mentioned here in AWS documentation. I also added a cloudwatch:GetMetricData permission as suggested on the RDS console. The overall policy is also more compact now:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::account_number:role/Enhanced-Monitoring"
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"rds:*",
"logs:Describe*",
"logs:List*",
"logs:StartQuery",
"ec2:*",
"iam:ListRoles",
"logs:StopQuery",
"logs:TestMetricFilter",
"logs:FilterLogEvents",
"logs:Get*",
"cloudwatch:GetMetricData"
],
"Resource": "*"
}
]
}
The setup is working fine now.
I've be trying to implement a new policy on AWS to allow a specific user to manage a specific Security Group.
I used to have this working but it stopped working a couple weeks ago and now no matter what I try I cannot get it to work again.
Does anyone have a valid JSON config on how to create a policy to allow users to modify a SPECIFIC security role? This is mainly to allow certain users to change the firewall rules when they are on dynamic IPs.
EDIT:
This is my current JSON config:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "s1",
"Effect": "Allow",
"Action": [
"ec2:DescribeInstanceAttribute",
"ec2:DescribeInstanceStatus",
"ec2:DescribeInstances",
"ec2:DescribeNetworkAcls",
"ec2:DescribeSecurityGroups"
],
"Resource": [
"*"
]
},
{
"Sid": "s2",
"Effect": "Allow",
"Action": [
"ec2:AuthorizeSecurityGroupEgress",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:RevokeSecurityGroupEgress",
"ec2:RevokeSecurityGroupIngress"
],
"Resource": [
"arn:aws:ec2:*:*:security-group/sg-<my id>"
]
}
]
}
The policy you mentioned looks correct. But it will not allow you to modify the existing egress/ingress security rule. If you want to modify a security group rule, you can delete the existing security group rule and add a new security group rule.
To allow modifications on an existing security group rule add this permission as well ec2:ModifySecurityGroupRules.
Modified policy
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeSecurityGroupRules",
"ec2:DescribeInstanceAttribute",
"ec2:DescribeNetworkAcls",
"ec2:DescribeSecurityGroups",
"ec2:DescribeInstanceStatus"
],
"Resource": "*"
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"ec2:RevokeSecurityGroupIngress",
"ec2:AuthorizeSecurityGroupEgress",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:UpdateSecurityGroupRuleDescriptionsEgress",
"ec2:RevokeSecurityGroupEgress",
"ec2:UpdateSecurityGroupRuleDescriptionsIngress",
"ec2:ModifySecurityGroupRules"
],
"Resource": [
"arn:aws:ec2:*:*:security-group/<sg-id>",
"arn:aws:ec2:*:*:security-group-rule/*"
]
}
]
}
Note: This policy allows you to edit a security group and any security group rules under that security group. You can also limit access using security group rule as well by mentioning security group rule id (arn:aws:ec2:::security-group-rule/$sgr-id) for the corresponding security group id.
I am trying to create a policy for giving the user the permission to create Ec2 instance but I dont wan't to give all the permission inside write.
Please verify if these permissions are enough or if some permission is extra
{
"Version": "2020-06-16",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeSubnets",
"ec2:DescribeSecurityGroups",
"ec2:DescribeInstances",
"ec2:DescribeImages",
"ec2:DescribeKeyPairs",
"ec2:DescribeVpcs",
"ec2:CreateSecurityGroup",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:CreateKeyPair"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": "*"
}
]
}
I can confirm these permissions should work if using the Console Wizard.
More examples of policies for other situations can be found here.
If you're ever in need of testing scenarios feel free to take a look at the IAM policy simulator. It can really help you to validate your permissions against actions easily without having to script or attempt executing the change(s) each time.
Here you have to give create tag access, as for run instances it's a must needed option.Here I am attaching my policy for your refrence.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"ec2:DescribeImages",
"ec2:AuthorizeSecurityGroupEgress",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:DescribeInstances",
"ec2:DescribeVpcs",
"ec2:CreateSecurityGroup",
"ec2:CreateTags",
"ec2:DescribeInstanceTypes",
"ec2:RunInstances",
"ec2:DescribeSubnets",
"ec2:DescribeKeyPairs",
"ec2:DescribeSecurityGroups"
],
"Resource": "*"
}
]
}
I am having trouble connecting to AWS Transfer for SFTP. I successfully set up a server and tried to connect using WinSCP.
I set up an IAM role with trust relationships like follows:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "transfer.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
I paired this with a scope down policy as described in the documentation using a home directory homebucket and home directory homedir
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ListHomeDir",
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetBucketAcl"
],
"Resource": "arn:aws:s3:::${transfer:HomeBucket}"
},
{
"Sid": "AWSTransferRequirements",
"Effect": "Allow",
"Action": [
"s3:ListAllMyBuckets",
"s3:GetBucketLocation"
],
"Resource": "*"
},
{
"Sid": "HomeDirObjectAccess",
"Effect": "Allow",
"Action": [
"s3:DeleteObjectVersion",
"s3:DeleteObject",
"s3:PutObject",
"s3:GetObjectAcl",
"s3:GetObject",
"s3:GetObjectVersionAcl",
"s3:GetObjectTagging",
"s3:PutObjectTagging",
"s3:PutObjectAcl",
"s3:GetObjectVersion"
],
"Resource": "arn:aws:s3:::${transfer:HomeDirectory}*"
}
]
}
I was able to authenticate using an ssh key, but when it came to actually reading/writing files I just kept getting opaque errors like "Error looking up homedir" and failed "readdir". This all smells very much like problems with my IAM policy but I haven't been able to figure it out.
We had similar issues getting the scope down policy to work with our users on AWS Transfer. The solution that worked for us, was creating two different kinds of policies.
Policy to attach to the role which has general rights on the whole bucket.
Scope down policy to apply to the user which makes use of the transfer service variables like {transfer:UserName}.
We concluded that maybe only the extra attached policy is able to resolve the transfer service variables. We are not sure if this is correct and if this is the best solution, because this opens the possible risk when forgiving to attach the scope down policy to create a kind of "admin" user. So I'd be glad to get input to further lock this down a little bit.
Here is how it looks in my console when looking at the transfer user details:
Here are our two policies we use:
General policy to attach to IAM role
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowListingOfUserFolder",
"Action": [
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::my-s3-bucket"
]
},
{
"Sid": "HomeDirObjectAccess",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObjectVersion",
"s3:DeleteObject",
"s3:GetObjectVersion"
],
"Resource": "arn:aws:s3::: my-s3-bucket/*"
}
]
}
Scope down policy to apply to transfer user
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowListingOfUserFolder",
"Action": [
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::${transfer:HomeBucket}"
],
"Condition": {
"StringLike": {
"s3:prefix": [
"${transfer:UserName}/*",
"${transfer:UserName}"
]
}
}
},
{
"Sid": "AWSTransferRequirements",
"Effect": "Allow",
"Action": [
"s3:ListAllMyBuckets",
"s3:GetBucketLocation"
],
"Resource": "*"
},
{
"Sid": "HomeDirObjectAccess",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObjectVersion",
"s3:DeleteObject",
"s3:GetObjectVersion"
],
"Resource": "arn:aws:s3:::${transfer:HomeDirectory}*"
}
]
}
I had a similar problem but with a different error behavior. I managed to log in successfully, but then the connection was almost immediately closed.
I did the following things:
Make sure that the IAM role that allows bucket access also contains KMS access if your bucket is encrypted.
Make sure that the trust relationship is also part of that role.
Make sure that the server itself has a Cloudwatch role also with a trust relationship to transfer.amazonaws.com! This was the solution for me. I don't get why this is needed but without the trust relationship in the Cloudwatch role, my connection get's closed.
I hope that helps.
Edit: Added a picture for the settings of the CloudWatch role:
The bucket policy for the IAM user role can look like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::<your bucket>"
]
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::<your bucket>/*"
]
}
]
}
Finally, also add a Trust Relationship as shown above for the user IAM role.
If you can connect to your sftp but then get a readdir error when trying to list contents, e.g. with the command "ls", then that's a sign that you have no bucket permission. If your connection get's closed right away it seems to be a Trust Relationship issue or a KMS issue.
According to the somewhat cryptic documentation #limfinity was correct. To scope down access you need a general Role/Policy combination granting access to see the bucket. This role gets applied to the SFTP user you create. In addition you need a custom policy which grants CRUD rights only to the user's bucket. The custom policy is also applied to the SFTP user.
From page 24 of this doc... https://docs.aws.amazon.com/transfer/latest/userguide/sftp.ug.pdf#page=28&zoom=100,0,776
To create a scope-down policy, use the following policy variables in your IAM policy:
AWS Transfer for SFTP User Guide
Creating a Scope-Down Policy
• ${transfer:HomeBucket}
• ${transfer:HomeDirectory}
• ${transfer:HomeFolder}
• ${transfer:UserName}
Note
You can't use the variables listed preceding as policy variables in an IAM role definition. You create these variables in an IAM policy and supply them directly when setting up your user. Also, you can't use the ${aws:Username}variable in this scope-down policy. This variable refers to an IAM user name and not the user name required by AWS SFTP.
Can't comment, sorry if I'm posting incorrectly.
Careful with AWS's default policy!
This solution did work for me in that I was able to use scope-down policies for SFTP users as expected. However, there's a catch:
{
"Sid": "AWSTransferRequirements",
"Effect": "Allow",
"Action": [
"s3:ListAllMyBuckets",
"s3:GetBucketLocation"
],
"Resource": "*"
},
This section of the policy will enable SFTP users using this policy to change directory to root and list all of your account's buckets. They won't have access to read or write, but they can discover stuff which is probably unnecessary. I can confirm that changing the above to:
{
"Sid": "AWSTransferRequirements",
"Effect": "Allow",
"Action": [
"s3:ListAllMyBuckets",
"s3:GetBucketLocation"
],
"Resource": "${transfer:HomeBucket}"
},
... appears to prevent SFTP users from listing buckets. However, they can still cd to directories if they happen to know buckets that exist -- again they dont' have read/write but this is still unnecessary access. I'm probably missing something to prevent this in my policy.
Proper jailing appears to be a backlog topic: https://forums.aws.amazon.com/thread.jspa?threadID=297509&tstart=0
We were using the updated version of SFTP with Username and Password and had to spend quite some time to figure out all details. For the new version, the Scope down policy needs to be specified as 'Policy' key within Secrets Manager. This is very important for the whole flow to work.
We have documented the full setup on our site here - https://coderise.io/sftp-on-aws-with-username-and-password/
Hope that helps!
I have a Elastic Beanstalk application running on an EC2 instance, currently I have given admin privileges to all my co-workers. However now I want to add other environments and web applications that I don't want my co-workers to have access to. I've been looking at Resource-Level Permissions but I'm pulling my hair out trying to get it to work. Sometimes It works intermittently and I'm looking for advice on how I can achieve this from anyone with previous experience.
In a nutshell: I have [Application A] that I want users to have access to. I also have [Application B] and [Application C] that I want to restrict access to so only I can see and make changes to it.
Here is my current IAM Policy JSON;
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecs:*",
"ecr:*",
"elasticloadbalancing:*",
"autoscaling:*",
"cloudwatch:*",
"sns:*",
"cloudformation:*",
"dynamodb:*",
"rds:*",
"sqs:*",
"iam:GetPolicyVersion",
"iam:ListRolePolicies",
"iam:ListAttachedRolePolicies",
"iam:ListInstanceProfiles",
"iam:ListRoles",
"iam:ListServerCertificates",
"acm:DescribeCertificate",
"acm:ListCertificates",
"codebuild:CreateProject",
"codebuild:DeleteProject",
"codebuild:BatchGetBuilds",
"codebuild:StartBuild"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:*"
],
"Resource": [
"arn:aws:ec2:myregion:myaccountid:instance/*"
],
"Condition": {
"StringEquals": {
"ec2:ResourceTag/Name":"mytag"
}
}
},
{
"Effect": "Allow",
"Action": [
"elasticbeanstalk:*"
],
"Resource": [
"arn:aws:elasticbeanstalk:myregion:myaccountid:environment/myapp/myenv"
],
"Condition": {}
}
]
}
Derived from here. I would really appreciate if someone with more experience with IAM policies could identify what I'm doing wrong and how to do it properly & If there is a simpler way of doing this I would love to hear it also!
Thanks!
Since your co-workers already have admin access, you need a Deny policy.
The following policy explicitly denies access to all Amazon EB resources other than the listed resources
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": "elasticbeanstalk:*",
"NotResource": [
"<Application A ARN>"
]
}
}