I want to provide a freelancer the ability to test, debug and deploy lambda functions in the console.
However the roles i saw until now are very restrictive (only logging) or very wide like AWSLambdaFullAccess: full S3 access(?)
What is the right role here, or do i have to create a custom one?
There are two sets of permissions here.
First, there are the permissions that you are giving the freelancer. These should be sufficient to test, debug and deploy the Lambda function. You might want to limit which functions they are allowed to edit (eg based on a prefix in the function name).
Second, there is the IAM Role that is associated with the Lambda function. This will need sufficient permission to perform whatever task the Lambda function doing (eg accessing Amazon S3).
The freelancer will probably need iam:PassRole permission to be able to select an IAM Role for the Lambda functions (or I wonder if you can set that, and they simply cannot edit the role?).
Be very careful when you assign the freelancer iam:PassRole permission because if you do not limit which roles they can pass to Lambda, then they can effectively gain access to any IAM Role in your system (including those for Admins). You should limit which Roles they can pass.
I'm told sharing IAM roles with third parties is more secure than sharing IAM keys. Currently we limit IAM keys with IP filters, many conditions on access control.
Why would sharing IAM roles be better. My understanding is they can use their role to assume privilege for a time limited period from something like the boto3 api. But if they can assume the role without limit, how is there a security benefit over a key?
First, as you mentioned, the short-lived session credentials used by a role limits the time that compromised credentials can be used.
Second, with an IAM user, any time the third party needs to access resources in your account, they must posses the access key and secret key of your IAM user. If they want to access resources from your account from an EC2 instance, they need to have a way to securely push the keys to the EC2 instance. If they want to access resources from a Lambda, they need to make the keys available to the Lambda. If they want to access resources from a mobile device, they need to push the credentials to the mobile device (where they are more difficult to secure, let alone rotate).
Managing these credentials is not only additional work for the third party, but also additional risk for you. The long-lived credentials for your IAM user are now being passed around by a third party.
Using an IAM role instead, you can allow the third party to access resources without passing your credentials around. An EC2 instance can avoid handling your credentials using EC2 instance roles. Lambda, similarly, can avoid handling your credentials by using execution roles. On a mobile device, there is Cognito.
To grant an external party access to the AWS resources owned by you, you have following options:
[WORST APPROACH] You create an IAM user (say, Foo) and grant it the required permissions and then share the same with the external parties. This is obviously the worst approach as now you have no segregation between who is making calls to your resources because in effect, it is always Foo who is calling you.
You let your clients create IAM users in their own accounts and then whitelist them in your resource's policy. This works, given that your resource supports resource-level policies (S3 and API Gatewaydo). Now, even if they do support resource-level policies, now it is an overhead for you to whitelist all such users created by all your clients, which can access the resource.
You create an IAM role, grant it capabilities (in terms of IAM policies) to access your resource and then whitelist your clients' IAM users to assume that role. This will be your way of saying that "this role is capable of accessing my resource and if you can assume this role, so do you". Moreover, this also prevents you from sharing the credentials as AWS STS does all that work in generating the temporary credentials for you.
My intention is simple- to create a role that I can assign to a standard user of my AWS account so that they can read/write to one of my S3 buckets.
I've created a policy to apply to the role and I'm happy with that bit.
The thing I'm a bit confused about is the "Select Role type" screen in the management console (see attached image). I can't work out what I'm supposed to choose at this stage as none of the descriptions seem to apply to the simple thing I'm trying to achieve.
Does anyone have any idea?
I think you are on the wrong path here. Roles are not ACLs for users, but for systems and services.
See: IAM Roles
If you want to grant a user access to some AWS resources you should have a look at the policy section. Either use a pre-build (like AmazonS3ReadOnlyAccess or AmazonS3FullAccess) or define a policy on your own.
You can then assign this policy to a user. If you want to manage multiple users this way, you can also use groups to assign policies to users.
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.
As part of the process for onboarding new customers, I need to create an S3 bucket, create a new user, and grant that user permissions to get, list, and put to that bucket. I'd like to automate this process, which means that I need to create a "Provisioning" policy that grants a service only the permissions needed to do these things.
It seems pretty straightforward to use String Conditions in my Provisioning Policy to require the names of Users and Buckets start with a certain prefix. However, the PutUserPolicy seems to just take a text blob as its argument. I'd prefer to limit my Provisioning Policy to only be able to create Policies that grant the specific permissions that I need here; ideally only being able to grant users who names match a pattern the ability to get, list, and put to buckets who names match a pattern. (If this Policy is somehow hijacked, I'd prefer to limit their ability to create a user and grant it all privileges.)
Is there any way to get this level of fine-grained control?
No. IAM doesn't go into this much detail. You can't say "Only allow a user to create a policy with these permissions".
You would need to design your system in such a way that this policy can't be hijacked. Create a template policy and just make sure a new user can't inject anything into the inputs.
Also, on a separate note, it would be considered much better practice to use one bucket and give each user a folder inside that bucket. You can still control permissions to a key in a bucket. See the blog for more on this.