Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Allow Custom Per-Function Roles #2073
What did you implement:
How did you implement it:
Allow each function to declare the ARN of the role that it is to execute under.
How can we verify it:
Added tests that check that the default role and policy are not added if every function has a role.
Resolves matter 1 of #1895 Allow each function to declare the ARN of the role that it is to execute within. If any function has no role ARN but provider role ARN is defined then use that role for such functions. If any function does not have a specified role (even by falling back to a provider-wide role) then add the default policy and role so that it can be used for such functions. Break out the portions of the logic into their discrete units so that the plugin code is a readable summary. Add comments to the discrete units. Add tests that check that the default role and policy are not added if every function has a role. Add tests that check that every function that has a declared role gets it assigned. Add tests that check that every function that has no declared role but where a provider role is declared gets the provider role assigned.
Hi @andymac4182, this change does not impact the current behavior of SLS. That said, the code in this change is not doing any checking for or verification of any rights on the role; it only cares to allow a role to be specified at an individual function level (with fall back to any provider declared role). That, of course, means it is not checking for VPC rights assignments on any of the assigned roles.
I can see how verifying VPC rights would be useful if VPC configuration exists on any of the functions but that seems beyond the scope of this change. I've seen PR #1934 but that regards the default role that SLS creates (of course, I'll happily merge that code into this PR if it gets accepted prior to this one). The code related to this PR is about not using the default role/policy (and not having them created at all) for cases where you want to do something more fine-grained, nuanced, or where your account configuration will not accept the default approach (because of assigned developer rights). More correctly, this PR allows you to do this on an individual function level (contrary to the default and current bypass rights assignment approach).
Given that this change increases available flexibility in order to support a bit more of a "do-the-heavy-lifting-yourself" and "advanced/responsibility and knowledge needed" use case, I think we can depend on users to properly configure their roles; at least to start out. If a "verify VPC rights" capability were to be implemented in the future, I would hope that it would produce a warning by default that could potentially be escalated to an error if a command line flag (or some other configuration) was used. For use cases like these, it seems important to not make any assumptions about how users would like to implement their custom rights management: are they using an inline policy, a custom policy, or a managed policy? Seems to me that there's a bit of complexity in how to implement such a sufficient rights verification feature properly.
Switch from an all lambdas logging resource IAM policy to one that targets specifically and only those CloudWatch logs produces by the lambdas declared by the service. Modify tests to ensure this is properly done. Introduce a `role` property that specifies a role defined within the service. Update tests to ensure this is properly used Update documentation to describe this Replace `iamRoleARN` with `roleArn` Update tests and documentation to reflect this Add Decision Trees describing the decision points and considerations between individual function rights and shared rights models
Thanks again @erikerikson for this very extensive PR. I've looked over it and it looks good, but I want to do a larger deep dive on it as well tomorrow.
I love the roleARN and the ability to expand
First of all: Thank you very much @erikerikson for this PR!
Tried it out today in a bunch of different combination and it works really great!
The only thing I was not able to get running was to set the
service: new-test-service provider: name: aws runtime: nodejs4.3 role: test123 functions: hello: handler: handler.hello resources: Resources: test123: Type: AWS::IAM::Role Properties: RoleName: test123 Path: "/" AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Principal: Service: - lambda.amazonaws.com Action: sts:AssumeRole Policies: - PolicyName: myPolicyName PolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Action: - logs:CreateLogGroup - logs:CreateLogStream - logs:PutLogEvents Resource: arn:aws:logs:us-east-1:XXXXXXXX:log-group:/aws/lambda/*:*:*
But all in all a really great PR with an awesome documentation!
@eahefnawy could you also do a deep dive into this and test out different combinations? Thanks!
1. fix docs that would lead to an error for users via copy-paste 2. add tests about adding roleArn to functions given role declared on provider and/or function 3. fix bug discovered due to lack of tests 4. add test to ensure preference for function declared roleArn over provider declared roleArn
Thank you very much @erikerikson
No worries you totally rock here
I've just added some minor change requests (seems like the
Furthermore I've retried to deploy the following service:
service: new-test-service provider: name: aws runtime: nodejs4.3 role: test123 functions: hello: handler: handler.hello resources: Resources: test123: Type: AWS::IAM::Role Properties: RoleName: test123 Path: "/" AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: Service: - lambda.amazonaws.com Action: sts:AssumeRole Policies: - PolicyName: myPolicyName PolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Action: - logs:CreateLogGroup - logs:CreateLogStream - logs:PutLogEvents Resource: arn:aws:logs:us-east-1:XXXXXXXX:log-group:/aws/lambda/*:*:*
But I get this error when I want to deploy it:
Thanks in advance! And thanks again for your time you've put into this!
EDIT: Tried to add comments to all the
I also looked up @pmuens comments about the
These docs follow:
I have added the 'CAPABILITY_NAMED_IAM' flag to the create call. As you are surely all painfully aware (very sorry) I am not in a position to exercise this. I really have been trying to get myself in such a position but things have been coming up. I will continue to endeavour to get set up and stop leaning on you guys.
To give some context on my comments:
Just tested it once again with the
Works as expected. Big
However if I want to deploy it it fails with the error message
Could you maybe rebase the PR once again as this bug can be related to the wrong resource merging (in the create stack step) which was resolved recently. After that I'll do another code review so that it can be merged ASAP.
Again. Thanks for your time and effort @erikerikson