Is there a complete list of AWS resource actions? - amazon-web-services

Is there a list of AWS resource actions anywhere? For example, if I look at one of the AWS policies for sqs read only access I see a list of actions. But I can't find the FULL list of actions for this resource despite searching for what seems like forever. Some of the API reference pages refer to the necessary action permission (like for create queue) but not all. I had a custom policy and found out I needed the GetQueueUrl action. So in summary, I just want to know if there is ANYWHERE that AWS lists out all the actions for each service?
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"sqs:GetQueueAttributes",
"sqs:GetQueueUrl",
"sqs:ListDeadLetterSourceQueues",
"sqs:ListQueues"
],
"Effect": "Allow",
"Resource": "*"
}
]
}

i think this shoudl work for you :-
go to IAM
under policies -> create policy.
choose a service -> under action -> expand all
you can see all the actions associated with that service through console.
also you can use this https://docs.amazonaws.cn/en_us/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html, select your service and you will be able to see actioned defined for that service in a tabular form

See Actions, resources, and condition keys for Amazon SQS. It contains the full list of Actions.
For all AWS services, start with Actions, resources, and condition keys for AWS services.

Related

How to protect AWS tagged resources via SCP?

I have a sensitive number of assets (Lambda, S3 Bucket, IAM...) I'd like to protect in case someone tries to erase a Bucket Policy, Delete a Function or do any harm to these resources. All of them are tagged as <<MY_KEY>>:<<MY_VALUE>>. The thing is that I'd like to do it in an Organization level since I have more than one AWS Account. I'm using this policy in an SCP.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyActionsOnTaggedResources",
"Effect": "Deny",
"Action": [
"s3:PutBucketPolicy",
"s3:PutBucketTagging",
"s3:DeleteBucketPolicy",
"s3:PutAccessPointPolicyForObjectLambda",
"s3:PutBucketPublicAccessBlock",
"s3:DeleteAccessPointPolicyForObjectLambda",
"s3:PutMultiRegionAccessPointPolicy",
"s3:PutBucketAcl",
"s3:PutBucketPolicy",
"s3:DeleteAccessPointPolicy",
"s3:DeleteBucketPolicy",
"s3:PutAccessPointPolicy",
"s3:BypassGovernanceRetention",
"lambda:DeleteFunction",
"lambda:DeleteCodeSigningConfig",
"lambda:DeleteFunctionCodeSigningConfig",
"lambda:AddLayerVersionPermission",
"lambda:RemoveLayerVersionPermission",
"lambda:EnableReplication",
"lambda:AddPermission",
"lambda:DisableReplication",
"lambda:DeleteLayerVersion",
"lambda:DeleteFunctionEventInvokeConfig",
"lambda:PublishVersion",
"lambda:CreateAlias",
"lambda:RemovePermission",
"iam:DeleteRole",
"iam:DeleteInstanceProfile",
"iam:DeletePolicy",
"iam:DeleteRolePolicy",
"iam:DeleteUserPolicy",
"iam:DeleteGroupPolicy",
"iam:UpdateAssumeRolePolicy",
"iam:PutRolePermissionsBoundary",
"iam:AttachRolePolicy",
"iam:PutRolePolicy",
"iam:DeleteRolePermissionsBoundary",
"iam:CreatePolicy",
"iam:DetachRolePolicy",
"iam:DeleteRolePolicy",
"iam:CreatePolicyVersion",
"iam:DeletePolicyVersion"
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/<<MY_KEY>>": "<<MY_VALUE>>"
},
"StringNotEquals": {
"aws:PrincipalArn": [
"arn:aws:iam::*:role/<<MY_ROLE>>"
]
}
}
}
]
}
For the sake of testing, whenever I put a role that is not my role, I am still able to modify the resources. Where is my mistake?
It turns out that #John Rotenstein is right. S3 API Calls does not support ResourceTag as a Condition.
Since this was a urgent demand at work, I ended up opening a Support Case at AWS and they replied this:
I understand you trying to restrict actions on an S3 bucket using the ResourceTag condition key.
Unfortunately, you cannot currently use the AWS:ResourceTag condition key to control access to the s3 bucket, please refer the following documentation[1]. In the documentation, you can see that only the resource type that currently supports the aws:ResourceTag condition key is "storagelensconfiguration". There is an existing feature request with the s3 service team to add support for the AWS:ResourceTag condition key which I have +1'd on your behalf. I am unable to provide an ETA for when the feature might get released since I have no visibility over the processes of the service team. However, all new feature announcements will be made available on our What's new with AWS page[2].
When it comes to controlling access to s3 with the use of tags, we do have the examples in the following AWS Documentation[3] which uses the tags applied to specific objects to control access. It makes use of the condition keys, s3:ExistingObjectTag/<tag-key>, s3:RequestObjectTagKeys and s3:RequestObjectTag/<tag-key> to control access to certain S3 actions however it requires the individual objects to be tagged, it will not work with tags at the bucket level. I would suggest reading through the above linked documentation[3] and see if the solution described in it will meet your organizations needs.
I hope you find the above information helpful, please let me know if you have any additional questions.
[1] Actions, resources, and condition keys for Amazon S3 - https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazons3.html
[2] What's New with AWS? - https://aws.amazon.com/new/
[3] Tagging and access control policies - https://docs.aws.amazon.com/AmazonS3/latest/userguide/tagging-and-policies.html
Can you modify this StringNotEquals to StringNotLike and try that? As you are using a wildcard (*) in the Condition, StringNotEquals won't work. The rest of the policy looks sound.
String condition operators
I also recommended using the Access Analyzer to validate policies. This will catch similar errors when building policies. See Access Analyzer.

