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
Related
We can leverage AWS services from within AWS infrastructure using the ACCESS_ID/ACCESS_SECRET or by assigning the IAM role.
What if I want to access the services from an instance outside of AWS. ex. DigitalOcean. I know that using the ACCESS_Key is not a good option. What is the recommended practice as an alternative to assigning the roles to EC2 instances
API calls to AWS go to public endpoints on the Internet. Therefore, they are accessible from anywhere on the Internet, not just within AWS.
Therefore, you should use the same method for connecting to AWS both inside AWS and outside AWS.
Using the Access Key and Secret Key as credentials is the correct method.
To assume an IAM Role, you must have an initial set of AWS credentials, so that AWS can confirm that you are entitled to assume the role. For example, an IAM User can provide their credentials to assume an IAM Role.
You can also assign an IAM Role to an Amazon EC2 instance. In this situation, the AWS service will automatically assume the role on behalf of the instance, and will provide the resulting credentials through the EC2 instance metadata service.
If you are using your own computer (not an Amazon EC2 instance), it is not possible to assign an IAM Role. Instead, use an Access Key + Secret Key. They should be stored in your ~/.aws/credentials file via the AWS CLI aws configure command. Never put actual credentials in your code files, since this can be a security risk (eg having credentials stored in GitHub).
AWS announced a new feature AWS IAM Anywhere that should help if you need to avoid using access/secret keys.
AWS Identity and Access Management (IAM) now enables workloads that
run outside of AWS to access AWS resources using IAM Roles Anywhere.
IAM Roles Anywhere allows your workloads such as servers, containers,
and applications to use X.509 digital certificates to obtain temporary
AWS credentials and use the same IAM roles and policies that you have
configured for your AWS workloads to access AWS resources.
and more here:
create a trust anchor where you either reference your AWS
Certificate Manager Private Certificate Authority (ACM Private CA) or
register your own certificate authorities (CAs) with IAM Roles
Anywhere. By adding one or more roles to a profile and enabling IAM
Roles Anywhere to assume these roles, your applications can now use
the client certificate issued by your CAs to make secure requests to
AWS and get temporary credentials to access the AWS environment.
AWS Announcement: https://aws.amazon.com/about-aws/whats-new/2022/07/aws-identity-access-management-iam-roles-anywhere-workloads-outside-aws/
User Guide:
https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html
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.
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
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.
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.