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

feat: fine-grained nacls for backend vpc creation #543

Merged
merged 56 commits into from
Jul 11, 2023

Conversation

noah-paige
Copy link
Contributor

Feature or Bugfix

  • Feature

Detail

  • Replace NACL Rules on VPC Subnet with individual security groups defined for the backend VPC as restrictive as possible, allowing only the needed traffic.

Relates

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

noah-paige and others added 30 commits June 6, 2023 15:42
### Feature or Bugfix
- Bugfix

### Detail
- fix how dynamic SQL with varying table names is generated

### Relates
- <URL or Ticket>

By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache 2.0 license.
…ride react-redux to non-vulnerable version (#521)

### Feature or Bugfix
- Bugfix

### Detail
- Upgraded `fast-xml-parser`
- In the process I also found that other dependency libraries included
vulnerabilities. In particular `react-redux` and `nth-check`, the parent
packages `aws-amplify`, `react-scripts` and `appbaseio/reactivesearch`
have been updated. For this last one, the latest version still uses a
vulnerable version of `react-redux` so I added a ovverride clause in the
package.json

### Relates
- Related to
https://github.com/NaturalIntelligence/fast-xml-parser/releases/tag/v4.2.4

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

### Detail
- Resolve nth-check in sub-dependencies to version 2.0.1

### Relates

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 ready for review June 30, 2023 19:29
@noah-paige noah-paige self-assigned this Jun 30, 2023
@noah-paige noah-paige linked an issue Jun 30, 2023 that may be closed by this pull request
@@ -12,7 +12,7 @@
from ....db import permissions, models
from ....db.api import ResourcePolicy, Glossary
from ....searchproxy import indexers
from ....utils import json_utils
from ....utils import json_utils, sql_utils
Copy link
Contributor

@dlpzx dlpzx Jul 3, 2023

Choose a reason for hiding this comment

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

I see that this feature branch includes changes from main to v1.6

def create_ecs_security_groups(self, envname, resource_prefix, vpc, vpce_connection, s3_prefix_list, lambdas):
scheduled_tasks_sg = ec2.SecurityGroup(
self,
f'ScheduledTasksSG{envname}',
Copy link
Contributor

@dlpzx dlpzx Jul 3, 2023

Choose a reason for hiding this comment

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

It is for scheduled tasks and for cdkproxy tasks right? But I see why you left the name for simplicity

Copy link
Contributor Author

@noah-paige noah-paige Jul 5, 2023

Choose a reason for hiding this comment

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

Yes - originally I had cdkproxy with it's own SG but ultimately I found a way to make cdkproxy ECS tasks work with no traffic over the internet so I removed the additional cdkproxy_security_group and now use scheduled_tasks_sg for all scheduled tasks and cdkproxy while only shares are handled separately with their own SG

I am open to changing the name to something more appropriate but for simplicity I kept it as scheduled_tasks_sg for now

Copy link
Contributor

@dlpzx dlpzx left a comment

Choose a reason for hiding this comment

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

Thank you for this PR! I added my comments and will do some additional testing :)

@@ -1,6 +1,6 @@
import { createContext, useEffect, useReducer } from 'react';
import PropTypes from 'prop-types';
import Amplify, { Auth } from 'aws-amplify';
import { Amplify, Auth } from 'aws-amplify';
Copy link
Contributor

Choose a reason for hiding this comment

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

from main changes

'pip install -r deploy/requirements.txt',
'cdk synth',
'echo ${CODEBUILD_SOURCE_VERSION}'
],
role_policy_statements=self.codebuild_policy,
role=self.pipeline_iam_role,
Copy link
Contributor

Choose a reason for hiding this comment

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

if we are replacing the codebuild policy by a role, shouldn't we define the codebuild_role here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This goes back to the previous code where we had the following configuration:

Baseline CodeBuild Policies were assigned to the following CodeBuild Steps:

  • Synth
  • ALL Quality Gate CodeBuild Steps
  • Lambda Image
  • ECS Image

Baseline CodeBuild Policies + select sts/cloudfront permissions were assigned to:

  • DB Migration
  • Stack Updater
  • Deploy FrontEnd
  • Update Documentation
  • Configure RUM
  • Configure Cognito
  • ALBFrontEndImage
  • UserGuideImage

Baseline CodeBuild Policies + sts/cloudfront + select codecommit permissions were assigned to:

  • GitRelease

I created 3 roles to align with the above 3 sets of permissions, pipeline_iam_role, codebuild_role, and git_project_role keeping the permissions the same and refactoring to focus on improving management of these permission sets.

I will rename the roles to be baseline_codebuild_role, expanded_codebuild_role, and git_project_role to avoid confusion with naming.

I think an optimization here would be to define individual permission sets for each CodeBuild Role (or each logical grouping of CodeBuild Steps) but would opt to leave that as a separate PR unless others think differently?

Copy link
Contributor

Choose a reason for hiding this comment

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

My bad for not looking into each role policies! I see now. And yes and additional improvement would be to define each role/set of roles separatedly. But I agree, this can be part of a different PR

