I have two iam roles,
allaccessrole (with complete aws account access)
limitedaccessrole (with very limited access to certain services only)
How do I utilize iam:passrole so that limitedaccessrole can utilize the permissions of allaccessrole for creating new resources(ex: a new iam user/ec2 instance)?
I added
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "*",
"Condition": {
"StringEquals": {"iam:PassedToService": "iam.amazonaws.com"}
}
}
]
}
to limitedaccessrole 's policy but when I try creating a new user, it still says
limitedaccessrole is not authorized to perform: iam:CreateUser on resource: arn:aws:iam::myaccnumber:user/new-user-m-trying-to-create
I also tried
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:sts::acc_num:role/limitedaccessrole",
"Condition": {
"StringEquals": {"iam:PassedToService": "iam.amazonaws.com"}
}
}
]
}
This also gives me:
limitedaccessrole is not authorized to perform: iam:CreateUser on resource: arn:aws:iam::myaccnumber:user/new-user-m-trying-to-create
In short is there a way to make limitedaccessrole
create resources (a new iam user + secrets) while utilizing a combination of IAM:Passrole and
an existing allaccessrole (which can do everything)
AND without giving "iam:CreateUser" permission to the limitedaccessrole.
Appreciate any inputs.
EDIT: I think I have a confused understanding of what IAM Passrole does. Looks like iam passrole is to be used when you want some service to have the same permissions as a specified role, but not when you want one role to take on the permissions of another role.
You want to use the sts:AssumeRole permission to accomplish what you're trying to achieve.
The workflow for this is below:
Resource A has Role A. Role A has permission sts:AssumeRole to allow it to assume Role B.
Resource A performs sts:AssumeRole to assume Role B. IAM key, secret key and session ID returned.
Resource performs interaction using SDK/CLI specifying specifically the three values returned.
To summarise, when you assume a role you use the credentials returned to act as the role. It is not automatic, you could support many roles.
Related
This question has been answered here but it didn't solve my problem.
I get the An error occurred (MalformedPolicyDocument) when calling the CreateRole operation: AssumeRole policy may only specify STS AssumeRole actions when I try to call aws iam create-role --role-name AutoscalingRole-Name --assume-role-policy-document file://./IAM_Trust_Policy.json
If my IAM_Trust_Policy.json contains only this code:
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": [
"ec2.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
}
It's working like a charm. But I needed something more, I'm creating an autoscaling role and I have a policy with these requirements:
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": [
"ec2.amazonaws.com",
"autoscaling.amazonaws.com"
]
},
"Action": [
"autoscaling:DescribeAutoScalingGroups",
"autoscaling:DescribeAutoScalingInstances",
"autoscaling:DescribeLaunchConfigurations",
"autoscaling:DescribeTags",
"autoscaling:SetDesiredCapacity",
"autoscaling:TerminateInstanceInAutoScalingGroup",
"ec2:DescribeLaunchTemplateVersions"
]
}
}
And for some reason I get the An error occurred (MalformedPolicyDocument) when calling the CreateRole operation: AssumeRole policy may only specify STS AssumeRole actions
Can anyone see where I'm wrong? Thanks
As #luk2302 commented, you are mixing up two policy types. Both are required for your Role to be useful:
Trust Policy: whom you allow to assume the role
This is your first policy document
Principal is required - this is whom you allow
Use this as the AssumeRolePolicyDocument parameter in CreateRole .
Access/Permissions Policies: the permissions the role will have
This is your second policy document
Principal is not allowed - makes no sense here
There are two ways to attach these permissions to your role (aka Identity-based Policies):
As a standalone Managed Policy with AttachRolePolicy
Or as an Inline Policy embedded in your role with PutRolePolicy
In other words, remove the Principal from your second policy document and call PutRolePolicy to embed it with your role.
You can not use role policy with assume-role-policy.
I think you are trying to rediscover the wheel.
AWS has one role for your need to autoscale AWSServiceRoleForAutoScaling managed role.
I have a user and I'm trying to impersonate a role for running a service on Kubernetes. However, when I tried using STS to assume the role, I get the following error:
$ aws sts assume-role --role-arn "arn:aws:iam::{ACCOUNT_ID}:role/service-myservice" --role-session-name AWSCLI-Session
An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::{ACCOUNT_ID}:user/me is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::{ACCOUNT_ID}:role/service-myservice
I find this odd because this user belongs to a user group with the AdministratorAccess permission attached to it, which should give it access to anything on AWS. This is it:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}
So, what am I doing wrong here?
What you have here is the IAM policy attached to this User, aka - what is this user is able to do.
You need to set the Trust Relationship as well. This defines which resources or principals is able to use this role/user. Could be Lambda, EC2 or in your case: an IAM User.
See here for example.
The IAM User/Role (in that case, role) you want to assume must have the Trust Relationship as follow:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<account_id>:role/<role_name>
},
"Action": "sts:AssumeRole"
}
]
}
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
I am trying to setup an API Gateway endpoint with a resource policy, which allows access to a specific IAM role in my account. The IAM role is cross-account, setup with a trust policy which allows AssumeRole to a specific IAM user principal from another account.
In the API Gateway resource policy, when I set AWS principal to the role ARN: arn:aws:iam::********:role/myRole, I get the following 403 error when invoking the API:
User: arn:aws:sts::********:assumed-role/myRole/mySession is not authorized to perform: execute-api:Invoke on resource: arn:aws:execute-api:us-west-2:********:********/test/POST/echo
But, if I change the AWS principal to be the temporary STS user ARN: arn:aws:sts::********:assumed-role/myRole/mySession, then I can invoke the API successfully.
Here's the resource policy that doesn't work:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::********:role/myRole"
},
"Action": "execute-api:Invoke",
"Resource": "arn:aws:execute-api:us-west-2:********:********/*"
}
]
}
Here's the resource policy that works:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:sts::********:assumed-role/myRole/mySession"
},
"Action": "execute-api:Invoke",
"Resource": "arn:aws:execute-api:us-west-2:********:********/*"
}
]
}
Can IAM roles be used as AWS principals for API Gateway resource policy?
Based on the documentation https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-policy-language-overview.html,
Principal – The account or user who is allowed access to the actions
and resources in the statement. In a resource policy, the principal is
the IAM user or account who is the recipient of this permission.
Looks like roles cannot be added as a principal.
P.S: Spent two days trying to restrict access using roles, but couldn't get it to work.
I want to create a policy where the user is restricted from creating a role without my permission boundary! i tried using iam:AttachRolePolicy and Iam:putRolePermissionBoundary but not working still!
The config you are attempting would be accomplished if you granted the user the iam:CreateRole permission with a condition. For example if your permission boundary is a a policy called myPermissionBoundary then attaching the policy below would allow the user to create a role IFF the user also attached the permission boundary to that role.
{
"Sid": "CreateRoleIffPermInPlace",
"Effect": "Allow",
"Action": [
"iam:CreateRole"
],
"Resource": *,
"Condition": {
"StringLike": {
"iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/myPermissionBoundary"
}
}
}