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.
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.
Is there any way to allow all instances created by a specific AWS account access to an S3 bucket?
I would like to provide data that should be very simple for clients to download to their instances. Ideally, automatically via the post_install script option of AWS ParallelCluster.
However, it seems like this requires a lot of setup, as is described in this tutorial by AWS:
https://aws.amazon.com/premiumsupport/knowledge-center/s3-instance-access-bucket/
This is not feasible for me. Clients should not have to create IAM roles.
The best I came up with at the moment is allowing S3 bucket access to a specific AWS account and then working with access keys:
export AWS_ACCESS_KEY_ID=<key-id>
export AWS_SECRETE_ACCESS_KEY=<secret-key>
aws s3 cp s3://<bucket> . --recursive
Unfortunately, this is also not ideal as I would like to provide ready-to-use AWS Parallelcluster post_install scripts. These scripts should automatically download the required data on cluster startup.
Is there any way to allow all instances created by a specific AWS account access to an S3 bucket?
Yes. It's a 2 step process. In summary:
1) On your side, the bucket must trust the account id of the other accounts that will access it, and you must decide which calls you will allow.
2) On the other accounts that will access the bucket, the instances must be authorised to run AWS API calls on your bucket using IAM policies.
In more detail:
Step 1: let's work through this and break it down.
On your bucket, you'll need to configure a bucket policy like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "111",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::ACCOUNT_ID_TO_TRUST:root"
},
"Action": "s3:*",
"Resource": "arn:aws:s3:::YOUR_BUCKET_NAME_HERE/*"
}
]
}
You can find more examples of bucket policies in the AWS documentation here.
WARNING 1: "arn:aws:iam::ACCOUNT_ID:root" will trust everything that has permissions to connect to your bucket on the other AWS account. This shouldn't be a problem for what you're trying to do, but it's best you completely understand how this policy works to prevent any accidents.
WARNING 2: Do not grant s3:* - you will need to scope down the permissions to actions such as s3:GetObject etc. There is a website to help you generate these policies here. s3:* will contain delete permissions which if used incorrectly could result in nasty surprises.
Now, once that's done, great work - that's things on your end covered.
Step 2: The other accounts that want to read the data will have to assign an instance role to the ec2 instances they launch and that role will need a policy attached to it granting access to your bucket. Those instances can then run AWS CLI commands on your bucket, provided your bucket policy authorises the call on your side and the instance policy authorises the call on their side.
The policy that needs to be attached to the instance role should look something like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": "s3:*",
"Effect": "Allow",
"Resource": "arn:aws:s3:::YOUR_BUCKET_NAME_HERE/*"
}
]
}
Keep in mind, just because this policy grants s3:* it doesn't mean they can do anything on your bucket, not unless you have s3:* in your bucket policy. Actions of this policy will be limited to whatever you've scoped the permissions to in your bucket policy.
This is not feasible for me. Clients should not have to create IAM roles.
If they have an AWS account it's up to them on how they choose to access the bucket as long as you define a bucket policy that trusts their account the rest is on them. They can create an ec2 instance role and grant it permissions to your bucket, or an IAM User and grant it access to your bucket. It doesn't matter.
The best I came up with at the moment is allowing S3 bucket access to a specific AWS account and then working with access keys:
If the code will run on an ec2 instance, it's bad practice to use access keys and instead should use an ec2 instance role.
Ideally, automatically via CloudFormation on instance startup.
I think you mean via instance userdata, which you can define through CloudFormation.
You say "Clients should not have to create IAM roles". This is perfectly correct.
I presume that you are creating the instances for use by the clients. If so, then you should create an IAM Role that has access to the desired bucket.
Then, when you create an Amazon EC2 instance for your clients, associate the IAM Role to the instance. Your clients will then be able to use the AWS Command-Line Interface (CLI) to access the S3 bucket (list, upload, download, or whatever permissions you put into the IAM Role).
If you want the data to be automatically downloaded when you first create their instance, then you can add User Data script that will execute when the instance starts. This can download the files from S3 to the instance.
I am going to Update existing Api gateway through aws cli commands (https://docs.aws.amazon.com/cli/latest/reference/apigateway/put-rest-api.html) from AWS CodePipeline and meet problem that CodeBuild has
An error occurred (AccessDeniedException) when calling the GetRestApis operation: User: arn:aws:sts:<skipped_text> is not authorized to perform: apigateway:GET on resource: arn:aws:apigateway:us-west-2::/restapis
Is it possible to update Api gateway through code using CodePipeline and aws cli?
Or What do you use as a tool for updating apigateway?
Make sure to add following policy to the IAM user in order to allow admin access (CREATE, READ, UPDATE, DELETE) to API gateway,
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"apigateway:*"
],
"Resource": "arn:aws:apigateway:*::/*"
}
]
}
which also exists under amazon managed policies, AmazonAPIGatewayAdministrator,
1) Please check your credential working properly or not ,It appears that the credentials used in your AWS SDK do not have valid permissions on the API Gateway API.
You will need to define a policy for the user/role similar to below.
http://docs.aws.amazon.com/apigateway/latest/developerguide/permissions.html
2) When using CloudFormation with CodePipeline, need to create a role that can be assumed by CloudFormation,CodePipeline moves releases through a pipeline using the role you specify for a pipeline. CloudFormation needs permission to assume a separate role that you create for the CloudFormation action (it's not enough to create a role with permission to access other resources).
References
http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/continuous-delivery-codepipeline-basic-walkthrough.html
https://s3.amazonaws.com/cloudformation-examples/user-guide/continuous-deployment/basic-pipeline.yml
aws forums
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
I am exploring IAM. I want to give access to a single ec2 instance to a user. I have created a policy for this as:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1392113879000",
"Effect": "Allow",
"Action": [
"ec2:*"
],
"Resource": [
"arn:aws:ec2:us-east-1:account:instance/instance_id"
]
}
]
}
But I am getting this error:
I have referred to this link
Any lead is appriciated.
The Resource-Level Permissions for EC2 and RDS Resources you are referring to are not yet available for all API actions, but AWS in gradually adding more, see this note from Amazon Resource Names for Amazon EC2:
Important Currently, not all API actions support individual ARNs; we'll add support for additional API actions and ARNs for additional
Amazon EC2 resources later. For information about which ARNs you can
use with which Amazon EC2 API actions, as well as supported condition
keys for each ARN, see Supported Resources and Conditions for Amazon
EC2 API Actions.
You will find that all ec2:Describe* actions are indeed absent still from Supported Resources and Conditions for Amazon EC2 API Actions at the time of this writing, and these are the ones required for listing resources e.g. in the AWS Management Console and triggering the errors you are seeing in turn ("You are not authorized to describe ...").
See also Granting IAM Users Required Permissions for Amazon EC2 Resources for a concise summary of the above and details on the ARNs and Amazon EC2 condition keys that you can use in an IAM policy statement to grant users permission to create or modify particular Amazon EC2 resources - this page also mentions that AWS will add support for additional actions, ARNs, and condition keys in 2014.