Need help to deny S3 bucket creation without specific Tags

I want to create an IAM policy to only allow the "Test" user to create S3 bucket with "Name" and "Bucket" Tags while creating. But not able to do.
I have tried this, but even with the specified condition, the user is not able to create an Bucket.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Deny",
"Action": "s3:CreateBucket",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestTag/Name": "Bucket"
}
}
}
]
}
Thanks in advance.
The Actions, resources, and condition keys for Amazon S3 - Service Authorization Reference documentation page lists the conditions that can be applied to the CreateBucket command.
Tags are not included in this list. Therefore, it is not possible to restrict the CreateBucket command based on tags being specified with the command.
#pop I believe you can't do this using an IAM policy nor an SCP because by design S3 create tag API is configured to be triggered as a subsequent call to CreateBucket API. So your IAM policy would prevent creation of S3 Bucket itself even if you have added this tag. This is by design for S3 service compared to other AWS services.
Only option in my opinion would be a post-deployment action i.e. to choose an event driven model where you use S3 events to take actions (delete bucket/ add access block bucket policy etc.) based on how a bucket got created.
As John Rotenstein pointed out, this is not possibly (yet at least) to explicitly deny this but there are a few options that people do for this since this type of tagging policy is a common things in many organizations.
Compliance Reports
You can use the AWS Config service to detect S3 bucket resources that are out-of-compliance. You can define your tagging policy for S3 Buckets with a Config rule.
This will not prevent users from creating buckets but it will provide a way to audit your accounts and also be proactively notified.
Auto-remediation
If you want a bucket to be auto-deleted or flagged, you can create a lambda function that is triggered by the CloudTrail API for when buckets are created.
The Lambda could be implemented to check the tags and, if the bucket is non-compliant, try and delete the bucket or mark it for deletion via some other process you define.

AWS IoT Rule - Update multiple columns in DynamoDB

