I want to add permissions to my instance's IAM roles to allow for the use of Cloudwatch Log Service. Upon looking at the Configuration Guide for the service, I see the following passage:
The CloudWatch Logs agent supports IAM roles and users.
If your instance already has an IAM role associated with it, make sure that you include the IAM policy below.
If you don't already have an IAM role assigned to your instance,
you'll need to use your IAM credentials for the next steps because you cannot assign an IAM role to an existing instance;
you can only specify a role when you launch a new instance.
I'm having a hard time figuring exactly what this means. When I created a new instance, I made an IAM role with the CloudWatchLogsFullAccess policy and an inline policy the configuration guide tells you to add:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents",
"logs:DescribeLogStreams"
],
"Resource": [
"arn:aws:logs:*:*:*"
]
}
]
}
This was for a new instance, however the above passage confuses me about adding permissions to existing instances. Can I just add the CloudWatchLogsFullAccess policy to the existing instance's role and that inline policy as well?
While it was true an IAM role can be assigned to an instance only during instance launch, AWS announced in February 2017 that it is now possible to replace or attach an IAM role to an existing instance.
Using AWS Console: Easily Replace or Attach an IAM Role to an Existing EC2 Instance by Using the EC2 Console
Using AWS CLI: Attach an AWS IAM Role to an Existing Amazon EC2 Instance by Using the AWS CLI
Related
We have just built a new Things Enterprise server hosted at AWS on an EC2 instance and created an application to use AWS IOT. We are getting the following error
“message”: “User: arn:aws:sts::446971925991:assumed-role/Things-Enterprise-Stack-Srv-StackIAMRole-DBHBSMSY05AQ/i-095895d605fab3fa4 is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::446971925991:role/Bosh-Parking-IOT-Stack-TheThingsStackRoleCD9FBAD2-C44RRJJ53M93”
I have been told
What is the execution role of the TTES instance that is trying to assume the role? The role TTES needs to be able to assume that role. That will give the right permissions.
But I'm not sure what that means, i'm presuming i need to add / alter some permissions within an IAM role. Can someone point me in the right direction Pls.
From the error message it seems that your IAM role for Amazon EC2 has no permissions to assume a role Bosh-Parking-IOT-Stack-TheThingsStackRoleCD9FBAD2-C44RRJJ53M93.
To add such permissions manually you can do the following:
Go to IAM Console->Roles.
In the Roles window, you can use Search bar to locate Things-Enterprise-Stack-Srv-StackIAMRole-DBHBSMSY05AQ role.
Once you find the role, you click on Add inline policy.
Once Create policy window shows, you can go to JSON tab and add the following JSON policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowAssumeRole",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::446971925991:role/Bosh-Parking-IOT-Stack-TheThingsStackRoleCD9FBAD2-C44RRJJ53M93"
}
]
}
Then click Review Policy, name the policy (e.g. PolicyToAssumeRole) and Create policy
However, based on your policy names (e.g. Stack-Srv-StackIAMRole) it is possible that they have been create by CloudFormation. If this is the case, then manually changing the roles as described above is a bad practice and will lead to drift. Any changes to resources created by CloudFormation should be done using CloudFormation. Sadly, your question does not provide any details about CloudFormation templates used, therefore its difficult to comment on that more.
I am checking the steps of setting up IAM auth in RDS: https://aws.amazon.com/premiumsupport/knowledge-center/users-connect-rds-iam/ And one of the steps is to attach the IAM role with proper permission: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.IAMPolicy.html
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds-db:connect"
],
"Resource": [
"arn:aws:rds-db:us-east-2:1234567890:dbuser:db-ABCDEFGHIJKL01234/db_user"
]
}
]
}
The resource follows this format:
arn:aws:rds-db:region:account-id:dbuser:DbiResourceId/db-user-name
If I understand correctly, as long as I know someone's account-id, DbiResourceId and db-user-name (or maybe db-user-name as I can use wildcard?), then I am able to connect to that DB instance, right?
This sounds insecure. Did I miss anything?
No this would not be possible. The only want to interact with this resource would be to assume a role in the target account.
You can use an IAM role to allow someone (a trusted principal) in a different account to access resources in your account. Roles are the primary way to grant cross-account access. However, with some AWS services, you can attach a policy directly to a resource (instead of using a role as a proxy). To learn the difference between roles and resource-based policies for cross-account access, see How IAM Roles Differ from Resource-based Policies in the IAM User Guide
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.
The policies attached to the IAM developers group I've set up are as follows:
However, launching new instances won't work. Just after a user in this group selects the key pair to associate with it, i.e. reaches the final step, they get the following message on the next page:
Launch Failed
You are not authorized to perform this operation. Encoded authorization failure message: WZzytnkJ4T3-nkMYslM...
What's preventing developers to launch new instances, given these policies?
It could be that the instance is being launched with an IAM Role, and the group does not have iam:PassRole permissions (which are outside of the ec2:* permissions space).
You should add a policy like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PassRoleToEC2",
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "*"
}
]
}
This saying "Allow this user to pass any (*) role to an EC2 instance".
Actually, you should limit such permissions only to specific roles, otherwise a normal user could select an Admin role. Then, if they logged into the instance, they would have access to credentials that have Admin permissions on the whole AWS Account.
Alternatively, do not select a Role when launching the instance. It should then launch okay (assuming that this is the issue causing the error).
The user needs a PassRole permission.
A Role must be associated with the "Launch" of the EC2 instance.
The PassRole permission helps 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.
As in the following example, if the EC2 Launch requires access to S3 you User must be able to pass the S3 role required.
{
"Effect":"Allow",
"Action":"iam:PassRole",
"Resource":"arn:aws:iam::123456789012:role/S3Access"
}
Link to documentation:
https://aws.amazon.com/blogs/security/granting-permission-to-launch-ec2-instances-with-iam-roles-passrole-permission/
Is there a way to grant IAM instance roles to be used by the build process?
In my particular case I need to perform some s3 operations during build (unrelated to archiving artifacts).
So far the only alternative I found is to add an aws key and secret to the environment variables on the aws codebuild configuration page.
It would be more secure to just attach an IAM role to the ec2 instance or container executing the build. Is that currently (2016-12) possible?
You should be able to attach any additional policy permissions to the service role that was created for your build project. CodeBuild uses that policy during build time to execute actions within a build instance.
For example, if you wanted to delete an object from S3 during build, you would need to add the following statement to your service role policy:
{
"Effect": "Allow",
"Resource": [
"*"
],
"Action": [
"s3:DeleteObject"
]
}
Note: You may wish to restrict these permissions to specific resources, the example above allows DeleteObject on anything in your account.
If you used the first-run wizard on the CodeBuild console to setup your project, you should already have policies in your service role for s3:GetObject and s3:GetObjectVersion. The service role name when creating via the console is 'codebuild-[project name]-service-role' by default.