I'm having an issue with a seemingly trivial task of getting CodeDeploy to deploy Github code to an AutoScaling Group in a Blue/Green Deployment.
I have a Pipeline setup, a Deployment Group setup, and the AutoScaling Group, but it fails when it gets to the actual deployment:
I went to my role and it seems like it has sufficient policies for it to go through with the blue/green deployment:
Is there a policy that I'm not considering that needs to be attached to this role?
I found the answer in this link:
https://h2ik.co/2019/02/28/aws-codedeploy-blue-green/
Without wanting to take the credit, only one statement was missing from #PeskyGnat :
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"iam:PassRole",
"ec2:CreateTags",
"ec2:RunInstances"
],
"Resource": "*"
}
]
}
I was also getting the error:
"The IAM role does not give you permission to perform operations in the following AWS service: AmazonAutoScaling. Contact your AWS administrator if you need help. If you are an AWS administrator, you can grant permissions to your users or groups by creating IAM policies."
I figured out the 2 permissions needed to get past this error, I created the policy below and attached it to the Code Deploy role:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:PassRole",
"ec2:RunInstances",
"ec2:CreateTags"
],
"Resource": "*"
}
]
}
Related
In the CI/CD section of the AWS SAM tutorial workshop, when I ran
sam pipeline init --bootstrap and went through the configurations, a role was created with this policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": "*",
"Resource": "*",
"Effect": "Allow"
}
]
}
Doesn't this grant the role complete permission over my AWS account which is a big no no? Or is it fine because the permission is granted to an AWS service, and not a user?
This is the trust relationship:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "cloudformation.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
Having a role that exists with those permissionsis fine.
When you create a vanilla AWS Account (in other words I am not including those created by enterprise landing zones like Control Tower) it comes with a policy called AdministratorAccess and a role called Administrator.
The best practice is in who or what you allow to use that policy and when.
Roles are preferred over users, since roles provide security credentials. With a user you have durable credentials you need to secure.
In this case you are allowing CloudFormation to assume this role. This makes sense since CloudFormation often needs to be able to create and modify any resources including IAM roles. If you know you will not be creating or modifying IAM resources you can user a more restrictive role (least privilege), for example using the PowerUserAccess policy which looks like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"NotAction": [
"iam:*",
"organizations:*",
"account:*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole",
"iam:DeleteServiceLinkedRole",
"iam:ListRoles",
"organizations:DescribeOrganization",
"account:ListRegions"
],
"Resource": "*"
}
]
}
I created a aws sagemaker user profile using terraform. I tried to launch the sagemaker studio from the user profile but was confronted with this error: SageMaker is unable to use your associated ExecutionRole [arn:aws:iam::xxxxxxxxxxxx:role/sagemaker-workshop-data-ml] to create app. Verify that your associated ExecutionRole has permission for 'sagemaker:CreateApp'. The role has sagemaker full access policy attached to it, but that policy doesn't have the createApp permission which is weird. Are there any policies I can attach to the role with the sagemaker createApp permission, or do I need to attach a policy to the role through terraform?
Make sure your execution role does not have any permission boundaries. By default, the SageMakerFullAccess policy allows create app permissions - see this statement -
{
"Effect": "Allow",
"Action": [
"sagemaker:CreatePresignedDomainUrl",
"sagemaker:DescribeDomain",
"sagemaker:ListDomains",
"sagemaker:DescribeUserProfile",
"sagemaker:ListUserProfiles",
"sagemaker:*App",
"sagemaker:ListApps"
],
"Resource": "*"
},
You can add an inline policy such as below to make sure your role has permissions to create app -
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowCreateApp",
"Effect": "Allow",
"Action": "sagemaker:CreateApp",
"Resource": "*"
}
]
}
Are you talking about arn:aws:iam::aws:policy/AmazonSageMakerFullAccess? If you take a look at this policy, you'll find this as one of the statements:
{
"Effect": "Allow",
"Action": [
"sagemaker:CreatePresignedDomainUrl",
"sagemaker:DescribeDomain",
"sagemaker:ListDomains",
"sagemaker:DescribeUserProfile",
"sagemaker:ListUserProfiles",
"sagemaker:DescribeSpace",
"sagemaker:ListSpaces",
"sagemaker:*App",
"sagemaker:ListApps"
],
"Resource": "*"
},
The sagemaker:*App action on "Resource": "*" means that the policy actually does have the sagemaker:CreateApp permission.
It is a common guardrail (even listed in the AWS Whitepaper on "SageMaker Studio Administration Best Practices") to limit notebook access to specific instances, and that guardrail denies on the CreateApp action. And the recommendation in the whitepaper is to control this at the service control policy level (in AWS Organizations, which you may not have visibility into), with this being an example policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "LimitInstanceTypesforNotebooks",
"Effect": "Deny",
"Action": [
"sagemaker:CreateApp"
],
"Resource": "*",
"Condition": {
"ForAnyValue:StringNotLike": {
"sagemaker:InstanceTypes": [
"ml.c5.large",
"ml.m5.large",
"ml.t3.medium",
"system"
]
}
}
}
]
}
I've followed a great tutorial by Martin Thwaites outlining the process of logging to AWS CloudWatch using Serilog and .Net Core.
I've got the logging portion working well to text and console, but just can't figure out the best way to authenticate to AWS CloudWatch from my application. He talks about inbuilt AWS authentication by setting up an IAM policy which is great and supplies the JSON to do so but I feel like something is missing. I've created the IAM Policy as per the example with a LogGroup matching my appsettings.json, but nothing comes though on the CloudWatch screen.
My application is hosted on an EC2 instance. Are there more straight forward ways to authenticate, and/or is there a step missing where the EC2 and CloudWatch services are "joined" together?
More Info:
Policy EC2CloudWatch attached to role EC2Role.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
ALL EC2 READ ACTIONS HERE
],
"Resource": "*"
},
{
"Sid": "LogStreams",
"Effect": "Allow",
"Action": [
"logs:CreateLogStream",
"logs:DescribeLogStreams",
"logs:PutLogEvents"
],
"Resource": "arn:aws:logs:*:*:log-group:cloudwatch-analytics-staging
:log-stream:*"
},
{
"Sid": "LogGroups",
"Effect": "Allow",
"Action": [
"logs:DescribeLogGroups"
],
"Resource": "arn:aws:logs:*:*:log-group:cloudwatch-analytics-staging"
}
]
}
In order to effectively apply the permissions, you need to assign the role to the EC2 instance.
I want to upload to S3 from a Fargate task. Can this be achieved by only specifying a ExecutionRoleArn as opposed to specifying a both a ExecutionRoleArn and a TaskRoleArn?
If I specify a ExecutionRoleArn that has the following Permission Policies attached:
Custom policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutObject"
],
"Resource": "arn:aws:s3:::example_bucket/*"
}
]
}
AmazonECSTaskExecutionRolePolicy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecr:GetAuthorizationToken",
"ecr:BatchCheckLayerAvailability",
"ecr:GetDownloadUrlForLayer",
"ecr:BatchGetImage",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "*"
}
]
}
With the following trust relationship:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": [
"events.amazonaws.com",
"lambda.amazonaws.com",
"ecs-tasks.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
Would this be sufficient to allow the task to upload to S3? Or do I need to define a TaskRoleArn?
The ExecutionRoleArn is used by the service to setup the task correctly, this includes pulling any images down from ECR.
The TaskRoleArn is used by the task to give it the permissions it needs to interact with other AWS Services (such as S3).
Technically both Arns could be the same, however I would suggest separating them to be different roles to avoid confusion over the permissions required for both of the scenarios the role is used for.
Additionally you should have the endpoint for ecs.amazonaws.com. In fact the full list of services depending on how you're using ECS are below (although most could be removed such as spot if you're not using spot, or autoscaling if you're not using autoscaling).
"ecs.amazonaws.com",
"ecs-tasks.amazonaws.com",
"spot.amazonaws.com",
"spotfleet.amazonaws.com",
"ecs.application-autoscaling.amazonaws.com",
"autoscaling.amazonaws.com"
In the case of Fargate, both IAM role pay different role
Execution Role
This is role is mandatory and you can not run the task without this role even if you add ExecuationRole policy in Task Role
To produce this error just set Execution role =None, you will not able to launch the task.
AWS Forums (Unable to create a new revision of Task Definition)
Task Role
This role is optional and you can add s3 related permission in this role,
Optional IAM role that tasks can use to make API requests to authorized AWS services.
Your police seems okay,
Create ecs_s3_upload_role
Add below policy
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutObject"
],
"Resource": "arn:aws:s3:::example_bucket/*"
}
]
}
Now Fargate Task will able to upload to S3 bucket.
Your policies don't include any s3 related permissions. Thus you should define your s3 permissions in a task role:
With IAM roles for Amazon ECS tasks, you can specify an IAM role that can be used by the containers in a task.
Created an AWS IAM policy for a user to give permission for only stopping and starting instance but if I give a particular instance ARN resource then it doesn’t work. Default EC2 Read only permission has been given to the user to describe EC2 instances and on top of that added customized sample policy as follows:
Sample policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"ec2:Describe*",
"ec2:StopInstances",
"ec2:RunInstances",
"ec2:StartInstances"
],
"Effect": "Allow",
"Resource": "*"
This works
"Resource": "arn:aws:ec2:<region>:<account id>:instance/<instance id>"
"Resource": "arn:aws:ec2:<region>:<account id>:instance/*"
"Resource": "arn:aws:ec2:<region>::instance/*"
"Resource": "arn:aws:ec2:::instance/*"
"Resource": "arn:aws:ec2:::*"
These doesn’t work
}
]
}
Edited on 23rd January (To Show what exactly I have done)
Objective: Start and stop instance permission on a single EC2 instance to a user.
Tested different combo policies but none of them worked except "Resource": "*":
Logged in: admin_user (Full access)
Created an instance as follows:
Region: Oregon
Availability zone: us-west-2c
Instance Id: i-xxx3dxxx32xxxxxxe
Owner: xxx23xxx11
Created a user: testec2_user
Permissions given to the user:
EC2 read only (available policy)
Customized policy to permit only stop and start i-xxx38xxx32xx45 instance as follows:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"ec2:Describe*",
"ec2:RunInstances"
],
"Effect": "Allow",
"Resource": "*"
},
{
"Action": [
"ec2:StopInstances",
"ec2:StartInstances"
],
"Effect": "Allow",
"Resource": "arn:aws:ec2:us-west-2c:xxx23xxx11:instance/i-xxx3dxxx32xxxxxxe"
}
] }
Logged in as testec2_user and tried starting up the stopped instance and received following error:
You are not authorized to perform this operation. Encoded authorization failure message
I have a plan for decoding the message received using sts decode authorization message of AWS.
DescribeInstances does not support resource-level permissions. (See Unsupported Resource-Level Permissions).
If an Amazon EC2 API action does not support resource-level
permissions, you can grant users permission to use the action, but you
have to specify a * for the resource element of your policy statement.
Read more
So, you could re-write your policy as:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"ec2:Describe*",
"ec2:RunInstances"
],
"Effect": "Allow",
"Resource": "*"
},
{
"Action": [
"ec2:StopInstances",
"ec2:StartInstances"
],
"Effect": "Allow",
"Resource": "arn:aws:ec2:<region>:<account>:instance/<instance-id>"
}
]
}
EDIT
RunInstances needs access to several resource types besides Instance (Such as Image, Key pair, Network interface, Placement group, Security group, Snapshot, Subnet and Volume) and accepts a specific ARN format for each resource type. So, arn:aws:ec2:<region>:<account id>:instance/* would not be enough and you'll get an UnauthorizedOperation error. The "Resource" element should either be:
"Resource": "*"
Which is the easiest way, or:
"Resource": [
"arn:aws:ec2:<region>:<account>:instance/*",
"arn:aws:ec2:<region>::image/*",
"arn:aws:ec2:<region>:<account>:key-pair/*",
"arn:aws:ec2:<region>:<account>:network-interface/*",
"arn:aws:ec2:<region>:<account>:placement-group/*",
"arn:aws:ec2:<region>:<account>:security-group/*",
"arn:aws:ec2:<region>::snapshot/*",
"arn:aws:ec2:<region>:<account>:subnet/*",
"arn:aws:ec2:<region>:<account>:volume/*"
]
Which is more complex but provides fine-grained control on each resource. For example, you can allow RunInstances execution for a specific EC2 image ID or subnet ID only. For more details, see the RunInstances section here.
Additional note on PassRole Permission
When executing RunInstances, if the EC2 instance should include an instance profile, the user who launches the EC2 instance must also have the IAM PassRole permission in order to associate a role with the instance during launch. For example:
{
"Version": "2012-10-17",
"Statement": [
...
{
"Action": "iam:PassRole",
"Effect": "Allow",
"Resource":"arn:aws:iam::<account>:role/<role-name>"
}
]
}
This way, you make sure that a user doesn't pass a role to an EC2 instance where the role has more permissions than you want the user to have.
For more info on granting permission to launch EC2 instances with IAM roles, see this AWS blog article.
This is how you specify multiple resources:
…
"Effect": "Allow",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::BUCKET-NAME/home/${aws:username}",
"arn:aws:s3:::BUCKET-NAME/home/${aws:username}/*"
]
}
]
}
Source:
http://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_examples.html
EDIT:
You can also use Conditions if you want to filter out instead of including all the required resources manually.