I have been able to use the AWS documentation to insert an mqtt message into a single column in a table. I would like to be able to update (not insert) multiple columns in the table. I used the DynamoDbv2 action in my IoT Rule, and I changed the IAM role to UpdateItem, but nothing is happening.
Is there a way to see where/when these errors are occuring?
Should I create a Lambda function to handle this instead? Is there an example of this?
Thanks.
First of all please keep in mind that DynamoDbV2 is using internally PutItem, so your are not able to only update attributes, but whole object will be overwritten.
If you want to update item you need to implement Lambda function and manually implement data update.
For IAM role, your trust relationship should contain:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "iot.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
You can use the DynamoDbV2 rule action to update multiple attributes (or columns if you will) in your DynamodDB table. Your role you provide to the Iot Rule needs to allow dynamodb:PutItem on the table in question. The role of course needs to have the IoT service in it's trust policy (also know as the assume role policy document in some places).
To help troubleshoot any issues you have turn on IoT logging and set the level to Debug. Then you can view any errors in the AWS Cloudwatch Logs.
https://docs.aws.amazon.com/iot/latest/developerguide/iot-rule-actions.html

IAM Policy using Condition ec2:ResourceTag not working

I have n x EC2 instances that I wish to limit ec2 actions to instances with the same key/value tag (I.E. platform=dev).
I'm looking at doing this using an IAM Policy attached to the group their default IAM user is in.
Policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:*",
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/tag:platform": "dev"
}
}
}
]}
I set this up as per the online AWS docs: Example Policies for Working With the AWS CLI or an AWS SDK
I check it in the Policy Simulator and it works as expected (pass in a dev and it's allowed, otherwise denied).
Then on one of the servers with the tag key/pair of platform=dev, I run aws ec2 describe-instances I get the response:
An error occurred (UnauthorizedOperation) when calling the DescribeInstances operation: You are not authorized to perform this operation.
but if I remove the Condition it works. I don't understand what I'm doing wrong. Any help would be gratefully received!
The problem is that not every API Action & Resource will accept the ec2:ResourceTag/tag in the condition.
I think you're probably granting overly-broad permissions (Action: ec2:*), so figure out what actions your instances will need do, and then decide how to restrict them.
The list of actions, resources and conditions keys can be found at Supported Resource-Level Permissions for Amazon EC2 API Actions.
I have ran into this issue before, it had something to do with combining wildcards and conditions. What solved it for us was being more explicit on the action (e.g ["ec2:DescribeInstances"]), and on the resource as well (arn:aws:ec2:region:accountid:instance/*).

Amazon AWS Management Console

I have problem with AWS API Gateway.
I create my own API and now i want that other users which are in the same group as me and have same roles to access this API via AWS Management console.
The problem is that other users can't see the API which i created (same problem with Lambda functions and DynamoDB which is also visible only for me, not for other users in group).
A simple but less secure solution is to assign the AmazonAPIGatewayAdministrator policy to the IAM Users, Groups, or Roles you want to be able to use the API Gateway. This will give them access to all APIs.
If you want to restrict access to a specific API or set of APIs you can create a custom IAM Policy for that API. You will then assign that Policy to the Roles and Groups you want to have access to the API. To create the policy, you will need the ID of the API. It's a long and convoluted process, but it works. Here are the steps:
Determine the ID of the API you want to provide access to by selecting the API Gateway service and clicking on the API. The URL in the browser will look like the following:
https://console.aws.amazon.com/apigateway/home?region=us-east-1#/apis/API_ID/resources/RESOURCE_ID
Copy the API_ID to your clipboard for use later.
Alternatively you can use the AWS CLI command: aws apigateway get-rest-apis and copy the ID from the result.
Create a new IAM Policy like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"apigateway:GET"
],
"Resource": [
"arn:aws:apigateway:*::/clientcertificates",
"arn:aws:apigateway:*::/restapis",
"arn:aws:apigateway:*::/restapis/*"
]
},
{
"Effect": "Allow",
"Action": [
"apigateway:*"
],
"Resource": [
"arn:aws:apigateway:us-east-1::/restapis/API_ID/*"
]
}
]
}
Attach the policy to the Users/Groups/Roles you want to have access. The first Effect allows the user to see all of the APIs but not modify them. You may want to remove this if you want to be more restrictive.
Amazon has a decent write-up of the IAM Policies for API Gateway here: http://docs.aws.amazon.com/apigateway/latest/developerguide/permissions.html