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.
Related
I'm currently working on IAM and Access and i'm switching from Roles to Permission Set (to use AWS SSO). I have many custom managed policies, that I can't use with Permission Sets now, so I'm using AWS managed policies such as: PowerUserAccess, ViewOnlyAccess etc.
Some of them are pretty close to what i need but have a bit too many actions. Let's take the PowerUserAccess example.
PowerUserAccess gives all GuardDuty action. I want to block all write actions.
The perfect AWS managed policy for that is: GuardDutyReadOnlyAccess.
Is there an easy way to do that "substraction"?
PowerUserAccess - "Not"GuardDutyReadOnly?
such as:
ManagedPolicies:
- arn:....:PowerUserAccess
- arn:....:PowerUserAccess - 'not' arn:....:GuarddutyReadOnlyAccess
Or do i have to do an inline policy and reverting the GuarddutyPolicy? I would like to avoid Inline policies if possible.
Thanks!
It doesn't have to be inline, but you will have to created another policy. In your case you probably want to create a customer managed policy that denies the guard duty access, and attach that to the users (or even better, to the groups).
Be aware, there is a subtle side effect of doing a deny. If a deny exist it always wins, so if you decide you want to single out a user and grant him/her access to guard duty you'd have to be sure that the deny policy is NOT attached to that user. You can't just give them another policy that includes access.
I'm currently working on a task to configure credential rotation in AWS Secret Manager, I did some reading, from my understanding, the best practice is to use the feature on Secret Manager Console 'enable the rotation', then SM will create a Lambda function and perform the rotation on a schedule that we defined (e.g. rotate every 30 days etc), but it seems like it requires IAMFullAccess role to configure this, my question is how can I check if my current AWS account has the full access or does it mean I must use root account to configure this? Many thanks.
No, you don't need root access to configure Secrets Manager key rotation. As a general rule, you should disable root access once you've set up appropriate IAM users. There are very few tasks that actually require root access.
To check your IAM policies, go to the IAM Console and list the policies attached to you (if you are an IAM user and/or in an IAM group) or to the IAM role that you assumed (if you are a federated/SSO user). If you can't access these IAM resources then you don't have full IAM access.
Note that you don't necessarily need to have the managed policy named IAMFullAccess, though that's commonly a way used to give you the relevant IAM permissions. You essentially need the permissions that that managed policy gives you (which is iam:* on all resources).
I have a AWS Lambda function in production. Triggering it can lead to monetary transactions. I want to block the feature of testing this lambda through AWS console so that users having console access cannot accidentally trigger it for the purpose of testing which they can do on the corresponding staging lambda. Is it somehow possible?
First solution that I would recommend is to not mix production and other workloads in the same AWS account. Combine that with not giving your developers and users credentials to the production account.
Assuming that you don't want to do that, you could apply a resource policy on the Lambda function that denies all regular IAM users permission to invoke the Lambda function. Be sure that your policy does not deny the 'real' source in your production system (e.g. API Gateway or SQS or S3). You should also prevent your users from modifying the resource policy on the Lambda function.
Alternatively, if all of your IAM users are managed under IAM groups, then you could apply an additional group policy that denied all actions on the Lambda function ARN. Again, ensure that they cannot modify the group policy to remove this control.
On occasion, I need to access multiple AWS resources that I have individual access for with separate IAM roles. If I need these resources to be used together, I currently have to figure out a non-native connector piece.
If I could access the resources together at the same time, I can sometimes use an AWS connector to interface with both resources at once (for example).
Is there a way to assume multiple IAM roles at the same time?
Technically, yes, there is a way to assume multiple IAM roles at the same time.
But it doesn't mean what you intend.
Assuming an IAM role doesn't modify who you are and doesn't modify what permissions you have -- contrary to the intuitive interpretation of what it might mean to assume a different identity. Instead, when you assume a role, you are given a new set of temporary credentials to use, instead of "your" credentials -- the credentials you used to assume the role.
Requests made with these temporary credentials are authorized against the permissions granted to the role.
Thus, while you can assume multiple roles at the same time, each of those actions has a separate set of associated credentials, so it won't allow you to make requests that require you to have the permissions of more than one role for any given request.
Every request is performed by a single principal, so if you are trying to perform a single action that requires the union of the permissions of multiple roles, that's a not possible.
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.