Giving access to AWS Lambda service with limited policy - amazon-web-services

I am trying to follow this tutorial to setup a lambda function to shutdown/startup instances with a special tag added to ec2 instances.
The policy assigned to my role by Admin user gives me access to all lambda function e.g by
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudwatch:*",
"cognito-identity:ListIdentityPools",
"cognito-sync:GetCognitoEvents",
"cognito-sync:SetCognitoEvents",
"dynamodb:*",
"events:*",
"iam:ListAttachedRolePolicies",
"iam:ListRolePolicies",
"iam:ListRoles",
"iam:PassRole",
"kinesis:DescribeStream",
"kinesis:ListStreams",
"kinesis:PutRecord",
"lambda:*",
"logs:*",
"s3:*",
"sns:ListSubscriptions",
"sns:ListSubscriptionsByTopic",
"sns:ListTopics",
"sns:Subscribe",
"sns:Unsubscribe"
],
"Resource": "*"
}
]
}
I am stuck as step 6 while setting Lambda function handler and role while selecting "Basic execution role" with error
User: arn:aws:iam::xxxx:user/Yyyy is not authorized to perform:
iam:CreateRole on resource: arn:aws:iam::xxxx:role/lambda_basic_exec
My role policy looked sth like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "arn:aws:logs:*:*:*"
},
{
"Effect": "Allow",
"Action": [
"ec2:Describe*",
"ec2:Start*",
"ec2:RunInstances",
"ec2:Stop*",
],
"Resource": "*"
}
]
}
That seems reasonable given my limited rights.
What should I ask my Admin to update policy assigned to me, so I can successfully set scheduled event for lambda function as described in tutorial ? Or this can be done in some other way around using IAM e.g by adding new role ? I want only sufficient rights.

As some time has passed since this question was answered and AWS changed a lot, I want to mention a new feature which was launched by AWS in 2018: Permissions Boundaries for IAM Entities [1].
They are used "to delegate permissions management to trusted employees" [2] and other IAM entities (such as roles).
That is, you do not need to grant a specific role admin-like permissions in order to create other roles as the accepted answer states. You may grant the role iam:CreateRole permission with a condition that requires a permission boundary being set on each newly created role: {"StringEquals": {"iam:PermissionsBoundary": "arn:aws:iam::111122223333:policy/XCompanyBoundaries"}}.
The policy which is specified by the permission boundary defines the maximum permission which are effectively assigned to the role. [1]
In order to create a role with a permission boundary you can e.g. use the optional parameter --permissions-boundary for the cli command aws iam create-role. [3]
References
[1] https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html
[2] https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/
[3] https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html

you have a security constraint, as you would need the "iam:CreateRole" in your policy, along with something like "iam:attachRolePolicy" and "iam:createPolicy". So with that you would basically be admin of your account, as you could create roles with any policy and attach it to an EC2 instance or assume it directly.
What you could do is having your admin create one or several roles for lambda, e.g one for S3 access, one for ec2 commands etc. When you want then to create a lambda function, choose one of these pre-created roles instead of creating a new one.

Related

How can an IAM role be restricted to gain higher permission than it itself is allowed, through role chaining?

I have a role named ThisRole with following deny permissions:
{
"Sid": "DenyPolicies",
"Effect": "Deny",
"Action": [
"iam:AddUserToGroup",
"iam:AttachGroupPolicy",
"iam:AttachUserPolicy",
"iam:CreateGroup",
"iam:CreateLoginProfile",
"iam:CreateUser",
"iam:DeleteUser",
"iam:DeleteLoginProfile",
"iam:DeleteAccountPasswordPolicy",
"iam:DeleteGroup",
"iam:DeleteGroupPolicy",
"iam:DeleteOpenIDConnectProvider",
"iam:DeleteUserPolicy",
"iam:DeleteVirtualMFADevice",
"iam:DetachGroupPolicy",
"iam:DetachUserPolicy",
"iam:EnableMFADevice",
"iam:RemoveUserFromGroup",
"iam:UpdateGroup",
],
"Resource": "*"
}
And following allow permissions:
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
I do want ThisRole to create new roles, create new and update existing IAM policies. Which is why iam:CreateRole and the likes are not denied. But this leaves the back door open for this role to:
Create a new role (lets say NewRole).
Allow this NewRole all the permissions itself is denied upon.
Assume this NewRole (role chaining).
Execute permissions that are otherwise denied for ThisRole.
What is the best way to allow ThisRole to create new roles/policies, modify existing roles/policies or assume another role but only within the limits of what it itself is allowed to do?
Your best option is to use Permissions Boundary.
In this way you will allow them to create roles but they will be forced to use the permissions boundary you define, restricting them on what they can do.
Two links below will explain you more:
Permissions Boundaries for IAM Entities - AWS Identity and Access Management
Delegate permission management to developers by using IAM permissions boundaries | AWS Security Blog

AWS IAM Policy grant permissions for some EC2 instances

