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.
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
My EC2 instance has a role attached with S3 permissions. Right now I use my access key and secret access key to load to s3 but I want to rely on the role and get rid of the credentials. Can I do that? Or do I need to have credentials for the Go AWS SDK?
Right now we are using the NewStaticCredentials function to setup our configuration. End goal is to upload files to S3.
This is what i could get from the docs
If you are running your application on an Amazon EC2 instance, use the instance’s IAM role to get temporary security credentials to make calls to AWS.
If you have configured your instance to use IAM roles, the SDK uses these credentials for your application automatically. You don’t need to manually specify these credentials.
Note:- Even AWS also recommends this.
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.
I need to create Java REST API(not with SDK) to launch a AWS EC2 instance.
First of all I need to Authenticate with the AWS API server by using Signature and Accesskey. I tried using the AWS documentations but I am facing the below error.
<Code>AuthFailure</Code><Message>AWS was not able to validate the provided access credentials</Message>
Could someone suggest me the steps to implement authentication with API and launching the instance in AWS. Also share if any existing GitHub code for the above requirement.
You have to use,
http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/ec2/AmazonEC2Client.html
There are ways you can gain access.
Create Access Key and Secret with IAM and pass them to java client.
Or you can create a role for an EC2 instance and assign the role to your Ec2 instance. Any code run from that EC2 instance will have access to the role mentioned.
Either with IAM Access Key or EC2 Instance Role, you need to have EC2 Policy with EC2FullAccess to access the API.