I have an S3 bucket policy in AWS to control access via IP, as per their standard examples, & would like to be able to add a comment or description inline (in the interest of keeping documentation as close to the implementation as possible).
If I try to add a custom field, e.g. Description, I'll get a validation error on save — "Invalid policy element - Description".
I can find this reference to the grammar of required elements, but can't seem to find any info on whether there are any optional fields allowed at all by the schema, & if so what they are.
Is it possible to add any fields to give an overview of the policy inline?
{
"Version": "2012-10-17",
"Id": "S3PolicyId1",
"Statement": [
{
"Sid": "IPAllow",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:*",
"Resource": "arn:aws:s3:::examplebucket/*",
"Condition": {
"IpAddress": {"aws:SourceIp": "54.240.143.0/24"},
"NotIpAddress": {"aws:SourceIp": "54.240.143.188/32"}
}
}
]
}
From the page you cited, Sid is probably what you want to use for this. It's largely freeform, but you probably want to use underscores where you might otherwise use spaces.
sid_string
Provides a way to include information about an individual statement. Some services require this value to be unique within an AWS account. Some services allow spaces in the Sid value, and others do not.
"Sid": "ThisStatementProvidesPermissionsForConsoleAccess"
Related
I initially tried with all the json policies in the below link.
https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/iam-identity-based-access-control-cwl.html#customer-managed-policies-cwl
And i finally got a solution of giving "list, read, write" access to one specific loggroup for an IAM user by using below JSON policy. But it is able to see the list of other log groups as well. As per the below JSON policy i tired limiting the resource for listing as well. It didn't work.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"logs:GetLogRecord",
"logs:DescribeLogGroups"
],
"Resource": "*"
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"logs:Describe*",
"logs:FilterLogEvents",
"logs:GetLogEvents"
],
"Resource": "arn:aws:logs:us-east-1:XXXXXXXXXXXX:log-group:/aws/lambda/XXXX:log-stream:*"
}
]
}
But then i found the tagging as a solution and tried tagging the loggroup and user with same tag and tried below JSON policy. That didn't work either.
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"logs:*"
],
"Effect": "Allow",
"Resource": "*",
"Condition": {
"StringLike": {
"logs:ResourceTag/Team": "Green"
}
}
}
]
}
Please can someone kindly suggest a way where i could give access to one specific IAM user for only one group to either, list&read or list,read&write. But that user should not be able to see the other log groups.
But it is able to see the list of other log groups as well
That's not something you can do typically within AWS. Generally IAM permissions can't affect on the result of an API action. It can't filter it to only show something in particular. This is one the reasons AWS recommends to isolate workloads by using different accounts, as API calls are only scoped to one account.
In this case, you can either not give access at all or give access to list everything.
I need to grant full admin access (All the AWS resources, not just few resources) for a specific region.
Below is the IAM policy configured. Anyway accessing to some other resources, it gives errors.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"rds:*",
"apigateway:*",
"s3:*",
"lambda:*",
"dynamodb:*",
"ec2:*",
"cognito-idp:*",
"sns:*",
"sqs:*",
"cloudwatch:*",
"cloudfront:*",
"cloudformation:*",
"ses:*",
"codepipeline:*",
"codebuild:*",
"logs:*",
"iam:*"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestedRegion": "ap-northeast-1"
}
}
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"cloudwatch:DescribeAlarms",
"cloudformation:DescribeStacks",
"logs:DescribeLogGroups",
"logs:CreateLogGroup"
],
"Resource": "*"
}
]
}
You should include the errors that you are seeing along with your question, else it's hard to help you.
With a cursory glance though I see you are including iam:* to the statement that has the region condition. IAM is a global resource so on the surface I could see why that policy wouldn't work (can't try it myself). I would break that into a separate statement without the region condition, but then they have admin access to your entire IAM (security scary!).
If you want to provide a restricted admin, I would start by cutting back some of those permissions to the actions they actually require (* vs CreateGroup). Then delegating with namespacing like the example here "arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:policy/TEAM-A/*". You can combine this with attribute tag conditions. Demonstrated here. This would allow them to move pretty freely but only in certain contexts. That being said, restricting those contexts can become quite complicated for you, the super-admin.
There may be other things to consider:
Do they really need IAM admin? How - in the way - would creating policies for them be in practice?
Could some of this pain be resolved by giving a separate account under and organization umbrella? Organizations can help enforce some of these policies like regional restrictions, budget maximums, but give a lot of control to the admins of those account.
I want to deny access to the ec2 that has a "Type" tag with "MyInstance" value.
I have Josh user with EC2FullAccess assigned policy.
I have created policy with such a rule:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "ec2:*",
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/Type": "MyInstance"
}
}
}
]
}
And assigned this policy to Josh user. But Josh still have access to the instances with Type:MyInstance tag.
Also, I have tried to Deny describe instances:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:*",
"Resource": "*",
},
{
"Effect": "Deny",
"Action": "ec2:Describe*",
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/Type": "MyInstance"
}
}
}
]
}
But, without success. Can you please help me with such a restriction? Thank you.
What you request is not possible.
The DescribeInstances() call is either permitted or denied. If permitted, information about all instances is returned.
The Actions, Resources, and Condition Keys for Amazon EC2 - AWS Identity and Access Management page does not show any conditions for the API call, so it would not be possible to craft a policy that only permits requests with certain filters/Instance IDs specified.
The ec2:ResourceTag condition can only be used on API calls that are shown on that page with ec2:ResourceTag mentioned in the Conditions column.
If you wish to segregate information in that manner, then you will either need to use separate AWS Accounts, or you will need to create an "information layer" that can apply detailed rules and make information API calls on behalf of your users, only relaying back permitted information.
From the AWS IAM ARN documentation at https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html, I can see wildcard use as shown below which is quite confusing.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ManageRichardAccessKeys",
"Effect": "Allow",
"Action": [
"iam:*AccessKey*",
"iam:GetUser"
],
"Resource": "arn:aws:iam::*:user/division_abc/subdivision_xyz/Richard"
},
{
"Sid": "ListForConsole",
"Effect": "Allow",
"Action": "iam:ListUsers",
"Resource": "*"
}
]
}
In the first statement "Resource": "arn:aws:iam::*:user/division_abc/subdivision_xyz/Richard", why are we not specifying the account number and just substituting with wildcard "*" - I understand that in the context of S3 this is left blank, but over here it is wildcard - what does the wild card here really mean? The wildcard appears to give it a meaning like "any account" but isnt this incorrect?
Also, for the second statement "Resource": "*", does this mean ListUsers for any resource? which does not make any sense - should this not be something like arn:aws:iam::123456789012: indicating list users for this AWS account (123456789012)?
Assuming that the queries actually work (I didn't test them):
Yes, leaving out the account number is a 'little' dangerous because it would also be permitting the user that has this policy to manage access keys for a same-named user in a different account, but the receiving account would not honor the request so it is safe.
The ListUsers command does not actually take many parameters (just a prefix), so it's really an "all or nothing" API call. Please note that it only applies to requesting a list of users, nothing else. (That is, there is no concept of calling "ListUsers for a resource".)
See: Actions, Resources, and Condition Keys for Identity And Access Management - AWS Identity and Access Management
this question references the same aws blog I've been trying to leverage in order to meet my needs, but without any success. I've been hacking on the solution in that answer AND the example policies it references all day without any success. I'm basically looking to allow different IAM groups full access to a common subfolder object within a bucket while selectively allowing/denying access to OTHER subfolders object based on group membership.
Bucket structure:
my-finance-bucket\
my-finance-bucket\files
my-finance-bucket\Our-Finance-Team\
my-finance-bucket\Our-Finance-Team\files
my-finance-bucket\Our-Finance-Team\Reports\
my-finance-bucket\Our-Finance-Team\Reports\files
my-finance-bucket\Our-Finance-Team\Reports\report1-name\
my-finance-bucket\Our-Finance-Team\Reports\report1-name\files
my-finance-bucket\Our-Finance-Team\Reports\report2-name\
my-finance-bucket\Our-Finance-Team\Reports\report2-name\files
my-finance-bucket\Our-Finance-Team\Data\
my-finance-bucket\Our-Finance-Team\Data\files
my-finance-bucket\Our-Finance-Team\Stuff\
my-finance-bucket\Our-Finance-Team\Stuff\files
I'm not even sure that what I'm looking to do is possible, but I want to create 3 groups named: finance-all, finance-data, and finance-reports.
I want all 3 groups to have access to:
my-finance-bucket\
my-finance-bucket\files
my-finance-bucket\Our-Finance-Team\
my-finance-bucket\Our-Finance-Team\files
my-finance-bucket\Our-Finance-Team\Stuff\
my-finance-bucket\Our-Finance-Team\Stuff\files
additionally, I have these requirements:
finance-all group has s3:* allow access to EVERYTHING under my-finance-bucket
(This is easy I think, and can probably stand alone as a separate group policy allowing s3:* to arn:aws:s3:::/my-finance-bucket and arn:aws:s3:::/my-finance-bucket/*)
finance-data group has the shared access listed above plus s3:*Object* allow to:
my-finance-bucket\Our-Finance-Team\Data\
my-finance-bucket\Our-Finance-Team\Data\files
no access to anything else that isn't specified
finance-reports has the shared access listed above, plus s3:*Object* allow to:
my-finance-bucket\Our-Finance-Team\Reports\
my-finance-bucket\Our-Finance-Team\Reports\files
my-finance-bucket\Our-Finance-Team\Reports\report1-name\
my-finance-bucket\Our-Finance-Team\Reports\report1-name\files
my-finance-bucket\Our-Finance-Team\Reports\report2-name\
my-finance-bucket\Our-Finance-Team\Reports\report2-name\files
no access to anything else that isn't specified
I'm aware that I will have to start with allowing "ListAllMyBuckets" and that as a consequence the objects representing the folders and files will be visible and listable for all folders, recursively. Though sub-optimal, it's not a show stopper since viewing, getting or putting files is to be denied for users not in their appropriate groups.
I realize most folks will ask "what have you done" in attempt to help correct whatever work I've done already - however I've gone through literally dozens of iterations and nothing has even come close to what I'm looking to do. the code listed in the linked answer and the linked aws blog post have been my start points for hacking on this and can serve as a baseline
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowUserToSeeBucketListInTheConsole",
"Action": ["s3:ListAllMyBuckets", "s3:GetBucketLocation"],
"Effect": "Allow",
"Resource": ["arn:aws:s3:::*"]
},
{
"Sid": "AllowRootAndHomeListingOfCompanyBucket",
"Action": ["s3:ListBucket"],
"Effect": "Allow",
"Resource": ["arn:aws:s3:::yourbucketname"],
"Condition":{"StringEquals":{"s3:prefix":["","yourfoldername/"],"s3:delimiter":["/"]}}
},
{
"Sid": "AllowListingOfUserFolder",
"Action": ["s3:ListBucket"],
"Effect": "Allow",
"Resource": ["arn:aws:s3:::yourbucketname"],
"Condition":{"StringLike":{"s3:prefix":["yourfoldername/*"]}}
},
{
"Sid": "AllowAllS3ActionsInUserFolder",
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": ["arn:aws:s3:::yourbucketname/yourfoldername/*"]
},
{
"Action": [
"s3:*"
],
"Sid": "Stmt1375581921000",
"Resource": [
"arn:aws:s3:::yourbucketname/anotherfolder1/*",
"arn:aws:s3:::yourbucketname/anotherfolder2/*",
"arn:aws:s3:::yourbucketname/anotherfolder3/*",
"arn:aws:s3:::yourbucketname/anotherfolder4/*"
],
"Effect": "Deny"
}
]
}
I ended up spending about 3 days on this before I gave up and convinced the person with the business need for this that I could get the whole thing done in a half hour if they would let me re-organize the bucket. They agreed, so I ended up just creating "subfolders" in the bucket and then just created IAM groups granting access to each individual "subfolder".
So I reorganized the bucket like so:
my-finance-bucket/
my-finance-bucket/files
my-finance-bucket/shared/
my-finance-bucket/shared/files
my-finance-bucket/
my-finance-bucket/data/
my-finance-bucket/data/files
my-finance-bucket/reports/
my-finance-bucket/reports/files
Following this pattern, I condensed existing "subfolders" such as
my-finance-bucket/some-report/*
my-finance-bucket/some-other-report/*
down to
my-finance-bucket/reports/some-report/*
my-finance-bucket/reports/some-other-report/*
and the same for condensing things under /shared/ and /data/
This being done, I was able to rely on the inherent deny functionality and simply carve out allow access for the individual top level folders using IAM group policies. By simply adding users to those groups, I was able to selectively grant access to some subfolders and not others.
All of the policies I created for access to each individual bucket followed this format:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowListAllMyBuckets",
"Effect": "Allow",
"Action": [
"s3:ListAllMyBuckets",
"s3:GetBucketLocation"
],
"Resource": [
"arn:aws:s3:::*"
]
},
{
"Sid": "AllowedListAccess",
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetBucketAcl",
"s3:GetBucketLocation"
],
"Resource": [
"arn:aws:s3:::my-finance-bucket",
"arn:aws:s3:::my-finance-bucket/shared"
]
},
{
"Sid": "AllowedObjectAccess",
"Effect": "Allow",
"Action": [
"s3:*Object*"
],
"Resource": [
"arn:aws:s3:::my-finance-bucket/shared/*"
]
}
]
}
Note that by virtue of the /* allows for list and object access, that the subfolders are also accessible to folks with access to the top level subfolders. Should nested subfolder access have been required, I believe it would have been the same issue as the original question. BUT, I think that with the simple and straightforward re-organization of this bucket I could have made it happen with explicit denies to the subfolders, and additional groups with explicit allows to those same subfolders. I'm fairly certain this also would have worked for the original question, but the way the bucket was organized would have made it an onerous task to create and maintain the policies.
Last, it's worth noting that this method makes it impossible to deny list access to "folders" and "files". This means that while users in the shared group can see the names of the files and folders in the data and reports folders, they cannot perform any other operations (no get or put aka list access only, no read, no write)