I'm trying to make an IAM policy through which I can allow the user to run the tests in API Gateway without making changes to the resources. What policy should I grant the user?
Use below policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "execute-api:Invoke",
"Resource": "*"
}
]
}
If you need more details, please check this Doc: https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-control-access-using-iam-policies-to-invoke-api.html
Related
In the CI/CD section of the AWS SAM tutorial workshop, when I ran
sam pipeline init --bootstrap and went through the configurations, a role was created with this policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": "*",
"Resource": "*",
"Effect": "Allow"
}
]
}
Doesn't this grant the role complete permission over my AWS account which is a big no no? Or is it fine because the permission is granted to an AWS service, and not a user?
This is the trust relationship:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "cloudformation.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
Having a role that exists with those permissionsis fine.
When you create a vanilla AWS Account (in other words I am not including those created by enterprise landing zones like Control Tower) it comes with a policy called AdministratorAccess and a role called Administrator.
The best practice is in who or what you allow to use that policy and when.
Roles are preferred over users, since roles provide security credentials. With a user you have durable credentials you need to secure.
In this case you are allowing CloudFormation to assume this role. This makes sense since CloudFormation often needs to be able to create and modify any resources including IAM roles. If you know you will not be creating or modifying IAM resources you can user a more restrictive role (least privilege), for example using the PowerUserAccess policy which looks like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"NotAction": [
"iam:*",
"organizations:*",
"account:*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole",
"iam:DeleteServiceLinkedRole",
"iam:ListRoles",
"organizations:DescribeOrganization",
"account:ListRegions"
],
"Resource": "*"
}
]
}
What I am trying to is using my IAM user udagram-xue-dev to assume the role of eksClusterRole. This is my policies configures:
This policy has been add to my IAM user:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111111111111:role/eksClusterRole"
}
]
}
This trust policy has been added to my eskClusterRole:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111111111111:user/udagram-xue-dev",
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
but I still get this problem:
I have read a lot of relevant details about this assuming role problem, but I still can't figure out how to fix it. It seems that they all just need to add these policies, then it'll be OK.
According to your configuration, everything seems to be in place. However, there might be a different policy (permission boundary, service control policy, or another IAM policy applied to the user) that overrides the permissions.
You can test your policies and find out if there’s anything interfering with your permissions using the IAM Policy Simulator.
Having some issues with AWS permissions and policies for grafana to be able to upload images. First off I tried with a custom policy attached to my user based on the requirements here https://grafana.com/docs/installation/configuration/#access-key.
Here's the policy:
custom policy with locked down permissions and bucket name
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:PutObjectAcl"
],
"Resource": "arn:aws:s3:::myclient-grafana-images"
}
]
}
This unfortunately didn't work and can see an access denied error in my grafana logs. The user is trying to write an image to the bucket and ended up adding the AWS predefined policy for s3 full access. This managed to get it working
s3 full access policy
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*"
}
]
}
The question is trying to lock the policy down just to the bucket that I need. I've tried creating a new policy with the full access policy and updated the wildcard to reference the s3 arn but that didn't work either.
Any suggestions on the best way to lock down the policies.
The PutObject and PutObjectAcl actions work on objects, not buckets.
This means that your Resource key should represent objects. ARN for objects start with the bucket name but are followed by a / and a path.
You should adapt your policy in the following way if you want to be able to put any object in your bucket (note the /*):
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:PutObjectAcl"
],
"Resource": "arn:aws:s3:::myclient-grafana-images/*"
}
]
}
I'm using this policy to a user that can create other users, but I need to restrict this user to only create users with permissions on S3, that's because, currently, he can create users with permissions on all services, like EC2 or IAM.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:GetFederationToken",
"Resource": "*"
}
]
}
Are there any samples to create that policy with the restriction for users to create other users having permission only on S3?
Try this
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:*",
"Resource": "*"
}
]
}
Should an IAM User say called User1 be given full access like so:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}
Could it also be used to create Amazon API calls? Is this a security risk or should I create another user just to access the Amazpn API Gateway?
You should never give an IAM user full privileges. So many things could go wrong, and yes it may very well be a security risk.
If you need to manage (create, configure, or deploy) your API in API Gateway with this IAM user, you can give the user this policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"apigateway:*"
],
"Resource": "arn:aws:apigateway:*::/*"
}
]
}
Or, if you only need to invoke the API, you can use this policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"execute-api:Invoke"
],
"Resource": "arn:aws:execute-api:*:*:*"
}
]
}