Only give user s3 read and write permissions for a bucket
Programmatic access
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:ListBucket"],
"Resource": ["arn:aws:s3:::test"]
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObject"
],
"Resource": ["arn:aws:s3:::test/*"]
}
]
}
If the Resource part is matched with test*, the two strategies can be merged into one, but this will also include other buckets starting with tets, so in the end, we will write two separately
2. Console access
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetBucketLocation",
"s3:ListAllMyBuckets"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": ["s3:ListBucket"],
"Resource": ["arn:aws:s3:::test"]
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObject"
],
"Resource": ["arn:aws:s3:::test/*"]
}
]
}
NoAction
To give users the permission to write sqs, the default approach is to give the FullAccess strategy, but the permissions of FullAccess are too large, and all sqs queues have write or even delete permissions.
Conversely, if according to the principle of aws least privilege, only the privileges of a certain sqs queue that the user will use are given, which is not conducive to the later expansion, because if the later users need to add new sqs queue privileges, they need to change frequently. Changing the iam strategy takes time and effort.
Can a compromise approach be adopted? At this time, you need to introduce the NoAction element in the iam strategy, and NoAction means an exception
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "SQSNoDeletePermission",
"Effect": "Allow",
"NotAction": "sns:DeleteQueue",
"Resource": "arn:aws:sqs:*:*:*"
}
]
}
The above strategy will give the user read and write permissions for all sqs, except for delete permissions
NoAction is not only applicable to sqs, but also applicable to other resources such as s3 and sns