{
"Version": "2012-10-17",
"Id": "Policy1612574490300",
"Statement": [
{
"Sid": "Stmt1612574488073",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:ec2:us-east-1:258977512672:instance/i-041123c1993c370ba"
},
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::my_bucket",
"arn:aws:s3:::my_bucket/*"
]
}
]
}
response is Invalid Principal. I dont see why it's invalid.
An EC2 instance isn't a valid principal. I think what you actually need to do here is use the ARN of the IAM role assigned to the EC2 instance.
You can specify following Principal in a policy
AWS account and root user
IAM users
Federated users (using web identity or SAML federation)
IAM roles
Assumed-role sessions
AWS services
Anonymous users (not recommended)
S3 Documentation Principal
AWS JSON policy elements: Principal
If you wanna give that instant access to the bucket then you can use Instance profiles
Related
I am trying to configure the SQS policy for a queue to authorize all principles of an account to send messages to this queue, according to the documentation here:
{
"Version": "2012-10-17",
"Id": "sqspolicy",
"Statement": [
{
"Sid": "Sqs policy1",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789:root"
]
}
"Action": "sqs:SendMessage",
"Resource": "arn:aws:sqs:eu-west-1:123456789:my_queue"
}
]
}
Will this allow any principle of this account to send messages to my_queue or will it only allow the root user?
Or should I use the below policy with a condition instead?
{
"Version": "2012-10-17",
"Id": "sqspolicy",
"Statement": [
{
"Sid": "Sqs policy1",
"Effect": "Allow",
"Principal": {
"AWS": "*"
}
"Action": "sqs:SendMessage",
"Resource": "arn:aws:sqs:eu-west-1:123456789:my_queue"
"Condition": {
"StringEquals": {
"AWS:SourceAccount": "123456789"
}
}
}
]
}
TIA
The documentation says:
When you use an AWS account identifier as the principal in a policy, you delegate authority to the account. All identities inside the account can access the resource if they have the appropriate IAM permissions attached to explicitly allow access. This includes IAM users and roles in that account.
According to this, your first approach will allow all of your users to send messages.
Only first policy is valid. The second policy will not work, the way you may think. The reason is that aws:SourceAccount is only used for service-to-service requests, not IAM users or roles. The most common example of when aws:SourceAccount is used is for S3:
For example, when an Amazon S3 bucket update triggers an Amazon SNS topic post, the Amazon S3 service invokes the sns:Publish API operation. The bucket is considered the source of the SNS request and the value of the key is the account ID associated with the bucket.
Send-messages requests made by IAM users/roles in the second account will be denied because for these entities there is no aws:SourceAccount.
I am using ssm:tag of documents to restrict access to users based on user role and document tag. I have added a condition to IAM policy and it's working. But when I try to do this with cross account, it's not working.
1) My SSM documents are in Master account, shared with Child account
2) IAM Policy to restrict access based on tags is in Child account (Tag key: Role)
3) The request is made to Child account
Scenario 1: I can execute the documents successfully, when condition from the IAM Policy is removed. So the Child AWS account can fetch the SSM Documents from Master AWS account.
Scenario 2: I cannot execute the documents when filtered based on tags, i.e. condition added to teh IAM policy. This shows the Child AWS account is unable to fetch tags of SSM documents from Master AWS account.
Could someone please help me with this? Attaching the IAM Policy for reference.
IAM Policy Document:
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "ssm:SendCommand",
"Resource": [
"arn:aws:s3:::ssm-deliverables/ssm-*",
"arn:aws:ec2:ap-south-1:20**********:instance/*"
]
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": "ssm:ListCommandInvocations",
"Resource": "*"
},
{
"Sid": "VisualEditor2",
"Effect": "Allow",
"Action": "ssm:SendCommand",
"Resource": "arn:aws:ssm:::document/*",
"Condition": {
"StringEquals": {
"ssm:resourceTag/Role": "${aws:PrincipalTag/Role}"
}
}
}
]
}
aws:PrincipalTag used here is one of the aws global condition context keys. We have to use the above key to compare the tag attached to a principal making request with the tag that you specify in the policy.
In this case, the principal is IAM User/Role to which the above policy is attached. So the IAM User/Role itself should be tagged with the same values mentioned in the IAM Policy.
For Example:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:StartInstances",
"Resource": "*",
"Condition": {"StringEquals": {"ec2:resourceTag/Name": "${aws:PrincipalTag/Name}"
}
}
}
]
}
Assume that the above policy is attached to an IAM user who has wants to start an EC2 Instance, the user will be able to start the EC2 Instance if the user is tagged with the same tags as the resource tags mentioned in the IAM Policy.
So, you have to tag the IAM User making request to SSM, with the key 'Role' and Value set the role name or arn same as ssm document tags.
I am trying to setup an API Gateway endpoint with a resource policy, which allows access to a specific IAM role in my account. The IAM role is cross-account, setup with a trust policy which allows AssumeRole to a specific IAM user principal from another account.
In the API Gateway resource policy, when I set AWS principal to the role ARN: arn:aws:iam::********:role/myRole, I get the following 403 error when invoking the API:
User: arn:aws:sts::********:assumed-role/myRole/mySession is not authorized to perform: execute-api:Invoke on resource: arn:aws:execute-api:us-west-2:********:********/test/POST/echo
But, if I change the AWS principal to be the temporary STS user ARN: arn:aws:sts::********:assumed-role/myRole/mySession, then I can invoke the API successfully.
Here's the resource policy that doesn't work:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::********:role/myRole"
},
"Action": "execute-api:Invoke",
"Resource": "arn:aws:execute-api:us-west-2:********:********/*"
}
]
}
Here's the resource policy that works:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:sts::********:assumed-role/myRole/mySession"
},
"Action": "execute-api:Invoke",
"Resource": "arn:aws:execute-api:us-west-2:********:********/*"
}
]
}
Can IAM roles be used as AWS principals for API Gateway resource policy?
Based on the documentation https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-policy-language-overview.html,
Principal – The account or user who is allowed access to the actions
and resources in the statement. In a resource policy, the principal is
the IAM user or account who is the recipient of this permission.
Looks like roles cannot be added as a principal.
P.S: Spent two days trying to restrict access using roles, but couldn't get it to work.
In S3, can we create an IAM user and give it rights to create other IAM users?
S3 and IAM are 2 different AWS services. S3 has nothing to do with IAM user creation.
I'll go ahead and assume that you meant creating an IAM user with permissions to create other users.
Yes, it is possible to do so. You just have to attach a suitable IAM policy to the newly created user. Following policy should get you started.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"iam:CreateUser",
"iam:CreateAccessKey"
],
"Resource": "*"
}
]
}
The policy specified by Maverick in the above answer can create a new user and create access and secret keys for the user. However, it cannot create or attach any policies to the created user. So, I'm adding the required permission to create and attach IAM and inline policies for IAM users.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:AttachUserPolicy",
"iam:CreateAccessKey",
"iam:CreatePolicy",
"iam:CreateUser",
"iam:PutUserPolicy"
],
"Resource": "*"
}
]
}
Refer this for more information about actions related to Identity and Access Management (IAM) in AWS: https://docs.aws.amazon.com/IAM/latest/UserGuide/list_identityandaccessmanagement.html
I've set up an S3 bucket and an IAM user who has full access to the bucket.
Im confused about how to restrict access to the bucket so only this user and cloud front can access it. The cloud front policy was auto generated for me in the cloudfront control pannel.
But as for allowing only my IAM user access, do I:
Allow "Any Authenticated User", does this refer to my IAM user or to any AWS user in general?
Or do I need to amend the bucket policy?
Any Authenticated User means any user that has an Amazon AWS Account.
You may want to attach a policy to the IAM user and not deal with bucket policy. Or add a bucket policy to allow only that IAM user. Examples for both are in: IAM Policies and Bucket Policies
Sample S3 Bucket Policy
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": ["arn:aws:iam::111122223333:user/Alice",
"arn:aws:iam::111122223333:root"]
},
"Action": "s3:*",
"Resource": ["arn:aws:s3:::my_bucket",
"arn:aws:s3:::my_bucket/*"]
}
]
}
Sample IAM Policy
{
"Version": "2012-10-17",
"Statement":[{
"Effect": "Allow",
"Action": "s3:*",
"Resource": ["arn:aws:s3:::my_bucket",
"arn:aws:s3:::my_bucket/*"]
}
]
}