-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement least privilege principle for cloudfront, lambda and db migration stacks #1134
Implement least privilege principle for cloudfront, lambda and db migration stacks #1134
Conversation
Leaving in draft state until additional permission restrictions added to lambda roles and dbmigration role |
Hi @mourya-33 Can you merge |
Sure @dlpzx |
2b35f80
to
626e174
Compare
Disabled CDK to auto add network interface permissions and log group permissions
@dlpzx @noah-paige I merged changes from main and reopened the PR |
Hi @mourya-33 I am reviewing the code. Di you test the PR? If so, what tests did you do? |
Yes @dlpzx i am running a few more tests and will update the list of tests performed here by tomorrow. |
Hi @mourya-33 - left one minor comment and can you run I will do a quick test in the meantime |
@noah-paige @dlpzx Here are the tests and validations performed for this PR.
Verified the loggroups for graphql, esproxy and awsworker as well which are now manually created from the lambda-api stacks. |
Updated the files for ruff format check as well |
Tested:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good!
### Feature or Bugfix - Bugfix ### Detail In #1134 log groups are created explicitly for each Lambda in the backend, which results in errors when the log-groups do not exist. (see #1190 ) This PR removes the `log_group` parameter from the definition of the Lambdas. It reverts back to the previous (2.3) settings. Tested: on a fresh deployment, making sure that no log-groups were previously created, the stack creates the log-groups with the Lambda name. For example `/aws/lambda/<resource_prefix>-<env_name>-esproxy`. Update: we need to explicitly define the log groups to avoid the log retention lambdas and their roles and policies that CDK automatically creates. So to cope with existing groups and non-existing groups this PR adds a CfnCondition to the creation of the log-group ### Relates - #1134 ### Security Please answer the questions below briefly where applicable, or write `N/A`. Based on [OWASP 10](https://owasp.org/Top10/en/). `n/a` - Does this PR introduce or modify any input fields or queries - this includes fetching data from storage outside the application (e.g. a database, an S3 bucket)? - Is the input sanitized? - What precautions are you taking before deserializing the data you consume? - Is injection prevented by parametrizing queries? - Have you ensured no `eval` or similar functions are used? - Does this PR introduce any functionality or component that requires authorization? - How have you ensured it respects the existing AuthN/AuthZ mechanisms? - Are you logging failed auth attempts? - Are you using or adding any cryptographic features? - Do you use a standard proven implementations? - Are the used keys controlled by the customer? Where are they stored? - Are you introducing any new policies/roles/users? - Have you used the least-privilege principle? How? By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
…front permissions
Feature or Bugfix
Relates
-
Security
Please answer the questions below briefly where applicable, or write
N/A
. Based onOWASP 10.
fetching data from storage outside the application (e.g. a database, an S3 bucket)? N/A
eval
or similar functions are used? N/ABy submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.