I am not able to start an OpsWorks instance after I have created the Instance within an OpsWorks Layer, which is part of an OpsWorks Stack. The error that I get after attempting to start the 24/7 instance is the following:
An error occurred while starting the instance java-app1
OpsWorks failed to obtain the necessary credentials to start the instance on your behalf. Please try again after waiting a minute. If this error persists, please check the permissions of the stack IAM role.
The error indicates that I don't have my permissions set correctly for the IAM Role of my Stack. I have created an OpsWorks Stack that contains a reference to a Role ARN that has the AWSOpsWorksFullAccess and AWSOpsWorksRole policies set for the Role's permissions. I would have thought one of those two policies would be enough.
I can create a OpsWorks Layer within that Stack, and create an OpsWorks instance as well. The created instance uses the DefaultInstanceProfileArn of the Stack. In my case, that ARN references a Role that contains the following policies:
AmazonEC2FullAccess
AWSOpsWorksFullAccess
AWSOpsWorksRole
AmazonS3FullAccess
I know that the policies that I have applied are very broad, but at this point I'm just trying to get an OpsWorks instance to start. What policy needs to be applied in order for OpsWorks to have the correct permissions to start an instance within my Stack?
This is a bit late :-)
I had that issue recently.
The roles that are attached are:
AmazonEC2FullAccess
AWSOpsWorksFullAccess
AWSOpsWorksCMServiceRole
This gives me create, start, stop and delete.
This confused me the most. Passing this mountant brings a lot of sights.
Open stack-setting, you will find your current IAM ROLE
Follow the document below to attach an inline policy.
https://docs.aws.amazon.com/opsworks/latest/userguide/opsworks-security-servicerole.html
If you create a custom service role, you must ensure that it grants all the permissions that AWS OpsWorks Stacks needs to manage your stack. The following JSON sample is the policy statement for the standard service role; a custom service role should include at least the following permissions in its policy statement.
{
"Version": "2008-10-17",
"Statement": [
{
"Action": [
"ec2:*",
"iam:PassRole",
"cloudwatch:GetMetricStatistics",
"cloudwatch:DescribeAlarms",
"ecs:*",
"elasticloadbalancing:*",
"rds:*"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"iam:PassedToService": "ec2.amazonaws.com"
}
}
}
]
}
A bit late, but the easiest way to solve this if you are just trying out opsworks is to create a service role with EC2 full access.
This should allow for the creation of the stack
Related
I am learning AWS and I have the following task in an online training course:
Configure the MongoDB VM as highly privileged – configure an instance
profile to the VM and add the permission “ec2:*” as a custom policy.
I am trying to work out what that means. Is the task asking for a role that enables the VM instance to have full control over all EC2 resources?
If I understand it correctly, then I think the following policy would implement it.
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"ec2:*"
],
"Effect": "Allow",
"Resource": "arn:aws:ec2:*:*:instance"
}
]
}
My understanding is that this policy is saying any EC2 instance can perform any EC2 action. Is that right?
I would say you are almost correct. Roles are attached to individual services which means your particular VM can perform any Ec2 action on this resource arn:aws:ec2:*:*:instance.
There is a difference in saying any ec2 can perform ec2 action instead that ec2 instance can perform any ec2 action to which this role is attached.
I'm facing some very weird issues when it comes to policies and managed instances. For example, one of my users is getting this error:
User: arn:aws:iam::708332864XX:user/XXXX is not authorized to perform: ssm:StartSession on resource: arn:aws:ssm:us-east-2:708332864XX:managed-instance/mi-055c2be5596fXXXXX
However, when looking at the policies, I don't have the ability to select a managed-instance as a resource:
If I try to just simply replace instance with managed-instance, then it says the ARN is invalid:
How would I give a user ssm:StartSession permission on managed instances then in this case? The following policy does nothing:
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"ssm:TerminateSession",
"ssm:StartSession"
],
"Resource": [
"arn:aws:ssm:us-east-2:708332864587:managed-instance/*"
]
}
Apparently this doesn't do anything:
Notice how the managed instance ARN is for the arn:aws:ssm namespace:
arn:aws:ssm:us-east-2:708332864XX:managed-instance/mi-055c2be5596fXXXXX
You are trying to add permission for the arn:aws:ec2 namespace, which is why it isn't working.
TLDR; I would suggest to use the instance ARN instead. I would also verify that your role have access to all documents or at least to SSM-SessionManagerRunShell.
The long explanation:
If you read about StartSession in https://docs.aws.amazon.com/service-authorization/latest/reference/list_awssystemsmanager.html you can learn that
for StartSession you have in the Resrouce column three different Resource types
Actions
Description
Access Level
Resource
StartSession
Grants permission to initiate a connection to a specified target for a Session Manager session
write
document instance task
Each of them has a different ARN structure:
document - arn:${Partition}:ssm:${Region}:${Account}:document/${DocumentName}
instance - arn:${Partition}:ec2:${Region}:${Account}:instance/${InstanceId}
task - arn:${Partition}:ecs:${Region}:${Account}:task/${TaskId}
You can put any other ARNs in the rule, but they will have no effect. But in one they or other the user need access to all the required resources.
For example (mentioned in the other answer as well): In your question you have
aws:arn:ec2:.....:managed-instance with quote: "If I try to just simply replace instance with managed-instance, then it says the ARN is invalid". Yes, because it is. You cannot just combine the parts of ARNs randomly. Valid ARNs are only the documented ones: https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html
When you describe your "managed instance" you should see in it an id of an EC2 instance. This is the only instance which does exist. The ssm "managed instance" is a structure which stores only the ssm-related data for that particular EC2 instance.
`
If you read the example policy in the AWS documentation for StartSession you see there:
https://docs.aws.amazon.com/systems-manager/latest/userguide/getting-started-restrict-access-quickstart.html
So you you need to figure out how to get the ec2 instance id from the managed instance id like for example with
https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-information.html
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:region:987654321098:instance/i-02573cafcfEXAMPLE",
"arn:aws:ssm:region:account-id:document/SSM-SessionManagerRunShell"
],
"Condition": {
"BoolIfExists": {
"ssm:SessionDocumentAccessCheck": "true"
}
}
},
--cut--
Keep in mind that in AWS you may not be able to limit access per resource level for all services. That's especially for newer services. Or you may not be able to do it easily. For example you can create a lambda function which will start your ec2 instance and will create a policy for it (I don't say that you should do it that way, but it is possible).
Sometimes you can use conditions or you can use PassRole/AssumeRole mechanism to allow access to the resource by a mechanism which is outside of the IAM service. You may need to be creative and/or sometimes compromise.
It seems to be impossible to allow developers to create Lambdas and create or maintain SAM Applications in AWS without essentially having AdministratorAccess policies attached to their developer's role. AWS documents a suggested IAM setup where everyone is simply Administrator, or only has IAMFullAccess, or a even more specific set of permissions containing "iam:AttachRolePolicy" which all boils down to still having enough access to grant the AdministratorAccess permission to anyone at will with just 1 API call.
Besides creating a new AWS Account for each SAM or Lambda deployment there doesn't seem to be any secure way to manage this, but I really hope I'm missing something obvious. Perhaps someone knows of a combination of tags, permission boundaries and IAM Paths that would alleviate this?
The documentation I refer to: https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-permissions.html which opens with:
There are three main options for granting a user permission to manage
serverless applications. Each option provides users with different
levels of access control.
Grant administrator permissions.
Attach necessary AWS managed policies.
Grant specific AWS Identity and Access Management (IAM) permissions.
Further down, a sample application is used to specify slightly more specific permissions:
For example, the following AWS managed policies are sufficient to
deploy the sample Hello World application:
AWSCloudFormationFullAccess
IAMFullAccess
AWSLambda_FullAccess
AmazonAPIGatewayAdministrator
AmazonS3FullAccess
AmazonEC2ContainerRegistryFullAccess
And at the end of the document an AWS IAM Policy document describes a set of permissions which is rather lengthy, but contains the mentioned "iam:AttachRolePolicy" permission with a wildcard resource for roles it may be applied on.
AWS has a PowerUserAccess managed policy which is meant for developers. It gives them access to most of the services and no access to admin activities including IAM, Organization and Account management.
You can create an IAM Group for developers (Say Developers) and add the managed policy PowerUserAccess to the group. Add developers to this group.
For deploying with SAM, the developers would need a few IAM permissions to create roles, tag roles. While rolling back a CloudFormation Stack, they may need a few delete permissions. While allowing the developers to create new roles for Lambda functions, you need to ensure they don't escalate privileges by using permissions boundary. A good starting point again would be to set the permissions boundary to PowerUserAccess. (until you figure out what is the right level of permissions)
Create a Policy something like this
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ReadRole",
"Effect": "Allow",
"Action": [
"iam:GetRole",
"iam:GetRolePolicy",
"iam:ListRoleTags"
],
"Resource": "arn:aws:iam::ReplaceWithYourAWSAccountNumber:role/*FunctionRole*"
},
{
"Sid": "TagRole",
"Effect": "Allow",
"Action": [
"iam:UntagRole",
"iam:TagRole"
],
"Resource": "arn:aws:iam::ReplaceWithYourAWSAccountNumber:role/*FunctionRole*"
},
{
"Sid": "WriteRole",
"Effect": "Allow",
"Action": [
"iam:DeleteRole",
"iam:DeleteRolePolicy",
"iam:AttachRolePolicy",
"iam:PutRolePolicy",
"iam:PassRole",
"iam:DetachRolePolicy"
],
"Resource": "arn:aws:iam::ReplaceWithYourAWSAccountNumber:role/*FunctionRole*"
},
{
"Sid": "CreateRoleWithPermissionsBoundry",
"Effect": "Allow",
"Action": [
"iam:CreateRole"
],
"Resource": "arn:aws:iam::ReplaceWithYourAWSAccountNumber:role/*FunctionRole*",
"Condition": {
"StringEquals": {
"iam:PermissionsBoundary": "arn:aws:iam::aws:policy/PowerUserAccess"
}
}
}
]
}
Note: It assumes the Lambda function names in the SAM template contains the word Function in them. (Replace the AWS Account Number in the ARNs).
Now you can attach the above policy to the Developers IAM Group. (This would give the SAM deployment permissions to all the developers)
Or you can create another IAM Group for SAM developers (Say SAM-Developers) and attach the above policy to the SAM-Developers group. Now add the appropriate developers (who need to deploy using SAM) to this new IAM group (SAM-Developers).
Define the Permissions Boundary in the SAM templates as well.
Here is an example PermissionsBoundary in SAM template.
Globals:
Function:
Timeout: 15
PermissionsBoundary: arn:aws:iam::aws:policy/PowerUserAccess
With that, the developers should be able to deploy using SAM provided they do not have any restrictive permission boundary.
You can set the permission boundary to AdministratorAccess for the developers or create a new Policy which combines the permissions of PowerUserAccess and the above defined policy for 'SAM' deployments. Then set this new Policy as the permission boundary for the developers.
This solution is for reference and you can build upon this. The PowerUserAccess has been set as the permissions boundary for the Lambda function roles. The PowerUserAccess is too permissive and you should further work on this to find out the right level of permission for your developers and the Lambda functions.
Sidenote: You can use this policy to allow the users to manage their own credentials.
I've create a new iam role that i would like my instance to run as so that I can give it specific permissions to other resources my instance will need (eg parameter store, it's database instance, etc).
The default role aws-elasticbeanstalk-ec2-role had 4 policies attached to it: AWSElasticBeanstalkWebTier, AmazonSESFullAccess, AWSElasticBeanstalkMulticontainerDocker, AWSElasticBeanstalkWorkerTier.
So I created a role like my-app-role that has the same 4 policies plus the one policy specific to this application.
However when I change the eb configuration(via console) to use this new role for it's instances, it spins for a while and ultimately displays this error with very little information:
I noticed that there is a bucket for elastic beanstalk called elasticbeanstalk-us-east-1-(arn) that mentions the default elastic beanstalk role so I added another policy to my-app-role to grant access to that bucket as such:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucketVersions",
"s3:ListBucket",
"s3:GetObjectVersion"
],
"Resource": [
"arn:aws:s3:::elasticbeanstalk-us-east-1-(arn)/resources/environments/*",
"arn:aws:s3:::elasticbeanstalk-us-east-1-(arn)"
]
}
]
}
However the same error occurs. There must be some permission I am still missing despite this. Does anyone know what you must do to properly create a custom eb instance role??
I just ran into the above issue and AWS support helped me out. Turns out when you first use a custom IAM instance profile with Elastic Beanstalk, it makes a call to its S3 bucket (elasticbeanstalk-<region>-<account>; e.g. elasticbeanstalk-us-east-1-123456789012) and adds the new IAM role to the bucket's policy. In my case, the bucket policy was referring to a test IAM user that had long ago been deleted, but this reference to a no-longer-valid/existing user caused S3 to complain that the policy was now invalid/"malformed". Elastic Beanstalk would try for exactly 13 minutes to make its change (to the S3 bucket's policy) and would then fail with "S3_MALFORMED_POLICY" error. Removing the reference to the no-longer-existing user from the Elastic Beanstalk S3 bucket resolved the issue.
I'm trying to launch a test task in a ECS Fargate environment from the AWS console, but every time I try to launch it, I have the error:
Execution Role Failed creation of AmazonECSTaskExecutionRole
I supposed that it was a permissions error, so I asked the account owner (I am a IAM user of another account) to give me them, and now I do but still doesn't work.
My current permissions for ECS are:
AmazonECS_FullAccess
AmazonECSTaskExecutionRolePolicy
The worst thing is that AWS doesn't give any kind of information about this error. Anyone have an idea of how to make it work?
Thank you in advance!
You need the "iam:createRole" permission.
The solution is to add the "iam:createRole" permission.
To do that add this policy to your IAM Policies:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1469200763880",
"Action": [
"iam:AttachRolePolicy",
"iam:CreateRole"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
I was having this same issue, it wasn't related to my permissions but rather the task setup trying to access an ECR image.
I needed to create a new IAM Role that gave ECS Task access to my ECR repo, then attach that Role to Execution Role ARN for the task definition. This fixed it for both CLI and Console creation for me.