Skip to content
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

Merged
merged 16 commits into from
Apr 15, 2024

Conversation

mourya-33
Copy link
Contributor

…front permissions

Feature or Bugfix

  • Bugfix

Relates

-

Security

Please answer the questions below briefly where applicable, or write N/A. Based on
OWASP 10.

  • 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)? N/A
    • Is the input sanitized? N/A
    • What precautions are you taking before deserializing the data you consume? N/A
    • Is injection prevented by parametrizing queries? N/A
    • Have you ensured no eval or similar functions are used? N/A
  • Does this PR introduce any functionality or component that requires authorization? N/A
    • How have you ensured it respects the existing AuthN/AuthZ mechanisms? N/A
    • Are you logging failed auth attempts? N/A
  • Are you using or adding any cryptographic features? N/A
    • Do you use a standard proven implementations? yes
    • Are the used keys controlled by the customer? Where are they stored? N/A
  • Are you introducing any new policies/roles/users? N/A
    • Have you used the least-privilege principle? How? Yes, by removing the * for cloudfront permissions and explicitly specifying the distribution id arn.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@noah-paige noah-paige marked this pull request as draft April 1, 2024 15:59
@noah-paige noah-paige marked this pull request as ready for review April 1, 2024 16:02
@noah-paige noah-paige marked this pull request as draft April 1, 2024 16:26
@noah-paige
Copy link
Contributor

Leaving in draft state until additional permission restrictions added to lambda roles and dbmigration role

@mourya-33 mourya-33 changed the title Update cloudfront.py to implement least privilege principle for cloud… Implement least privilege principle for cloudfront, lambda and db migration stacks Apr 5, 2024
@dlpzx
Copy link
Contributor

dlpzx commented Apr 8, 2024

Hi @mourya-33 Can you merge main into your branch? That way we can see your changes better

@mourya-33
Copy link
Contributor Author

Sure @dlpzx

@mourya-33 mourya-33 closed this Apr 8, 2024
@mourya-33 mourya-33 force-pushed the permission-cleanup-multiple-stacks branch from 2b35f80 to 626e174 Compare April 8, 2024 15:43
@mourya-33 mourya-33 reopened this Apr 8, 2024
@mourya-33
Copy link
Contributor Author

@dlpzx @noah-paige I merged changes from main and reopened the PR

@noah-paige noah-paige marked this pull request as ready for review April 10, 2024 14:51
@dlpzx
Copy link
Contributor

dlpzx commented Apr 10, 2024

Hi @mourya-33 I am reviewing the code. Di you test the PR? If so, what tests did you do?

@mourya-33
Copy link
Contributor Author

Yes @dlpzx i am running a few more tests and will update the list of tests performed here by tomorrow.

@noah-paige
Copy link
Contributor

Hi @mourya-33 - left one minor comment and can you run ruff format and commit the changes ( I see the ruff workflow is failing)

I will do a quick test in the meantime

@mourya-33
Copy link
Contributor Author

@noah-paige @dlpzx Here are the tests and validations performed for this PR.

  1. Deploy to AWS
  2. Link/Unlink Environment
  3. Create/Delete Notebooks
  4. Create/Delete ML Studio
  5. Create/Delete Pipelines
  6. Add/Import/Delete Datasets

Verified the loggroups for graphql, esproxy and awsworker as well which are now manually created from the lambda-api stacks.

@mourya-33
Copy link
Contributor Author

Updated the files for ruff format check as well

@noah-paige
Copy link
Contributor

noah-paige commented Apr 15, 2024

Tested:

  • CICD Pipeline Completes
  • CodePipeline CB Policy Updated
  • Cross Account Cloudfront Role Updated
  • DB Migration Role Updated
  • Lambda Roles Updated
  • Lambda Functions Work and Still write to same CW Logs (GraphQL, AWSWorker, ESProxy)

Copy link
Contributor

@noah-paige noah-paige left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good!

@dlpzx dlpzx merged commit af46a25 into data-dot-all:main Apr 15, 2024
10 checks passed
dlpzx added a commit that referenced this pull request Apr 19, 2024
### 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants