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'm totally new to AWS and learning about IAM. I was wondering if there is a way around for an IAM user to check what all permission he/she have? Like as a root user, I created a group of IAM users where they were only allowed to use S3 service but once I logged in as an IAM user, it was showing that I have access to other AWS services as well like running EC2 instances, etc which I reckon shouldn't be the case. Thanks!
No, it isn't possible to "show" which services you have access to use, because the policies can be quite complex (eg permission to access an S3 bucket, but only a particular sub-folder if coming from a given range of IP addresses).
You would need to look the the IAM Policies attached to the IAM User, plus the policies on any IAM Groups they are in. Then, some services like Amazon S3 have additional permissions such as Bucket Policies.
In addition, AWS Organizations can limit the permissions of all users within an AWS Account, so even if a user appears to be granted certain permissions, they might not actually be available for use.
In many situations, you'll only know if you can do something by actually trying it. For example, you might have Read Only permissions, which means you can see resources in the AWS Console, but you would receive an error when you try to change things.
All services are available in the AWS Console, but various parts of the console will only work if you have adequate permission.
Note that there's IAM Policy Simulator from AWS. You can select a service and check if a given user has access to any given action (or all actions relevant to a service)
We have large number of IAM users ( in hundreds, can increase more then 1000 in future ).
All the IAM users have access to create EC2 instances. Simultaneously around 30-40 users will be working and creating EC2 instances.
In AWS Management Console, an IAM user can see all the instances created by other IAM users as well.Is it possible to visibly make him see only those EC2 instances which he created and hide all the other instances created by other IAM users?
I do agree that IAM users can give names and tags to recognise their instances. However i am looking for visibly hiding those resources which he has not created.
If IAM policies allowed specifying a required filter, this would be possible. But you can't specify it, so it's not possible.
What you want is called Organizations - You can give each group their own AWS account, so they can see their own billing, etc.
Reserved Instances can flow from the master account to sub account
Bills flow from the sub accounts to the master account
All your users can remain in the master account, you just give them AssumeRole capabilities to view their account.
You can apply Service Control Policies that prevent sub-accounts from doing things.
You may think management is "easier" with one account - but the opposite is true. Just like you should treat servers as "Cattle not Pets" (i.e. they are disposable), you should think of AWS accounts as disposable. Some organizations give each developer their own AWS account, and only a build server can modify the Staging/Prod accounts via TerraForm or CloudFormation.
What you would typically use for this is resource level permissions. What resources / what you can control varies from API call to API call in AWS. In particular, what you would want is a resource-level permission on the DescribeInstances API call. Unfortunately, AWS does not currently support resource-level permissions on this API Call.
The AWS official site reads role as a collection of permissions and group as a collection of users. But still they look the same to me. You attach policies to groups or roles, and then assign groups or roles to a user. What exactly are the differences between role and group?
Short answer for googlers: you can't assign role to user.
group is a bunch of users with the same policies
role is a preset of policies for service(s)
Users can asume roles according to AWS docs:
Assuming a Role
AWS Groups are the standard groups which you can consider as collection of several users and a user can belong to multiple groups.
AWS IAM Roles are all together different species; they operate like individual users except that they work mostly towards the impersonation style and perform communication with AWS API calls without specifying the credentials.
Given that IAM Roles are little different, I am emphasizing only that. There are several types of IAM Roles like EC2 IAM Roles, Lambda etc. If you consider, you can launch an EC2 instance with an EC2 IAM Role; hence forth any AWS API related communication wouldn't require any AWS Access Key or Secret key for authentication rather can call the APIs directly (however the long answer is - it uses STS and continuously recycles the credentials behind the scenes); the privileges or permissions of what it can do is determined by the IAM Policies attached to the IAM Role.
Lambda IAM Role works exactly the same, except that only Lambda function can use the Lambda IAM Role etc.
Users: End User (Think People).
Groups: A collection of users under one set of permissions (permission as policy). As per IAM standards we create groups with permissions and then assign user to that group.
Role: you create roles and assign them to AWS resource (AWS resource example can be a customer, supplier, contractor, employee, an EC2 instance, some external application outside AWS) but remember you can't assign role to user.
It’s not only users who will login, sometimes applications need access to AWS resources. For example, an EC2 instance might need to access one or more S3 buckets. Then, an IAM role needs to be created and attached to the EC2 instance. That role can be re-used by different EC2 instances.
Remember : Groups are for living. Roles are for non-living.
I think of an AWS Role as a kind of 'sudo', where each AWS Role can temporarily provide a very specific set of elevated privileges, but without needing the elevated credentials. I get the impression that like sudo, AWS Roles try to prevent privileged actions being used accidentally.
I'd be interested to hear if others agree with this analogy.
Please note that Groups are specific to local IAM users, which are not federated, and local IAM user logs do not show who has done the actions (i.e.., multiple people or applications could use the same long-term secret/access keys, and there is no record of which entity used them). If you must use local IAM users, you can place them into IAM Groups. Where this can be especially useful is to serve as a boundary -- you could place a deny policy on the group, restricting access to specific services or actions, and that deny policy will be applied to all users in the Group.
Conversely, roles can be federated, whereas local IAM users are not. You might create an on-premises AD group that serves as a member container, for example, and then the members of that AD group (and only they) can use the role that the AD group correlates to, with whatever allow or deny policies and/or permissions boundaries you've applied to the role. (Here is a link explaining the AWS ADFS federation.)
Importantly, roles allow for temporary session credentials (which is a best security practice), as their session tokens expire after a maximum of 12 hours. Equally importantly, roles do show in the logs which of the AD members with access to use the role actually did the action. You'll find this tacked to the end of the role ARN in the logs (e.g., a user ID). CloudTrail would be one of several services that indicate user activity. This is important from a logging standpoint.
Understanding IAM roles vs IAM groups (IAM indentities) is very important foundational concept . Its important to look at difference between IAM role and IAM user as essentially group is just a bunch of users performing similar functions (eg. group of developers, QA's etc.) Roles are not uniquely associated with one person (user), they can be assumed by user,resource or service who needs it to perform task at that point of time (session). Roles do not provide long-term credentials like password or access keys.
Best practice recommendation is to require workloads to use temporary credentials with IAM roles to access AWS
Please refer to link below for more clarity:
https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html
I was confused all the time about the difference between these two functions.
In short,
Role is like a tag with all the preset policies that can attach on IAM users/groups or AWS services. IAM users share the same account with the account root user (Admin) but with assigned permissions by the root user to use AWS resources within that account.
Therefore, IAM users can directly interact with AWS services; whereas IAM roles cannot make direct requests to AWS services, they are meant to be assumed by authorised entities like an IAM user or an instance. https://aws.amazon.com/iam/faqs/
I had a hard time deciphering the spirit of the given answers..
Here's what I've found:
Groups:
Intended to represent human users created within IAM who need identical policies.
Ex. Dev 1 - Dev 8 are all developers, and all need access to create dev servers.
This is similar to traditional desktop users/groups, but for HUMAN users only.
Roles:
Roles rotate automatic credentials, meaning password input isn't needed for accessing policies.
This makes it good for two things:
Giving permissions to non-humans, such as services / applications.
Ex. EC2 of type A needs access to S3 of type B.
Giving permissions to federated / outside users & groups.
Ex. Contractor A # Outside Company A needs access to your Server A.
Authentication of users & groups are handled by some service, like Azure AD.
Authorizations are then mapped to your IAM role(s), NOT users or groups.
Note: I've used Jumpcloud's Article & AWS's Documentation to gather this information. The terms "Group", "Role", and "User" become overloaded in context to SSO+IdP, and IAM.
Here's an image showing how they map roles. !Need 10 Reputation :(
Aside: There is a way of assigning Roles to normal IAM Users & Groups, but it appears to be bad practice.
Hopefully this provides clarity to the answers above.
Only one IAM Role can be assumed at a time! And there are several
situations which fits exactly this kind of permission.
Read the faq about: How many IAM roles can I assume?
The underlaying tool in use is "Permission" in both of the use cases namely: Group and IAM Role.
Group or IAM Role --> Has Policy --> Policy defines permisions --> Permissions are assigned to a Group or IAM Role.
I am in the early stages of writing an AWS app for our users that will run our research algorithms using their AWS resources. For example, our code will need to spin up EC2 instances running our 'worker' app, access RDS databases, and create access SQS queues. The AWS Java SDK examples (we are writing this in Java) use a AwsCredentials.properties file to store the Access Key ID and Secret Access Key, which is fine for examples, but obviously not acceptable for our users, who are would be in essence giving us access to all their resources. What is a clean way to go about running our system on their behalf? I discovered AWS Identity and Access Management (IAM) which seems to be for this purpose (I haven't got my head around it yet), esp. Cross-account access between AWS accounts. This post makes it sound straightforward:
Use the amazon IAM service to create a set of keys that only has
permission to perform the tasks that you require for your script.
http://aws.amazon.com/iam/
However, other posts (e.g., Within IAM, can I restrict a group of users to access/launch/terminate only certain EC2 AMIs or instances?) suggest there are limitations to using IAM with EC2 in particular.
Any advice would be really helpful!
The key limitation with regards to RDS and EC2 is that while you can restrict access to certain API actions there are no resource level constraints. For example with an IAM S3 policy you can restrict a user to only being able to perform certain actions on certain buckets. You can write a policy for EC2 that says that user is allowed to stop instances, but not one that says you can only stop certain instances.
Another option is for them to provide you with temporary credentials via the Security Token Service. Another variant on that is to use the new IAM roles service. With this an instance has a set of policies associated with it. You don't need to provide an AwsCredentials.proprties file because the SDK can fetch credentials from the metadata service.
Finally one last option might be consolidated billing. If the reason you are using their AWS resources is just because of the billing, then setup a new account which is billed from their account. The accounts are isolated from each other so you can't for example delete their instances by accident. Equally you can't access their RDS snapshots and things like that (access to an RDS instance via mysql (as opposed to the AWS api) would depend on the instance's security group). You can of course combine this with the previous options - they could provide you with credentials that only allow you to perform certain actions within that isolated account.