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?
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": "*"
}
]
}
I am trying to configure a trust relationship for a AWS IAM role in account 111111111111 so that a user with an assumed role from account 222222222222 can assume it. However, the sts:AssumeRole action is failing because AWS says that I'm not authorised.
Here is the trust relationship that I have set. I've had to define an overly permissive principal because AWS do not allow the use of wildcards in role session principals. I am however attempting to use a condition to restrict the principal.
Note that the AWS principal explicitly matched as arn:aws:iam::222222222222:role/my_lamda_function_role is allowed to assume that role - it seems as though the only issue is with wildcards.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "sts:AssumeRole",
"Condition": {
"ArnLike": {
"aws:PrincipalArn": [
"arn:aws:sts::222222222222:assumed-role/my_admin_role_name/*",
"arn:aws:iam::222222222222:role/my_lamda_function_role"
]
}
}
}
]
}
When I try to assume the role I see the following error.
An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:sts::222222222222:assumed-role/my_admin_role_name/my_session_name is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::111111111111:role/my_role_that_admins_can_assume
How can I amend my trust relationship to get it working?
I believe that my issue is related to my use of Condition in the policy, because when I explicitly add my STS session to the Principal I can assume the role as expected.
However, I wish for all sessions that assume the role my_admin_role_name to be allowed, so this approach is not viable and that is why I'm trying to use Condition with a wildcard.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:sts::222222222222:assumed-role/my_admin_role_name/my_session_name",
"arn:aws:iam::222222222222:role/my_lamda_function_role"
]
},
"Action": "sts:AssumeRole"
}
]
}
NOTE: similar question asked here, but no proper solution provided.
I setted up an EKS cluster via eksctl tool with single EC2 node. Deploy a Pod inside the EC2 node, this Pod writes the logs into s3 bucket. All worked fine when I used IAM user with key and secret. But now I want this Pod to use IAM Role instead. This Pod uses a newly created role with AmazonS3FullAccess permissions named prod-airflow-logs. According to the Docs, I also added "ec2.amazonaws.com" in this role's trust Relationship as follows;
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"s3.amazonaws.com",
"ec2.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
EC2 Node has its own Role named eksctl-prod-eks-nod-NodeInstanceRole-D4JQ2Q6D9GDA. If I understand correct, this role has to assume role prod-airflow-logs in order to allow container Pod to access and store logs in s3. According to the same Docs, I attached an in-line policy in this Node Role as follows;
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"iam:GetRole",
"iam:PassRole",
"ec2:*",
"iam:ListInstanceProfiles",
"iam:GetRolePolicy"
],
"Resource": "*"
}
]
}
But I still get following error in kubernetes pod when it tried to store logs on s3;
botocore.exceptions.ClientError: An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:sts::XXXXXXX:assumed-role/eksctl-prod-eks-nod-NodeInstanceRole-D4JQ2Q6D9GDA/i-0254e5b5b36e58f79 is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::XXXXXX:role/prod-airflow-logs
The only thing I don't understand from this error is, which user is it referring to ?
Where on earth is this user User: arn:aws:sts::XXXXXXX:assumed-role/eksctl-prod-eks-nod-NodeInstanceRole-D4JQ2Q6D9GDA/i-0254e5b5b36e58f79 ? Would appreciate if someone could point out what exactly I am missing here.
No answer yet... Here is how I made this work, I had to add the arn of Node Role into the trust policy of Pod Execution role.
In my case, the Pod execution role is prod-airflow-logs and the Node Role is eksctl-prod-eks-nod-NodeInstanceRole-D4JQ2Q6D9GDA.
The trust relationship of Pod execution has to be as follows;
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::XXXXXXX:role/eksctl-prod-eks-nod-NodeInstanceRole-D4JQ2Q6D9GDA"
},
"Action": "sts:AssumeRole"
}
]
}
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 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.