I've created a new eks cluster using terraform , couple of developers when they try to access the cluster in aws console get the following error.
Can someone pls point me what i'm missing.
cluster version: 1.18
User: arn:aws:iam::xxxx:user/yyy is not authorized to perform: eks:AccessKubernetesApi on resource: arn:aws:eks:us-east-1:xxxx:cluster/cluster
Each user has this policy attached
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"eks:ListFargateProfiles",
"eks:DescribeNodegroup",
"eks:ListNodegroups",
"eks:DescribeFargateProfile",
"eks:ListTagsForResource",
"eks:ListUpdates",
"eks:DescribeUpdate",
"eks:DescribeCluster",
"eks:ListClusters"
],
"Resource": "*"
}
]
}
my aws-auth config looks
apiVersion: v1
data:
mapRoles: |
- rolearn: arn:aws:iam::xxxx:role/cluster182020111918162137770000002f
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
- groups:
- system:masters
rolearn: arn:aws:iam::xxxx:role/abc-role
username: abc-xac
- groups:
- system:bootstrappers
- system:nodes
rolearn: arn:aws:iam::xxx:role/cluster_eks_worker_role
username: system:node:{{EC2PrivateDNSName}}
mapUsers: |
- groups:
- system:developers
userarn: arn:aws:iam::xxx:user/yyy
username: yyy
....
Its already mentioned that user dosen't have access to eks:AccessKubernetesApi in error.
Just add this to the IAM role.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"eks:AccessKubernetesApi",
"eks:ListFargateProfiles",
"eks:DescribeNodegroup",
"eks:ListNodegroups",
"eks:DescribeFargateProfile",
"eks:ListTagsForResource",
"eks:ListUpdates",
"eks:DescribeUpdate",
"eks:DescribeCluster",
"eks:ListClusters"
],
"Resource": "*"
}
]
}
Related
I am pretty new to AWS and struggling with role chaining for my github-actions-role.
I have a role “GithubActionsRole” which has the following Permissions:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity"
],
"Resource": [
"arn:aws:iam::ACCOUNT_NO:role/cdk-contactupd-deploy-role-ACCOUNT_NO-REGION
],
"Effect": "Allow"
}
]
}
And this Trust relationships:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::ACC_NO:oidc-provider/token.actions.githubusercontent.com"
},
"Action": [
"sts:AssumeRoleWithWebIdentity",
"sts:SetSourceIdentity"
],
"Condition": {
"StringLike": {
"token.actions.githubusercontent.com:sub": "repo:my-repo/sub-dir:*”
}
}
}
]
}
So now, the GithubActionsRole should assume the role “cdk-contactupd-deploy-role-ACCOUNT_NO-REGION”. This role is configured like this:
Persmissions:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"cloudformation:CreateChangeSet",
"cloudformation:DeleteChangeSet",
"cloudformation:DescribeChangeSet",
"cloudformation:DescribeStacks",
"cloudformation:ExecuteChangeSet",
"cloudformation:CreateStack",
"cloudformation:UpdateStack"
],
"Resource": "*",
"Effect": "Allow",
"Sid": "CloudFormationPermissions"
}
]
}
Trust relationships:
{
"Version": "2008-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::ACCOUNT_NO:root"
},
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity"
]
}
]
}
In my GitHub-action I execute the following:
…
- name: Set nonlive variables
run: |
echo "STAGE=nonlive" >> $GITHUB_ENV
echo "GITHUB_ROLE=arn:aws:iam::ACC_NO:role/GithubActionsRole" >> $GITHUB_ENV
- name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials#v1
with:
aws-region: MY_REGION
role-to-assume: ${{ env.GITHUB_ROLE }}
- run: aws sts get-caller-identity
- name: Deploy CDK Stacks
…
Unfortunately the last step is failing with the following Message:
failed: AccessDenied: User: arn:aws:sts::***:assumed-role/GithubActionsRole/GitHubActions is not authorized to perform: cloudformation:DescribeStacks on resource: arn:aws:cloudformation:...:stack/MY_STACK/... because no identity-based policy allows the cloudformation:DescribeStacks action.
But the "cloudformation:DescribeStacks"-policy should be allowed through the role chaining from the ""cdk-contactupd-deploy-role-ACCOUNT_NO-REGION" role.
I appreciate any idea how to fix it. I tried already a lot the last few days :/
When deploying Spinnaker to EKS via hal deploy apply, Spinnaker Clouddriver pod goes to CrashLoopBackOff with the following error,
Caused by: com.amazonaws.services.securitytoken.model.AWSSecurityTokenServiceException: User: arn:aws:sts::xxxxxxxxxxxx:assumed-role/Spinnaker-k8s-Worker-Node-Role/i-yyyyyyyyyyyyyyy is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::xxxxxxxxxxxx:role/Spinnaker-Managed-Role
My Halyard config is like follows,
currentDeployment: default
deploymentConfigurations:
- name: default
version: 1.17.6
providers:
appengine:
enabled: false
accounts: []
aws:
enabled: true
accounts:
- name: my-account
requiredGroupMembership: []
providerVersion: V1
permissions: {}
accountId: 'xxxxxxxxxxxx' # my account id here
regions:
- name: us-east-1
assumeRole: Spinnaker-Clouddriver-Role
lifecycleHooks: []
primaryAccount: my-account
bakeryDefaults:
baseImages: []
defaultKeyPairTemplate: '{{name}}-keypair'
defaultRegions:
- name: us-east-1
defaults:
iamRole: BaseIAMRole
My Spinnaker-Clouddriver-Role IAM role has PowerUserAccess permissions at the moment and has following as the Trust Relationship
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"ec2.amazonaws.com",
"ecs.amazonaws.com",
"application-autoscaling.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
},
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::xxxxxxxxxxx:role/Spinnaker-k8s-Worker-Node-Role"
},
"Action": "sts:AssumeRole"
}
]
}
How can I get this resolved?
The full log can be found on https://gist.github.com/agentmilindu/d9d31ee4287c87fb87e5060e0709989d#file-awssecuritytokenserviceexception-log-L3
Take a look at an AWS IAM policy that works flawlessly.
Refer to Armory AWS IAM set up and EC2 provider set up
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:*",
"cloudformation:*",
"ecr:*"
],
"Resource": [
"*"
]
},
{
"Action": "sts:AssumeRole",
"Resource": [
"arn:aws:iam::123456789012:role/SpinnakerManagedRoleAccount1",
"arn:aws:iam::101121314157:role/SpinnakerManagedRoleAccount2",
"arn:aws:iam::202122232425:role/SpinnakerManagedRoleAccount3"
],
"Effect": "Allow"
}
]
}
I have an infrastructure where SNS topic sends messages to SQS (using SNS subscription of course). When I setup the following access policy it works.
{
"Version": "2012-10-17",
"Id": "__default_policy_ID",
"Statement": [
{
"Sid": "SendMessagePolicy",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "SQS:SendMessage",
"Resource": "arn:aws:sqs:us-east-1:312226948869:mr-sandbox-loyalty",
"Condition": {
"ArnEquals": {
"AWS:SourceArn": "arn:aws:sns:us-east-1:312226948869:mr-sandbox-transaction-created"
}
}
}
]
}
BUT when instead of * I setting up arn:aws:iam::312226948869:root messages aren't sent to queue. The account number which I used is 312226948869. Any ideas?
Thanks.
UPDATE
In web console, when I'm trying to set Principal: 312226949769 it's overrided as Principal: arn:aws:iam::312226949769:root
I managed to fix the issue. I added IAM ARN to ArnEquals condition.
{
"Version": "2012-10-17",
"Id": "__default_policy_ID",
"Statement": [
{
"Sid": "SendersPolicy",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "sqs:SendMessage",
"Resource": "arn:aws:sqs:us-east-1:%account_id%:mr-prod-loyalty-program",
"Condition": {
"ArnEquals": {
"AWS:SourceArn": [
"arn:aws:iam::%account_id%:role/boss-mr-prod-sqs-dashboard",
"arn:aws:iam::%account_id%:role/IDT-PSF-Instance-Profile"
]
}
}
}
]
}
My solution ended up not using my specific account as principal but instead service of SNS. This should be fine since I have the condition of specific sns topic arn
Resources:
Policy:
Type: AWS::SQS::QueuePolicy
Properties:
PolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Principal:
Service:
- sns.amazonaws.com
Action:
- sqs:SendMessage
Resource: !GetAtt MySQS.Arn
Condition:
ArnEquals:
aws:SourceArn: !Ref MyTopic
Queues:
- !Ref MySQS
I am trying to create a CloudWatch rule that triggers on a schedule and executes a state machine (Step Functions). I'm using CloudFormation to create this, and everything creates fine except for the association of the IAM role used by the rule, to the rule itself. Here is what I mean:
Notice under 'Use Existing Role' it's blank.
Here is the CF template portion that deals with the rule and its role.
"SFInvoke":{
"Type": "AWS::IAM::Role",
"Properties": {
"AssumeRolePolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": {
"Fn::Sub": "states.${AWS::Region}.amazonaws.com"
}
},
"Action": "sts:AssumeRole"
}
]
},
"Policies": [
{
"PolicyName": "StepFunctionsInvoke",
"PolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"states:StartExecution"
],
"Resource": { "Ref" : "StateMachine"}
}
]
}
}
]
}
},
"CloudWatchStateMachineSDCEventRule": {
"Type":"AWS::Events::Rule",
"Properties": {
"Description":"CloudWatch trigger for the InSite Static Data Consumer",
"ScheduleExpression": "rate(5 minutes)",
"State":"ENABLED",
"Targets":[{
"Arn":{ "Ref" : "StateMachine"},
"Id":"StateMachineTargetId",
"RoleArn":{
"Fn::GetAtt": [
"SFInvoke",
"Arn"
]
}
}]
}
},
You want the SFInvoke role to show up on the Use existing role selector?
If that is the case, you need to set the Principal to events instead of states.
You're editing the event target in the screenshot above, not the step function. Principal defines the service that can assume the role, in your case that is the events service.
Try this for role creation:
"SFInvoke":{
"Type": "AWS::IAM::Role",
"Properties": {
"AssumeRolePolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "events.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
},
"Policies": [
{
"PolicyName": "StepFunctionsInvoke",
"PolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"states:StartExecution"
],
"Resource": { "Ref" : "StateMachine"}
}
]
}
}
]
}
}
Probably the Yaml would be as:
Based on the Principal: as an Events Based Services and Actions: to start the execution of a StepFunctions State Machine.
AWSEventsInvokeStepFunctions:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: Allow
Principal:
Service:
- events.amazonaws.com
Action: sts:AssumeRole
Policies:
- PolicyName: AWSEventsInvokeStepFunctions
PolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: Allow
Action:
- states:StartExecution
Resource: !Sub "arn:aws:states:${AWS::Region}:${AWS::AccountId}:stateMachine:*"
The Role which is now generic in nature can be applied to a CloudWatch Event Rule, gives Rule with the permissions to be able to start the Execution of a StepFunctions State Machine based on an Amazon S3 Event.
AmazonCloudWatchEventRule:
Type: AWS::Events::Rule
Properties:
EventPattern:
source:
- aws.s3
detail-type:
- 'AWS API Call via CloudTrail'
detail:
eventSource:
- s3.amazonaws.com
eventName:
- PutObject
requestParameters:
bucketName:
- !Ref EventBucket
Targets:
-
RoleArn: !GetAtt AWSEventsInvokeStepFunctions.Arn
Arn: !Sub "arn:aws:states:${AWS::Region}:${AWS::AccountId}:stateMachine:MyStateMachine"
Id: !Sub "StepExecution"
You can probably check more on Start the Execution of State Machine based on Amazon S3 Event
I am trying to create a new project in AWS CodeBuild. Every time I attempt to I receive the following error:
Not authorized to perform DescribeSecurityGroups
Any help would be greatly appreciated.
You are likely missing the VPC related permissions in your service role. You need to update the role to have the following policy:
https://docs.aws.amazon.com/codebuild/latest/userguide/auth-and-access-control-iam-identity-based-access-control.html#customer-managed-policies-example-create-vpc-network-interface
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface",
"ec2:DescribeDhcpOptions",
"ec2:DescribeNetworkInterfaces",
"ec2:DeleteNetworkInterface",
"ec2:DescribeSubnets",
"ec2:DescribeSecurityGroups",
"ec2:DescribeVpcs"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterfacePermission"
],
"Resource": "arn:aws:ec2:{{region}}:{{account-id}}:network-interface/*",
"Condition": {
"StringEquals": {
"ec2:Subnet": [
"arn:aws:ec2:{{region}}:{{account-id}}:subnet/[[subnets]]"
],
"ec2:AuthorizedService": "codebuild.amazonaws.com"
}
}
}
]
}
It means that associated IAM Role doesn't have attached policy allowing CodeBuild to describe Security Groups.
If you trying to create a new Build project and have selected "New Service Role" (Create a service role in your account), and in the same time added VPC, Subnets and Security Groups in Additional Configuration section - you will get "Not authorized to perform DescribeSecurityGroups" error.
For some reason AWS auto-created policy looks like:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Action": [
"ssm:GetParameters",
"logs:PutLogEvents",
"logs:CreateLogStream",
"logs:CreateLogGroup",
"ecr:UploadLayerPart",
"ecr:PutImage",
"ecr:InitiateLayerUpload",
"ecr:GetAuthorizationToken",
"ecr:CompleteLayerUpload",
"ecr:BatchCheckLayerAvailability"
],
"Resource": "*"
}
]
}
It's not allowing anything VPC/EC2 related, so you can either pre-create correct policy and use it, or let AWS create project without VPC, and modify new policy by adding required services in "Action" block:
"Action": [
"ssm:GetParameters",
"logs:PutLogEvents",
"logs:CreateLogStream",
"logs:CreateLogGroup",
"ecr:UploadLayerPart",
"ecr:PutImage",
"ecr:InitiateLayerUpload",
"ecr:GetAuthorizationToken",
"ecr:CompleteLayerUpload",
"ecr:BatchCheckLayerAvailability",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets"
],
I had this same issue when using cloudformation. The issue was the IAM role was being created before CodeBuild started creation, but the Policy attached the IAM role was being created after CodeBuild was created.
The remedy for this was to add a DependsOn to CodeBuild saying it needs the Policy to be created first.
Ex:
CodeBuildIamRole:
Type: 'AWS::IAM::Role'
Properties:
RoleName: 'CodeBuildAutomatedTestingRole'
AssumeRolePolicyDocument:
Statement:
- Action: 'sts:AssumeRole'
Effect: Allow
Principal:
Service: codebuild.amazonaws.com
Path: /
CodeBuildIamPolicy:
Type: 'AWS::IAM::Policy'
Properties:
PolicyName: !Sub 'CodeBuildServiceRolePolicy-${AWS::StackName}'
PolicyDocument:
Statement:
- Action:
- 's3:PutObject'
- 's3:GetObject'
- 's3:GetObjectVersion'
- 's3:ListBucket'
Effect: Allow
Resource: '*'
- Action:
- 'logs:CreateLogGroup'
- 'logs:CreateLogStream'
- 'logs:PutLogEvents'
- 'ec2:CreateNetworkInterface'
- 'ec2:DescribeDhcpOptions'
- 'ec2:DescribeNetworkInterfaces'
- 'ec2:DeleteNetworkInterface'
- 'ec2:DescribeSubnets'
- 'ec2:DescribeSecurityGroups'
- 'ec2:DescribeVpcs'
- 'ec2:CreateNetworkInterfacePermission'
- 'ecr:*'
- ...
Effect: Allow
Resource:
- '*'
Roles:
- !Ref CodeBuildIamRole
CodeBuild:
DependsOn:
- CodeBuildIamPolicy
Type: "AWS::CodeBuild::Project"
Properties:
...
Hopefully this is helpful