I have deployed elastic beanstalk which has a role MyEBSRole in Account A. I would like to give this role access to Event Bridge in other account (Account B) (cross account). In Account B Event Bridge, I have added the following resource based policy:
{
"Sid": "mysid",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<Account-A-ID>:role/MyEBSRole"
},
"Action": ["events:PutRule", "events:ListRules", "events:DeleteRule", "events:DescribeRule", "events:DisableRule", "events:EnableRule", "events:PutTargets", "events:RemoveTargets"],
"Resource": "arn:aws:events:<Region>:<Account-B-ID>:rule/*",
"Condition": {
"StringEqualsIfExists": {
"events:creatorAccount": "${aws:PrincipalAccount}"
}
}
}
But I am getting the following exception:
An error occurred (AccessDeniedException) when calling the ListRules operation: User: arn:aws:sts::<Account-A-ID>:assumed-role/MyEBSRole/i-0b68xxxxxxx is not authorized to perform: events:ListRules on resource: arn:aws:events:<Region>:<Account-B-ID>:rule/*
If I replace the principal in resource based policy to this:
"Principal": {
"AWS": "arn:aws:iam::<Account-A-ID>:root"
}
Then I am able to get result via cloud shell, but with Elastic beanstalk it is still not working.
I also tried with arn:aws:sts::<Account-A-ID>:assumed-role/MyEBSRole/i-0b68xxxxxxx in principal but it also does not work.
Could anyone please, indicate what is wrong or missing there? Thank you.
Related
I several lambda functions on my account to be able to access a secret.
(I cannot use identity policies, don't ask why)
I am following this example from the official documentation so I am creating this resource based policy
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"lambda.amazonaws.com"
]
},
"Action": "secretsmanager:GetSecretValue",
"Resource": "*",
"Condition": {
"ArnLike": {
"aws:sourceArn": "arn:aws:lambda::1234567891911:*"
},
"StringEquals": {
"aws:sourceAccount": "1234567891911"
}
}
}
]
}
My lambda invocation fails as follows:
"An error occurred (AccessDeniedException) when calling the GetSecretValue operation: User: arn:aws:sts::1234567891911:assumed-role/my-secret-name/my-lambda-name is not authorized to perform: secretsmanager:GetSecretValue on resource: ps-shield-token because no identity-based policy allows the secretsmanager:GetSecretValue action",
????
I don't see the problem. Your policy example is valid for services that support service-linked roles1. Lambda functions do not support service-linked roles. Therefore, the policy example is not valid for Lambda.
Service-linked roles, which are AWS-managed, are referenced by service name in resource-based policies, as in the OP. For instance, the principal { “Service”: “elasticloadbalancing.amazonaws.com” } refers to the AWS-managed ELB service-linked-role, which is called AWSServiceRoleForElasticLoadBalancing. Again, there's no equivalent lambda.amazon.aws option here, because Lambda has no service-linked role2.
Functions have user-managed execution roles. Execution roles (EC2 Instances and ECS Tasks have something similar) are referenced by the role ARN in the resource-based policy "Principal": { AWS: <Lambda Role Arn> }, as in #jellycsc's answer.
Although the docs could definitely be clearer, your Example: Service principal does refer to just to service-linked roles. The first link on the page, AWS Service Principal, refers to "service principal" as used "services that support service-linked roles".
Lambda#Edge does support service-linked roles.
It's not the lambda service that's getting the secret value. The lambda service first assumes the execution role which you set in your lambda function, and the execution role is the principle of the secretsmanager:GetSecretValue action. Therefore, the following policy should work.
{
"Version": "2012-10-17",
"Statement":
[
{
"Effect": "Allow",
"Principal":
{
"AWS": "arn:aws:iam::1234567891911:role/<lambda-execution-role-name>"
},
"Action": "secretsmanager:GetSecretValue",
"Resource": "*"
}
]
}
Customer managed key associated with topic with the following key policy:
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::XXXXXXXXXX:root"
},
"Action": "kms:*",
"Resource": "*"
}
According to this:
https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html
The evaluated permissions are a union of resource and identity policies (if you disregard policy boundaries and explicit denies).
So my question: my ECS task execution role is still complaining about missing permissions:
arn:aws:sts::XXXXXXXXX:assumed-role/ecs-task-role/XXXXX is not authorized to perform: kms:GenerateDataKey on resource: arn:aws:kms:eu-west-1:XXXXXXXXX:key/XXXXXXXX
I can of course add kms:GenerateDataKey++ to the identity policy of the role in question, but why is this necessary?
My organisation uses a gateway account for which i have aws credentials.
We also have our personal account, in order to access our personal account users in gateway account assume IAM roles ( created in the personal account).
With such configuration i am trying to create terraform resource but somehow keep on getting error -> Error: operation error STS: AssumeRole, https response error StatusCode: 403, RequestID: xxxxxxx, api error AccessDenied: User: arn:aws:iam::xxxxxx:user/xx-xxxxxx is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::xxxxxxx2:role/xxxxxx
Here is the provider configuration i am trying.
provider "aws" {
alias = "mad"
profile = "personal account"
region = "ap-south-1"
assume_role {
role_arn = "arn:aws:iam::xxxxxxx:role/personal account"
}
}
Update :- the role uses mfa too.
Personal account has trust relationship which allows gatgeway account iam user to assume to role.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::gateway-account-id:user/user"
},
"Action": "sts:AssumeRole",
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
}
}
]
}
The user user/xx-xxxxxx which you use to run the TF script which is going to assume role role/xxxxxx must have sts:AssumeRole.
You can add such permission to the user, by adding the following inline policy to it:
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": [
"arn:aws:iam::xxxxxxx2:role/xxxxxx"
]
}
UPDATE
Also for MFA you need to use token option in your provider configuration, or use any of the workarounds provided in TF github issue.
My IAM user has the below two policies attached to it.
I created the below IAM policy that prevents lambda from being created if it does not have the Project tag.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Deny",
"Action": "lambda:*",
"Resource": "*",
"Condition": {
"Null": {
"aws:RequestTag/Project": "true"
}
}
}
]
}
I also need to attach/create a new execution role when creating lambda so I added below
Iam policy to my IAM user.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Action": "iam:*",
"Resource": "*"
}
]
}
I logged into aws console using that IAM user's credentials and tried to create the lambda function without the tag, but it did'nt block the resource creation.I was able to create the lambda function without the required tag but with the following errors.
You are not authorized to perform: cloudformation:DescribeStackResources.
You are not authorized to perform: lambda:GetFunctionEventInvokeConfig.
User: arn:aws:iam::****:user/testuser is not authorized to perform: lambda:ListEventSourceMappings on resource: * with an explicit deny (Service: AWSLambda; Status Code: 403; Error Code: AccessDeniedException; Request ID: 199433ed*****)
How can I completely block the resource creation?
https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_example-scps.html#example-require-tag-on-create
Eventually I want to try aws:RequestTag/{TageKey} for all supported aws resources.
Not all AWS services/resources support aws:RequestTag as a condition key.
For lambda it is not allowed. Currently the supported condition keys on lambda:CreateFuncion Action are:
lambda:Layer
lambda:VpcIds
lambda:SubnetIds
lambda:SecurityGroupIds
lambda:CodeSigningConfigArn
As specified on table "Actions defined by AWS Lambda" on column "Condition keys".
https://docs.aws.amazon.com/service-authorization/latest/reference/list_awslambda.html#awslambda-actions-as-permissions
You can check that link and review any other service and validate if a specific Action support the Condition that you need.
For example, for EC2:RunInstances https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html supported conditions are:
aws:RequestTag/${TagKey}
aws:TagKeys
ec2:AvailabilityZone
ec2:EbsOptimized
ec2:InstanceMarketType
ec2:InstanceProfile
ec2:InstanceType
ec2:IsLaunchTemplateResource
ec2:LaunchTemplate
ec2:MetadataHttpEndpoint
ec2:MetadataHttpPutResponseHopLimit
ec2:MetadataHttpTokens
ec2:PlacementGroup
ec2:Region
ec2:RootDeviceType
ec2:Tenancy
So in that case you can restrict creation on new EC2 instances based on the presence of Tags but for Lambda it is not supported (for now).
I have the following IAM Role:
AmazonEC2FullAccess
Custom-Policy
In my custom policy I have:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": "iam:ListRoles",
"Resource": "*",
"Condition": {
"IpAddress": {
"aws:SourceIp": "10.0.0.0/16"
}
}
}
]
}
Then I create a new EC2 instance and attach this role to it.
Inside the EC2 Instance I try to do:
aws iam list-roles
But I get this error:
An error occurred (AccessDenied) when calling the ListRoles operation:
User: arn:aws:sts::XXXXXXX:assumed-role/My-Role/i-XXXXXX is not
authorized to perform: iam:ListRoles on resource:
arn:aws:iam::XXXXXXX:role/
Do you have an idea why it's not working, please? thanks.
PS: The EC2 instance's IP is 10.0.0.XX
The IAM API lives on the Internet. Thus, when it receives your request, it will be coming from the IP address of the instance. IAM never sees the private IP address of the instance.
In theory, the IP address restriction should not be necessary because the role can only be used on instances where it has been assigned. You should put security on who can use the role (iam:PassRole), rather than from where the role can be used.