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.
Related
I am having some trouble doing code deploy with my AWS Educate account. Initially, when I was setting things up I was following this article.
https://hackernoon.com/deploy-to-ec2-with-aws-codedeploy-from-bitbucket-pipelines-4f403e96d50c?fbclid=IwAR3rezVMGpuQxTJ3AneOeTL2oMHjCKbQB5C5ouTLhJQ5gRp3JeL4GK0f53o
In it is talks about setting up an IAM service account. The problem is that AWS Educate allows you to create the accounts but it won't generate keys. In order for me to deploy my Spring Boot (and VueJS) apps to my s3 buckets and ec2s from my bitbucket repo, I need a key and secret key and CodeDeploy Group.
Fine I was able to use my Click the Account Details button on the labs.vocareum page and get my keys, however when I am attempting to set up a Code Deploy Group it asks for a service role and I am unsure where to get this?
Why is the service role necessary?
The service role is used by the CodeDeploy service in order to perform actions outside CodeDeploy (i.e. on another service such as S3).
AWS has a special approach of integrating services. Basically, you have to give each service you are using explicit permission to use another service (even if the access stays in the bounds of the same account). There is no inherent permission given to the CodeDeploy service to change things in S3. In fact, CodeDeploy is not even allowed to read files from S3 without explicitly allowing it.
Here is the official explanation from the docs [1]:
In AWS, service roles are used to grant permissions to an AWS service so it can access AWS resources. The policies that you attach to the service role determine which AWS resources the service can access and what it can do with those resources.
What you are actually doing according to the hackernoon article
you need a user account with programmatic access to your aws account
the user account needs to have a policy attached which grants permission to upload files into S3 and trigger a CodeDeploy deployment --> you provide the access key and secret access key of this user to Bitbucket so it can upload the stuff into S3 and trigger a deployment on bahalf of your user identity
Unrelated to steps 1 and 2: Create a role in AWS IAM [2] which will be used by both services (NOT Bitbucket): CodeDeploy and EC2. Strictly speaking, the author of the hackernoon article is merging two steps into one here: You are creating one role which is used by both services (as specified by the two different principals in the trust relationship: ec2.amazonaws.com and codedeploy.us-west-2.amazonaws.com). Usually this is not how IAM policies should be configured because it violates the principle of granting least privilege [4] as the EC2 instances receives permissions from the AWSCodeDeployRole policy which it probably does not need as far as I see. But that is just a philosophical note here. All the steps mentioned in the hackernoon article should technically work.
So, what you actually do is:
granting CodeDeploy permission to perform various actions inside your account, such as viewing which EC2 instances you have started etc. (this is specified inside the policy AWSCodeDeployRole [3])
granting EC2 permission to read the revision which was uploaded to S3 (this is specified inside the policy AmazonS3FullAccess)
To get back to your question...
However when I am attempting to set up a Code Deploy Group it asks for a service role and I am unsure where to get this?
You need to create the service role by yourself inside the IAM service (see [2]). I do not know if this is supported by AWS Educate, but I guess it should be. After creating the service role, you MUST assign it to the CodeDeploy Group (that is the point where you are stuck right now). Moreover, you must assign that same service role to you EC2 instance profile.
References
[1] https://docs.aws.amazon.com/codedeploy/latest/userguide/getting-started-create-service-role.html
[2] https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html#roles-creatingrole-service-console
[3] https://github.com/SummitRoute/aws_managed_policies/blob/master/policies/AWSCodeDeployRole
[4] https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege
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
I am new to AWS. My task is create a KMS management role that would be used for creating Custom Management Keys.
I am on the step of “Create Role”. I need to choose the service that will use this role.
There are about 40 options, such as EC2, EC2 Container Service, EMR, S3. What is the most logical service?
When you create a Role in AWS IAM, that Role must then be used with something else. E.g. you may have an EC2 instance (a server) that has a Role assigned to it. Anything running inside that EC2 instance will then have the permissions assigned to that role. Same is true about AWS Lambda Functions and other services.
In this case, you are creating a Role, so later you would create an application/service/function that performs CMK creation tasks for you. Your role will be assigned to your application. Therefore, you only have to decide where your application is supposed to run?
If it is going to run inside EC2, you should choose the Principal in your policy as EC2 service. If it is Lambda, choose Lambda, and so forth...
Notice, you can specify AWS accounts (root), IAM users, IAM roles, and some AWS services as principals in a key policy. IAM groups are not valid principals.
See here for more info:
http://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html
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'm just getting in touch with EC2 and came across the IAM Role concept. This question is to clear my doubt about the concept on restriction level.
Lets say I have an EC2 instance with attached IAM Role Role A which posses one policy AmazonS3ReadOnlyAccess, correct me if i'm wrong but it means this particular instance only allow to perform S3 Read only operation.
Now says I created a User with Programmatic access and AmazonS3FullAccess policy.
If this user SSH into the EC2 instance, can he write file to s3 ?
I still unable to try it out by myself as I don't have a linux machine and still figuring on how to connect to Ec2 using putty
Lets say I have an EC2 instance with attached IAM Role Role A which
posses one policy AmazonS3ReadOnlyAccess, correct me if i'm wrong but
it means this particular instance only allow to perform S3 Read only
operation.
Yes
Now says I created a User with Programmatic access and
AmazonS3FullAccess policy. If this user SSH into the EC2 instance, can
he write file to s3 ?
IAM users cannot SSH to EC2 instances using IAM user credentials. After provisioning a EC2 instance, you need to use regular Operating System User constructs, to SSH to the Server (Default user keys created by AWS).
In addition if a user SSH to EC2 instance and use a Programatic Access Credentials of a EC2 User through AWS CLI, REST API or SDKs (Doesn't have to be a EC2 instance, it also can be your on-premise server) then if the IAM User has a S3 write policy, the CLI commands or API calls or the code using SDK is able to write files to S3.
So in a summary
Use IAM roles if you are running a EC2 instance, for your CLI commands, Code with SDK, or REST API calls to access AWS Resources.
If you are using a server on-premise or outside AWS, use IAM User's Programatic Access keys to do the same.
Insight on how IAM roles work internally with EC2
When you attach a IAM role to a EC2 instance, AWS periodically updates the EC2 instance with temporal Access Credentials to that EC2 instance (Which is a good security practice).
These credentials are accessible through the Metadata URLs for the CLI, REST API and Code using SDKs inside EC2 instance.
Note: When using Roles, its much secure since it uses Temporal access credentials vs IAM Users Programatic Access uses Long lived access credentials.