Private Endpoint Access
This page describes a feature that is not enabled by default. Ask your Quilt manager to enable it for you.
Establishing a data perimeter pattern that only allows access to trusted principals from trusted networks is a best practice to guarantee your organization's data security. A data perimeter helps protect your data from unintended access and potential configuration errors via built-in barriers.
You can restrict Amazon S3 bucket access to a particular VPC and VPN traffic via a data perimeter pattern, which prevents leaked S3 credentials from bypassing your organization's VPN.
Quilt already has private IPs for all Quilt services (Lambda functions, API Gateway, Quilt catalog API).
To implement a data perimeter, you will need to take the following steps.
To limit access to Amazon S3 from your VPC you use gateway VPC endpoints. Note that there is no additional charge for using gateway endpoints.
Alternatively you can use AWS PrivateLink for Amazon S3 to provision interface VPC endpoints (interface endpoints) in your VPC. These are assigned private IP addresses from subnets in your VPC.
To allow Quilt services access AWS endpoints other than S3 the traffic from the subnets where Quilt is deployed to the internet should be routed through NAT gateway.
Access should be restricted to trusted networks and principals:
- Allowed VPCs
- Allowed IP ranges
- Specific AWS services used by Quilt:
- AWS Glue
- Amazon Athena
- Amazon CloudWatch
- Principals exempt from network restriction
An SCP defines a guardrail on any action that the account's administrator delegates to the IAM users and roles in the account.
For instructions on enabling SCPs, see the AWS documentation on "Enabling and disabling policy types"
The example policy below denies access (
"Effect": "Deny") to all Amazon S3 buckets prefixed with the string quilt unless any of the following conditions is met:- 1.A
Source VPCmatches eithervpc-LOCALorvpc-VPN. - 2.The principal making the request has
NetworkRestrictedExempttag attached. - 3.The request comes from IP range
192.0.2.0 - 192.0.2.255or203.0.113.0 - 203.0.113.255. - 4.The call to the S3 bucket is beng made by an AWS service principal (the idenitifer for a service,
"aws:PrincipalIsAWSService"), such as CloudWatch, or by an AWS service to another service ("aws:ViaAWSService").
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PreventUnexpectedNetworksButAllowAWSServices",
"Effect": "Deny",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::quilt*",
"arn:aws:s3:::quilt*/*"
],
"Condition": {
"StringNotEqualsIfExists": {
"aws:SourceVpc": [
"vpc-LOCAL",
"vpc-VPN"
]
},
"Null": {
"aws:PrincipalTag/NetworkRestrictedExempt": "true"
},
"NotIpAddressIfExists": {
"aws:SourceIp": [
"192.0.2.0/24",
"203.0.113.0/24"
]
},
"Bool": {
"aws:PrincipalIsAWSService": "false",
"aws:ViaAWSService": "false"
}
}
}
]
}
SCPs should be used in parallel with identity-based or resource-based policies to IAM users or roles, or explicit S3 bucket policies
After doing steps above please check your canaries status to make sure everything works as expected.
- 1.There can only be one gateway endpoint per VPC.
- 2.Your S3 buckets must be in the same region as the gateway endpoint.
- 3.Keeping traffic on private networks will incur Transit Gateway, inter-VPC, and Interface Endpoint charges.
- 4.The DNS of any VPN clients must assign AWS global and regional S3 service names to the Interface Endpoint IP addresses.