When using the web UI for AWS Elastic Beanstalk Environment management, I see:
Code change deployments will complete faster if you associate an
instance profile with this environment.
(also see this forum post mentioning the same thing: http://www.infosys.tuwien.ac.at/staff/leitner/cs_study/forum/viewtopic.php?pid=186#p186)
What is an instance profile? Why does it matter? How does it work / what is it doing?
I found these articles:
http://docs.aws.amazon.com/IAM/latest/UserGuide/instance-profiles.html
http://docs.aws.amazon.com/cli/latest/reference/iam/create-instance-profile.html
but I still don't understand instance profiles.
Like Celine said in the comment above, instance profiles allow you to associate an IAM role to your instance. This IAM role must be provided with certain permissions to access your AWS resources. Your EC2 instance (launched by Elastic Beanstalk) can then perform certain extra tasks. For example if you launch a worker tier environment with Elastic Beanstalk the daemon needs to poll from SQS queue, publish metrics to cloudwatch from the EC2 instance. This means that the EC2 instance needs some credentials to poll from a queue. If you have an IAM role with appropriate policies associated with the EC2 instance you essentially permit your instance to call SQS using the credentials of that role.
You can do other interesting things like automatic log publication to your S3 bucket if you have an instance profile associated with your environment.
Having an instance profile allows you to control permissions you want to give to the instance and also frees you from storing long term credentials on all your EC2 instances.
From the documentation:
Instance profiles provide applications and services access to AWS
resources. For example, your application may require access to
DynamoDB. Every API request made to AWS services must be signed using
AWS security credentials. One way to grant applications access to AWS
resources is to distribute your credentials to each instance; however,
distributing long-term credentials to each instance is challenging to
manage and a potential security risk. Instead, you can create an IAM
role with the permissions that applications require when the
application makes calls to other AWS resources. When AWS Elastic
Beanstalk launches the Amazon EC2 instances, it uses the instance
profile associated with that role. All applications that run on the
instances can use the role credentials to sign requests. Because role
credentials are temporary and rotated automatically, you don't have to
worry about long-term security risks.
The message you are seeing on the console regarding console is recommending you to use an instance profile because that allows your EC2 instance to take a faster path to deploy your application version each time you update your environment with a new copy of your source code. The end result is the same but having an instance profile enables optimizations in deployment speed which are not possible without one.
You can read more about instance profiles with Elastic Beanstalk here.
Although you can create a custom role and associate it with a beanstalk environment by giving it appropriate permissions, you can for convenience just get a default role when you launch an environnment using the AWS console. You will have the option of choosing which role you want to associate with an environment in the create environment wizard.
Related
I was reading Default VPC and Default Subnets - Amazon Virtual Private Cloud about default VPC creation by AWS. Under default VPC components, it states "Amazon creates the above VPC components on behalf of the customers. IAM policies do not apply to those actions because the customers do not perform those actions".
My question is, we need to create an IAM role for an AWS service to call another AWS service, e.g., EC2 invoking S3, but why does IAM policy not work when the AWS builds resources on our behalf?
Thanks in advance for any input.
In your example of Amazon EC2 connecting to Amazon S3, it is actually your program code running on an Amazon EC2 instance that is making calls to Amazon S3. The API calls to S3 need to be authenticated and authorized via IAM credentials.
There are also situations where an AWS service calls another AWS service on your behalf using a service-linked role, such as when Amazon EC2 Auto Scaling launches new Amazon EC2 instances. This requires provision of a Service-Linked Role for Amazon EC2 Auto Scaling, which gives one service permission to call another service.
In the case of creating a Default VPC, this is something that AWS does before an account is given to a customer. This way, customers can launch resources (eg an Amazon EC2 instance) without having to first create a VPC. It is part of the standard account setup.
It appears that AWS has also exposed the CreateDefaultVpc() command to recreate the Default VPC. The documentation is saying that permission to make this API call is sufficient for creating the resources, without requiring permissions for each underlying call that it probably generates. I guess it is using the permissions that would normally be associated with a service-linked role, except that there is no service-linked role for VPC actions. If you are concerned about people creating these resources (eg an Internet Gateway), you can deny permissions on users for being able to call CreateDefaultVpc(), which will prevent them from using the command.
Think of our AWS account as the "root" and AWS essentially has a "super root" account that they can trigger the initial creation of your account with. This all occurs when your account is initially set up and configured since they have that "super root" level of access just as part of being the product owners.
We are limited (and I assume AWS is limited in a different way) by IAM to allow us to use the Principle of Least Privilege
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html . I don't understand what the docs are trying to convey.
When you see the first line in the section service role for an EC2 instance , It says the "It is a special type of service role that a service assumes to launch an Amazon EC2 instance that runs your application." Later it says "This role is assigned to the EC2 instance when it is launched". Which doesn't make any sense (self-contradicting)
You have asked a very interesting question.
First, move your comment about EC2 instance into your question. This will make your question better and clearer on what you are asking.
The difference between "AWS Service Role for an EC2 instance" and "AWS Service Role" is in the sentence:
"AWS automatically provides temporary security credentials that are attached to the role and then makes them available for the EC2 instance to use on behalf of its applications."
EC2 gets one set of credentials based upon your IAM User permissions to create and launch the EC2 instance. You can then assign a different set of permissions (temporary security credentials from an IAM Role) that the applications on the EC2 instance can use.
There are other AWS services that this description would fall into. Lambda, ECS, etc. I think that this specific topic is legacy from the days when EC2, S3, DynamoDB were the major services. Today, the service offering is vast.
Think of it like this: When you are building your new house, you need one set of permissions for the construction. Later when you move into the house you need a different set of permissions.
https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html
As Mentioned:A set of permissions that grant access to actions and resources in AWS. These permissions are attached to the role, not to an IAM user or group.
These Permission are used to grant or revoke the Access of services used into the AWS Server.
According to this document link.
AWS service role: This Like Admin role By which we configure what other user can do or assign permission to them.
AWS service role for an EC2 instance EC2 is instance of application. Tis role attach with instance. So by there permission assigned to that role application will able to connect to other services like S3 storage, IAM User configuration etc.
This link says
To create the IAM role
Open the IAM console.
In the navigation pane, select Roles, then Create New Role.
Enter a name for the role, then select Next Step. Remember this name, since you'll need it when you launch your Amazon EC2 instance.
On the Select Role Type page, under AWS Service Roles, select Amazon EC2.
On the Set Permissions page, under Select Policy Template, select Amazon S3 Read Only Access, then Next Step.
On the Review page, select Create Role.
But when you click "Create New Role", you will be asked as follows
They say "choose a service that will use this role"
a) As you launch an app in ElasticBeanStalk which in turn creates an Ec2 instance , should I select Ec2 service or Elastic beanstalk service?
You are creating an EC2 instance role, so the service to select is EC2, regardless of whether or not the instances are being spawned and managed by Elastic Beanstalk.
With an instance role, your instance has continuous access to a set of automatically-rotated temporary credentials that it can use to access whatever services the role policies grant access to.
Here, you are granting the EC2 service permission to actually obtain those temporary credentials on behalf of your instance.
Rule of thumb with AWS, only create the resources you need. The reason for this is that AWS charges you for everything that you use. Now with that said, if you only need an EC2 that can communicate with your S3, then go with an EC2 only. EC2's are sorta like your base server, and you can always link one to your Elastic Beanstalk (if in fact you want to utilize that service later on).
Note, if you eventually begin using your S3 to show content to your users (e.g. your images, videos, etc.), then you should use CloudFront as your CDN to control things like caching, speed, and availability across various regions.
Hope this helps.
The AWS document merely is an example (Apply IAM on EC2). You don't need follow the document mechanically, because your case is different, applying IAM on different type(s) of AWS services.
I have a scaling group of several EC2 instances.
I have API keys which I would like to distribute to the instances using round-robin.
How can I code the instances to get the credentials once they go live?
Is there an AWS service for that?
It is not AWS credentials which could be solved by defining IAM Roles.
Thanks
Use "user data" option when you start your EC2 instance, You can run the bash script.
I recommend the following step.
1-put your cred or other shared information to S3 or dynamoDB.
2-write script to read and setting this data when your EC2 was starting.
The closest thing AWS has to this is called IAM Roles. A role includes a set of IAM permissions (like an IAM user). When you start a VM, you can set the role of the VM. The VM can then call the AWS API and get temporary credentials that give it access to the services that are defined in the IAM role.
See here for more details:http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html
This does not exactly meet your requirement for round-robin credentials distribution. But it might be a better option. IAM roles are as secure a method of distributing credentials to EC2 instances as you can get.
AWS now provides two services that could be used for that purpose:
The Secrets Manager would seem to be the most fitting, but does cost money from the start.
The Parameter Store is also an option and is free for up to 10k parameters.
I'm logging into a role through SSO and I'm trying to create a new Elastic Beanstalk environment (newest tomcat if it matters) and I am getting the following error which is preventing me from even getting the environment started building:
(Namespace: 'aws:elasticbeanstalk:environment', OptionName: 'ServiceRole'): Invalid service role
This is happening even when I am trying to clone an existing environment. I've tried to auto generate a service role and to manually create one. Both are giving the error. This error does not happen when I am logging into a user with the same permissions.
When you clone an environment using the Elastic Beanstalk console, you have the option to choose a new platform and a service role. Service role is a new concept in beanstalk documented here. Service is not required if you are using basic health monitoring but it is required if you choose to use enhanced health monitoring.
When creating an environment you can choose to pass an IamInstanceProfile (typically named aws-elasticbeanstalk-ec2-role) and a service role (typically named aws-elasticbeanstalk-service-role). These two roles are required when using Enhanced Application Health Monitoring.
Please note that these two roles require a completely a different set of permissions and you should use different roles for each of them. You can find the list of permissions required for Service Role and Instance profile documented here.
When creating/cloning/modifying environments using AWS console you will be shown an option to choose a service role. If you have never used a Service role before, you will be presented with an option to "Create a new role". The console allows you to create the Service role required by beanstalk using a single button click. You can view the permissions before creating the role.
After the first create, the console will present you with a dropdown with the role you created previously (typically named aws-elasticbeanstalk-service-role) and you can reuse this service role.
From the documentation: "A service role is the IAM role that Elastic Beanstalk assumes when calling other services on your behalf. Elastic Beanstalk uses the service role that you specify when creating an Elastic Beanstalk environment when it calls Amazon Elastic Compute Cloud (Amazon EC2), Elastic Load Balancing, and Auto Scaling APIs to gather information about the health of its AWS resources."
When creating/using a role you need to make sure the IAM user has pass role permission for the role you created. In case you are not using the root account make sure you have the correct policies for the IAM user.
Note the iam:PassRole permission allows your IAM user to pass the role to beanstalk service.
Update
There was an issue with Single Sign On that has now been resolved. Please update here or in the AWS forum thread below if you are still seeing issues.
AWS forum thread: https://forums.aws.amazon.com/thread.jspa?threadID=171369
I got the same error yesterday and a different one today using the same stack "Unable to assign role. Please verify that you have permission to pass this role: XXXXXX."
And I solved assigning this policy "AWSElasticBeanstalkFullAccess" to my user
Here you could read more:
http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/concepts-roles.html#concepts-roles-user
There seems to be a thread on aws support forum here: https://forums.aws.amazon.com/thread.jspa?messageID=670359
I am having the same issue when trying to access a beanstalk environment via crossaccount iam policy.
I think that logging into console with an IAM account that belongs to that particular AWS account with resolve the issue. Im certain AWS folks are working on it