Implement the new app security group strategy

apburnes commented 3 years ago

In order for spaces to use specific egress rules to lock down or open up access, we must apply the duplicate ASG's to all of the current spaces to keep functionality working as expected before we can remove the global space ASG rule sets. After the duplicate ASG's are applied. We can remove the global ASG's by environment and verify the test suite passes as expected.

Acceptance Criteria

[x] Apply new ASG's to all
[X] Update cg-script org generation to add ASG's and create private spaces
[X] Create blog post - PR
[x] Remove global ASG's
- [x] dev
- [x] staging
- [x] production
[x] Verify tests pass development
[x] Add passing test validation to deployments before promoting env
[x] Add tests to staging
[x] Add tests to production

Security considerations

No change to current spaces but will allow for improved egress control.

Implementation Details

Pause CF Terraform for staging and dev
Update default, global ASG to be a locked down and apply via TF
Apply and test asg's are working as expected with the asg cli and the test suite
Unpause for staging and apply the asg cli and the test suite
Unpause for production and apply the asg cli and the test suite

pburkholder commented 3 years ago

How are we going to handle S3? Most other brokered services in AWS will have a non-routable IP address which we can allow in a no-egress space, but S3 is ... tricky....

On Wed, Oct 6, 2021 at 12:00 PM Andrew Burnes @.***> wrote:

In order for spaces to use specific egress rules to lock down or open up access, we must apply the duplicate ASG's to all of the current spaces to keep functionality working as expected before we can remove the global space ASG rule sets. After the duplicate ASG's are applied. We can remove the global ASG's by environment and verify the test suite passes as expected. Acceptance Criteria

Apply new ASG's to all

Remove global ASG's

Verify tests pass development

Add passing test validation to deployments before promoting env

Add tests to staging and production

Security considerations

No change to current spaces but will allow for improved egress controll.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/cloud-gov/cg-deploy-cf/issues/580, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJHWCXC434IQXUTM7WQVUDUFRXC5ANCNFSM5FPAB5IQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

--

Peter Burkholder | cloud.gov https://cloud.gov ISSO, compliance & security lead please use @.*** for cloud.gov matters

*202-709-2028 <(202)%20209-2028> | @. @.> *

| pronouns he-him https://www.mypronouns.org/he-him *Free/Busy Calendar @.**>

bengerman13 commented 3 years ago

I think we talked about this before, and I think what we came up with was S3 needs to be proxied via the open egress space

pburkholder commented 3 years ago

Here's some of my thoughts from a Slack thread today - and now that I see @bengerman13 's comments, we'll need to check with our customers on whether S3 is needed in spaces they'd otherwise want "closed"

-- S3 is tricky because even in a space marked “no egress” we’ll still want apps there to reach their brokered S3 buckets.

But we can’t do it by IP address because a malicious actor could still get their own S3 govcloud bucket and then use it for exfiltration or C2 (command and control).

So we’ll like have to use something like https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html

If you've already set up access to your Amazon S3 resources from your VPC, you can continue to use Amazon S3 DNS names to access those resources after you've set up an endpoint. However, take note of the following:

and have rules on the VPC s3 gateway for all the S3 buckets we allow egress to:

{
  "Effect": "Allow",
  "Action": [
     "s3:ListBucket",
     "s3:GetObject",
     "s3:PutObject"
  ],
  "Resource": [
     "arn:aws:s3:::example-bucket",
     "arn:aws:s3:::example-bucket/*"
  ]
}

bengerman13 commented 3 years ago

But we can’t do it by IP address because a malicious actor could still get their own S3 govcloud bucket and then use it for exfiltration or C2 (command and control).

We also can't do it by IP because AWS doesn't have dedicated S3 IPs - according to their docs, the same IP block used for S3 is shared by EC2 and general AWS usage.

I really think the solution here is to have users use a proxy for S3 - the S3 SDKs and CLIs all seem to support HTTP_PROXY and HTTPS_PROXY variables, so this should be a relatively low lift once a customer has proxies set up.

apburnes commented 3 years ago

PR to add different types of egress spaces to new org creation. https://github.com/cloud-gov/cg-scripts/pull/181

cloud-gov / deploy-cf