deploy/stacks/pipeline.py Outdated Show resolved Hide resolved
deploy/stacks/pipeline.py Outdated Show resolved Hide resolved
deploy/stacks/pipeline.py Outdated Show resolved Hide resolved
deploy/stacks/pipeline.py Outdated Show resolved Hide resolved
deploy/stacks/pipeline.py Outdated Show resolved Hide resolved
deploy/stacks/vpc.py Outdated Show resolved Hide resolved
deploy/stacks/vpc.py Outdated Show resolved Hide resolved
deploy/stacks/backend_stack.py Show resolved Hide resolved
@dlpzx
Copy link
Contributor

dlpzx commented Jul 3, 2023

Yes, I was thinking of having some alternative to VPC endpoints. The ones introduced in this PR are also needed only for particular features which means that can be avoided if a module is disabled in modularization. So I would wait for this change and implement it directly in the modularization architecture

@dlpzx
Copy link
Contributor

dlpzx commented Jul 3, 2023

Hi @noah-paige! I have tested the backwards compatibility of this feature and I run into the following issue when merging this feature branch in a pre-existing deployment.
The deployment fails in the CDK Synth stage throwing the exceptionbotocore.exceptions.ClientError: An error occurred (UnauthorizedOperation) when calling the DescribePrefixLists operation: You are not authorized to perform this operation.
The issue is that the role used in Codebuild does not have this permission before being updated in the SelfMutate stage.
image

What I did is adding the permission manually to the role that is created for CodeBuild based on the IAM policy(a role which will be deleted in CDK Synth and replaced by a role instead of a policy). After this it succeeds and does not throw any other error.
image

We have 2 options:

  1. update the IAM policy of the CodeBuild stage and add the ec2:DescribePrefixLists in a PR include it in v1.5.6 minor release > Force customers to upgrade to v1.5.6 before upgrading to v1.6.0
  2. include instructions in the v1.6.0 release notes where customers add that permission manually to CodeBuild

@@ -55,7 +55,12 @@ def update_stack_output(session, stack):

def deploy_cdk_stack(engine: Engine, stackid: str, app_path: str = None, path: str = None):
logger.warning(f'Starting new stack from stackid {stackid}')
sts = boto3.client('sts')
region = os.getenv('AWS_REGION', 'eu-west-1')
Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder if we can create a factory for this client to avoid copy-paste e.g.

    @staticmethod
    def client(additional_params: dict = None):
        if additional_params is None:
            additional_params = {}
        region = os.getenv('AWS_REGION', 'eu-west-1')
        return boto3.client(
            'sts',
            region_name=region,
            endpoint_url=f"https://sts.{region}.amazonaws.com",
            **additional_params
        )

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added a new Issue for the above #561

@@ -56,7 +56,12 @@ def up(response: Response):
def check_creds(response: Response):
logger.info('GET /awscreds')
try:
sts = boto3.client('sts', region_name=os.getenv('AWS_REGION', 'eu-west-1'))
region = os.getenv('AWS_REGION', 'eu-west-1')
Copy link
Contributor

Choose a reason for hiding this comment

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

To consider: Looks like we reach the same behavior if we specify AWS_STS_REGIONAL_ENDPOINTS=regional. boto3 sts client will make a call to a regional sts endpoint. This way we don't have to worry about forgetting to put region to sts client

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Relates to #561

Copy link
Contributor

@dlpzx dlpzx 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, thanks @noah-paige

@dlpzx dlpzx merged commit 1465c62 into v1m6m0 Jul 11, 2023
@dlpzx dlpzx mentioned this pull request Jul 11, 2023
dlpzx added a commit that referenced this pull request Jul 19, 2023
### Feature or Bugfix
Release PR with the following list of features. Refer to each PR for the
details

### Detail
- #498 
- #482 
- #543
- #524 (which also solves #531)
- #532 
- #535 
- #497 
- #515
- #529 
- #562 
- #455 
- #572 
- #567 
- #573 
- #579 
- #578 
- #582 

### Breaking changes - release notes
- ⚠️ IMPORTANT: upgrade to a version >V1.5.0 before upgrading to V1.6 to
avoid deletion of resources in custom resource deletion
- ⚠️ IMPORTANT: requires an update of environments and then datasets
after upgrading. Either using cdk.json parameter
`enable_update_dataall_stacks_in_cicd_pipeline`, waiting for overnight
update stack task, or manually updating first environments and then
datasets
- CloudFront distribution replace for #529 
- Additional EC2 permissions in CDK Synth CodeBuild stage for #543 -->
this can be avoided by upgrading to v1.5.6 before upgrading to v1.6.0
- local development affected by more restrictive pivotRole trust policy


### Relates
V1.6.0 release

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

---------

Co-authored-by: Gezim Musliaj <102723839+gmuslia@users.noreply.github.com>
Co-authored-by: Noah Paige <69586985+noah-paige@users.noreply.github.com>
Co-authored-by: nikpodsh <124577300+nikpodsh@users.noreply.github.com>
Co-authored-by: chamcca <40579012+chamcca@users.noreply.github.com>
Co-authored-by: Nikita Podshivalov <nikpodsh@amazon.com>
Co-authored-by: dbalintx <132444646+dbalintx@users.noreply.github.com>
Co-authored-by: mourya-33 <134511711+mourya-33@users.noreply.github.com>
@dlpzx dlpzx deleted the feat/487-restrict-nacls-backend-vpc branch July 20, 2023 09:17
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.

Restrict NACL rules for backend VPC
4 participants