I want to restrict access for a specific user to see just few EC2 instances. I created a new user in IAM Roles and I attached a new Policy to it. The content of that Policy is attached below. I tried to look over documentation and to do it myself like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:*",
"Resource": [
"arn:aws:ec2:eu-west-1:ACCOUNT_ID:instance/i-INSTANCE_ID1",
"arn:aws:ec2:eu-west-1:ACCOUNT_ID:instance/i-INSTANCE_ID2"
]
}
]
}
I placed my region,ACCOUNT_ID(the owner id, not of the new user created) and instance-id, but when I connect with that user and I go to list all Instances I got this An error occurred fetching instance data: You are not authorized to perform this operation..
After I placed the code in JSON editor, in Policy Review step I got this message:
This policy defines some actions, resources, or conditions that do not
provide permissions. To grant access, policies must have an action
that has an applicable resource or condition. For details, choose Show
remaining Learn more
The AWS documentation mention exactly the same configuration or these examples.
I assume you connect as that user in the console (but it would be the same with CLI) Here is what I think is happening:
To list all the instances, the console most probably calls the DescribeInstances API. As per the list of action/resources/tags that can be used in IAM policy, this API does not support the resource filter in IAM.
This means your user has no authorization to list instances and they will not be shown in the console. You can validate this theory by using the CLI to request the details of a specific instance id, if my hypothesis is correct, it will be authorized.
As DescribeInstances can not be restricted by resource or tags, I don't think it is possible to filter the instance list for a user.
To have the console working, you'll need to add the following statement in your IAM policy
"Statement": [
{ your existing statement },
{
"Effect": "Allow",
"Action": "ec2:DescribeInstances",
"Resource": "*"
}
]
Please report if I was right :-) The example you mentioned in your question shows exactly that : Resources = * on DescribeInstances and Resources specific InstanceId on other operations.
The previous answer is wrong, you can Conditionally allow access to ec2:DescribeInstances by tag names. It's an AWS best practice as well. Also explicitly deny access to the ec2:CreateTags and ec2:DeleteTags actions to prevent users from creating or deleting tags to take control of the instance.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:DescribeInstances",
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/UserName": "${aws:username}"
}
}
},
{
"Effect": "Deny",
"Action": [
"ec2:CreateTags",
"ec2:DeleteTags"
],
"Resource": "*"
}
]
}
DescribeInstances action does not support condition.
https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html

AWS PowerUserAccess cannot list roles when creating VM, but policy shows it as allowed

I've assigned the policy PowerUserAccess to a group. The Policy for that is:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"NotAction": [
"iam:*",
"organizations:*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole",
"iam:DeleteServiceLinkedRole",
"iam:ListRoles",
"organizations:DescribeOrganization"
],
"Resource": "*"
}
]
}
In the second permission, it appears iam:ListRoles is granted. However, when I attempt to create a VM, and try to view the roles I'd like to assign to it, I get the message "You do not have permissions to list any IAM roles. Contact your administrator, or check your IAM permissions."
Should I be able to assign a role to an EC2 instance as a power user? Is there another permission that needs to be granted?
No, the PowerUserAccess policy does not allow that. You need to include iam:ListInstanceProfiles to view the IAM roles which can be attached to EC2 instances and iam:Passrole to attach the role to instances.

Unable to launch EC2 with IAM role as a member of Administrators group

On AWS member of Administrators group is unable to launch EC2 instances with IAM role. The same user can create IAM roles and even manage users in IAM console.
User seems to have all possible permissions. What could be missing?
The documentation states you need ec2:RunInstances, ec2:AssociateIamInstanceProfile, ec2:ReplaceIamInstanceProfileAssociation and iam:PassRole. Do they have all of those?
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:RunInstances",
"ec2:AssociateIamInstanceProfile",
"ec2:ReplaceIamInstanceProfileAssociation"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "*"
}
]
}
Apparently rights were OK. The mistake was made when creating the role. For instance roles EC2 had to be selected on the first step (not the desired access). Permissions were available on the next step.

Allow user to manage EC2 by its tags

I am trying to enable access to EC2 for our vendor . So, what I did : I add tag "Vendor" for dedicated EC2 instances .
Then , I add policy below ..
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:*",
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/Vendor": "Takamol"
}
}
},
{
"Effect": "Deny",
"Action": [
"ec2:CreateTags",
"ec2:DeleteTags",
"ec2:TerminateInstances"
],
"Resource": "*"
}
]
}
Nevertheless , the user (who belongs to group that attaches) cannot see any EC2 instance even the policy condition restricts by tag "Vendor" (as you notice) .
How can allow user to manage only EC2 instances which has tag : Vendor = Takamol
What you're trying to achieve isn't possible. This is because of a concept called "Resource Level Permissions". Actions that support Resource level permissions allow you to use IAM to allow/deny a user the ability to perform an action on some subset of the resources in question, e.g. EC2 instances with a particular tag, S3 buckets, VPCs etc. Actions that don't support Resource Level Permissions can only be allowed/denied for ALL resources, and can only be allowed to a user in a statement where the resource is * and where there are no conditions.
Unfortunately for you, not all EC2 Actions support Resource Level Permissions. The reason that your user can't see any EC2 instances with the above IAM policy is that the ec2:Describe* API calls (used in the console to list all the instances in the account) do NOT support resource level permissions.
So even though ec2:Describe* falls under ec2:* which you allow for tagged instances in the first statement in the policy, ec2:Describe* with a condition evaluates to DENY all ec2:Describe*.
What people usually end up doing is allowing the vendor access to see all instances in the account and then only allow them the additional permissions they need for a particular set of instances. See the policy below, it will allow the user to see all instances but only start, stop and reboot instances with the required tag.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowSeeEverything",
"Effect": "Allow",
"Action": [
"ec2:Describe*"
],
"Resource": [
"*"
]
},
{
"Sid": "ThingsIAllowThemToDoForTaggedEc2s",
"Effect": "Allow",
"Action": [
"ec2:RebootInstances",
"ec2:StartInstances",
"ec2:StopInstances"
],
"Condition": {
"StringEquals": {
"ec2:ResourceTag/Vendor": "Takamol"
}
},
"Resource": [
"*"
]
}
]
}
The list of what EC2 API calls support resource level permissions along with what conditions are supported is documented in Supported Resource-Level Permissions for Amazon EC2 API Actions. I also recommend reading the Demystifying EC2 Resource-Level Permissions
blog post.