| AWS – Allow SSH and or RDP port only to required IPs and VPN Network | It is recommended to restrict access to the SSH and RDP ports to the required IP(s) and VPN network. In addition, it is highly recommended that this access be limited to these ports as required and not include any other ports. Access to other ports should be handled separately as required.This can be implemented using security policies.To create a new security group using the console:1. Open the Amazon EC2 console at <a href=”https://console.aws.amazon.com/ec2/”>https://console.aws.amazon.com/ec2/</a>.2. In the navigation pane, choose Security Groups.3. Choose Create Security Group.4. Specify a name and description for the security group.5. For VPC, choose the ID of the VPC.6. Add Rules and Click on Create.Resource:<a href=”https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html#security-group-rules”>Creating Security Group rules</a> |
| AWS – Protect against accidental termination | By default, you can terminate your instance using the Amazon EC2 console, command line interface, or APIIf you want to prevent your instance from being accidentally terminated using Amazon EC2, you can enable termination protection for the instance.The DisableApiTermination attribute controls whether the instance can be terminated using the console, CLI, or API.To enable termination protection for an instance at launch timeOpen the Amazon EC2 console at <a href=”https://console.aws.amazon.com/ec2/”>https://console.aws.amazon.com/ec2/</a>.On the dashboard, choose Launch Instance and follow the directions in the wizard.On the Configure Instance Details page, select the Enable termination protection check box.Select the instance, and choose Actions, Instance Settings, Change Termination Protection.Choose Yes, EnableResource:<a href=”https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/terminating-instances.html#Using_ChangingDisableAPITermination”>Instance Termination</a> |
| AWS – Ensure detailed monitoring is enabled on EC2 instances | By default, your instance is enabled for basic monitoring. You can optionally enable detailed monitoring. After you enable detailed monitoring, the Amazon EC2 console displays monitoring graphs with a 1-minute period for the instance.You can enable detailed monitoring on an instance as you launch it or after the instance is running or stopped. Enabling detailed monitoring on an instance does not affect the monitoring of the EBS volumes attached to the instance.Steps to Implement:To enable detailed monitoring for an existing instance:Open the Amazon EC2 console at <a href=”https://console.aws.amazon.com/ec2/”>https://console.aws.amazon.com/ec2/</a>.In the navigation pane, choose Instances.Select the instance and choose Actions, CloudWatch Monitoring, Enable Detailed Monitoring.In the Enable Detailed Monitoring dialog box, choose Yes, Enable.Choose Close.To enable detailed monitoring when launching an instance:When launching an instance using the AWS Management Console, select the Monitoring check box on the Configure Instance Details page.Resource:<a href=”https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html”>Enable detailed monitoring for EC2</a> |
| AWS – Ensure communication to global resources is only through VPC endpoints or Privatelink | A VPC endpoint enables you to privately connect your VPC to supported AWS services and VPC endpoint services powered by PrivateLink without requiring an internet gateway, NAT device, VPN connection, or AWS Direct Connect connection. Instances in your VPC do not require public IP addresses to communicate with resources in the service. Traffic between your VPC and the other service does not leave the Amazon network. Endpoints are virtual devices. They are horizontally scaled, redundant, and highly available VPC components that allow communication between instances in your VPC and services without imposing availability risks or bandwidth constraints on your network traffic. There are two types of VPC endpoints: interface endpoints and gateway endpoints. Steps to Implement:To create an interface endpoint to an AWS service using the consoleOpen the Amazon VPC console at <a href=”https://console.aws.amazon.com/vpc/”>https://console.aws.amazon.com/vpc/</a><a href=”https://console.aws.amazon.com/vpc/”></a>In the navigation pane, choose Endpoints, Create Endpoint.For the Service category, ensure that AWS services are selectedFor Service Name, choose the service to which to connect. For Type, ensure that it indicates InterfaceComplete the following information and then choose Create endpoint: VPC: Select VPC in which to create the endpoint; Subnets: select the subnets (Availability Zones) in which to create the endpoint network interfaces; DNS: To enable private DNS for the interface endpoint, for Enable Private DNS Name, select the check box; Security group: select the security groups to associate with the endpoint network interfaces; Tags: (Optional) add any tags.Resources:<a href=”https://docs.aws.amazon.com/AmazonS3/latest/dev/security-best-practices.html#end-points”>S3 Bucket</a> <a href=”https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-and-interface-VPC.html”>Cloudwatch</a> <a href=”https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/load-balancer-vpc-endpoints.html”>ELB </a><a href=”https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/vpc-endpoints-dynamodb-tutorial.html”>DynamoDB</a> <a href=”https://docs.aws.amazon.com/AmazonECS/latest/developerguide/vpc-endpoints.html”>ECS</a> <a href=”https://docs.aws.amazon.com/amazonglacier/latest/dev/network-isolation.html”>Glacier </a><a href=”https://docs.aws.amazon.com/sns/latest/dg/sns-vpc-create-endpoint.html”>SNS</a> <a href=”https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-security-best-practices.html#consider-using-vpc-endpoints-access-sqs”>SQS</a> <a href=”https://docs.aws.amazon.com/athena/latest/ug/interface-vpc-endpoint.html”>Athena </a><a href=”https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html”>ECR</a><a href=”https://docs.aws.amazon.com/emr/latest/ManagementGuide/interface-vpc-endpoint.html”>EMR</a> <a href=”https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/vpc.html”>Elastic Beanstalk</a> <a href=”https://docs.aws.amazon.com/codebuild/latest/userguide/security-traffic-privacy.html”>CodeBuild </a><a href=”https://docs.aws.amazon.com/sagemaker/latest/dg/interface-vpc-endpoint.html”>SageMaker</a><a href=”https://docs.aws.amazon.com/datasync/latest/userguide/datasync-in-vpc.html”>DataSync</a><a href=”https://docs.aws.amazon.com/app-mesh/latest/userguide/vpc-endpoints.html”>App Mesh</a> <a href=”https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-internetwork-traffic-privacy.html”>SQS</a><a href=”https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-vpc-endpoints.html”>AWS EC2 Auto Scaling</a><a href=”https://docs.aws.amazon.com/config/latest/developerguide/config-VPC-endpoints.html”>Config</a><a href=”https://docs.aws.amazon.com/efs/latest/ug/efs-vpc-endpoints.html”>EFS</a><a href=”https://docs.aws.amazon.com/kms/latest/developerguide/kms-vpc-endpoint.html”>KMS</a> |
| AWS – Ensure host OS is built from pre-approved AMI | The integrity of the EC2 instance is, fundamentally, dependent upon the integrity of the AMI (Amazon Machine Image) used for the EC2 launch. Consequently, it is imperative to:Establish that the built or chosen image can be trusted andHave a means to validate the integrity of the image at any point in time.Recommendations for Implementation:Use a golden Amazon Machine ImageIf you are building your own image or adding applications/libraries, analyze code for application-specific vulnerabilities, remove unneeded libraries and packages, restrict functions, and scan for vulnerabilities.Use Amazon Inspector to <a href=”https://aws.amazon.com/blogs/security/how-to-set-up-continuous-golden-ami-vulnerability-assessments-with-amazon-inspector/”>set up</a> continuous vulnerability assessment scans of your golden AMIs.Ensure trust with signing and author/publisher verification. Restrict and monitor access to trusted registries and deployment tools.Host your AMIs in a private VPC registry with restricted access.Reference:<a href=”https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/usingsharedamis-finding.html”>Finding shared AMIs</a> |
| AWS – Enable continuous vulnerability checks | EC2 Amazon Inspector performs security assessments of Amazon EC2 instances by using AWS managed rules packages such as the Common Vulnerabilities and Exposures (CVEs) package. The steps below schedule an Amazon CloudWatch Events rule to run the golden AMI vulnerability assessments on a regular basis. LambdaAWS Lambda provides runtimes that run your function code in an Amazon Linux–based execution environment. Lambda is responsible for keeping software in the runtime and execution environment up to date, releasing new runtimes for new languages and frameworks, and deprecating runtimes when the underlying software is no longer supported. If you use additional libraries with your function, you’re responsible for updating the libraries. You can include additional libraries in the deployment package, or in layers that you attach to your function. You can also build custom runtimes and use layers to share them with other accounts. Lambda deprecates runtimes when the software on the runtime or its execution environment reaches the end of life. When Lambda deprecates a runtime, you’re responsible for migrating your functions to a supported runtime for the same language or framework.Steps to deploy continuous golden AMI vulnerability assessments in your AWS account, follow these steps: Tag your golden AMIs – Tagging your golden AMIs lets you search assessment result findings based on tags after Amazon Inspector completes an assessment. Store your golden AMI metadata in the Systems Manager Parameter Store – Prepare and store the golden AMI metadata in the Systems Manager Parameter Store. The StartContinuousAssessment Lambda function reads golden AMI metadata and starts assessing for vulnerabilities.Run the supplied AWS CloudFormation template and subscribe to an SNS topic to receive assessment results – Set up the infrastructure required to run vulnerability assessments and subscribe to an SNS topic to receive assessment results via email.Test golden AMI vulnerability assessments – Ensure you have successfully set up the required resources to run vulnerability assessments.Set up a CloudWatch Events rule for triggering continuous golden AMI vulnerability assessments – Schedule the execution of vulnerability assessments on a regular basis.References <a href=”https://aws.amazon.com/blogs/security/how-to-set-up-continuous-golden-ami-vulnerability-assessments-with-amazon-inspector/”>https://aws.amazon.com/blogs/security/how-to-set-up-continuous-golden-ami-vulnerability-assessments-with-amazon-inspector/</a>Lambda: <a href=”https://docs.aws.amazon.com/lambda/latest/dg/security-configuration.html”>https://docs.aws.amazon.com/lambda/latest/dg/security-configuration.html</a> |
| AWS – Maintain the health and availability of your compute instances | The AWS global infrastructure is built around AWS Regions and Availability Zones. Regions provide multiple physically separated and isolated Availability Zones, which are connected through low-latency, high-throughput, and highly redundant networking. With Availability Zones, you can design and operate applications and databases that automatically failover between zones without interruption. Availability Zones are more highly available, fault-tolerant, and scalable than traditional single or multiple data center infrastructures. In addition to the AWS global infrastructure, Amazon EC2 offers the following features to support your data resiliency: •Copying AMIs across Regions •Copying EBS snapshots across Regions •Automating EBS snapshots using Amazon Data Lifecycle Manager •Maintaining the health and availability of your fleet using Amazon EC2 Auto Scaling •Distributing incoming traffic across multiple instances in a single Availability Zone or multiple Availability Zones using Elastic Load Balancing The health status of an Auto Scaling instance is either healthy or unhealthy. All instances in your Auto Scaling group start in a healthy state. Instances are assumed to be healthy unless Amazon EC2 Auto Scaling receives notification that they are unhealthy. This notification can come from one or more of the following sources: Amazon EC2, Elastic Load Balancing, or a custom health check. After Amazon EC2 Auto Scaling marks an instance as unhealthy, it is scheduled for replacement. If you do not want instances to be replaced, you can suspend the health check process for any individual Auto Scaling group. References: <a href=”https://docs.aws.amazon.com/autoscaling/ec2/userguide/healthcheck.html”>https://docs.aws.amazon.com/autoscaling/ec2/userguide/healthcheck.html</a> |
| AWS – Distribute incoming traffic across multiple instances in a single Availability Zone or multiple Availability Zones using Elastic Load Balancing | The AWS global infrastructure is built around AWS Regions and Availability Zones. Regions provide multiple physically separated and isolated Availability Zones, which are connected through low-latency, high-throughput, and highly redundant networking. With Availability Zones, you can design and operate applications and databases that automatically failover between zones without interruption. Availability Zones are more highly available, fault-tolerant, and scalable than traditional single or multiple data center infrastructures. In addition to the AWS global infrastructure, Amazon EC2 offers the following features to support your data resiliency: Copying AMIs across RegionsCopying EBS snapshots across RegionsAutomating EBS snapshots using Amazon Data Lifecycle ManagerMaintaining the health and availability of your fleet using Amazon EC2 Auto ScalingDistributing incoming traffic across multiple instances in a single Availability Zone or multiple Availability Zones using Elastic Load BalancingReference: <a href=”https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/disaster-recovery-resiliency.html”>https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/disaster-recovery-resiliency.html</a> <a href=”https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/load-balancer-getting-started.html”>https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/load-balancer-getting-started.html</a> |
| AWS – Securely configure your EC2 security groups | Configure the security groups for your Amazon EC2 instances to accept traffic only from the load balancer. These security groups must allow inbound traffic from the load balancer on the listener ports and the health check ports.To allow communication between your load balancer and your instances, Create an inbound rule for the security group for your instances that allows inbound traffic only from the load balancer (using the source security group provided by Elastic Load Balancing).To lock down traffic between your load balancer and instances using the console, follow the steps mentioned below:Open the Amazon EC2 console at <a href=”https://console.aws.amazon.com/ec2/.”>https://console.aws.amazon.com/ec2/.</a>On the navigation pane, under LOAD BALANCING, choose Load Balancers.Select your load balancer.On the Description tab, copy the name of the source security group.On the Instances tab, select the instance ID of one of the instances registered with your load balancer.On the Description tab, for Security groups, select the name of the security group.On the Inbound tab, choose Edit, Add Rule.From the Type column, select the protocol type. The Protocol and Port Range columns are populated. From the Source column, select Custom IP and then paste the name of the source security group that you copied earlier (for example, amazon-elb/amazon-elb-sg).(Optional) If your security group has rules that are less restrictive than the rule that you just added, remove the less restrictive rule using its delete icon.To lock down traffic between your load balancer and instances using the AWS CLI, follow the steps mentioned <a href=”https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-groups.html#elb-classic-security-groups”>here</a>Reference:<a href=”https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-groups.html#elb-classic-security-groups”>https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-groups.html#elb-classic-security-groups</a> |
| AWS – Launch an instance in a private subnet | Launch the EC2 instance in private subnet unless it’s really required to be launched in Public subnet.You can improve the security posture of your VPC by configuring Amazon EC2 to use an interface VPC endpoint. Interface endpoints are powered by AWS PrivateLink, a technology that enables you to privately access Amazon EC2 APIs by restricting all network traffic between your VPC and Amazon EC2 to the Amazon network. With interface endpoints, you also don’t need an internet gateway, a NAT device, or a virtual private gateway.Steps to implement:1. Create an endpoint for Amazon EC2 using the following service name:com.amazonaws.region.ec2 — Creates an endpoint for the Amazon EC2 API actions.2. You can attach a policy to your VPC endpoint to control access to the Amazon EC2 API. The policy specifies:The principal that can perform actions.The actions that can be performed.The resource on which the actions can be performed.Important: When a non-default policy is applied to an interface VPC endpoint for Amazon EC2, certain failed API requests, such as those failing from RequestLimitExceeded, might not be logged to AWS CloudTrail or Amazon CloudWatch.Reference: <a href=”https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/interface-vpc-endpoints.html”>https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/interface-vpc-endpoints.html</a> |
AWS-EKS
| AWS – Use restrictive EKS Pod Security Policy | The Kubernetes pod security policy admission controller validates pod creation and update requests against a set of rules. By default, Amazon EKS clusters ship with a fully permissive security policy with no restrictions. This is an example of a restrictive policy that requires users to run as an unprivileged user, blocks possible escalations to root, and requires use of several security mechanisms.apiVersion: policy/v1beta1kind: PodSecurityPolicymetadata: name: restricted annotations: seccomp.security.alpha.kubernetes.io/allowedProfileNames: ‘docker/default,runtime/default’ apparmor.security.beta.kubernetes.io/allowedProfileNames: ‘runtime/default’ seccomp.security.alpha.kubernetes.io/defaultProfileName: ‘runtime/default’ apparmor.security.beta.kubernetes.io/defaultProfileName: ‘runtime/default’spec: privileged: false # Required to prevent escalations to root. allowPrivilegeEscalation: false # This is redundant with non-root + disallow privilege escalation, # but we can provide it for defense in depth. requiredDropCapabilities: – ALL # Allow core volume types. volumes: – ‘configMap’ – ’emptyDir’ – ‘projected’ – ‘secret’ – ‘downwardAPI’ # Assume that persistentVolumes set up by the cluster admin are safe to use. – ‘persistentVolumeClaim’ hostNetwork: false hostIPC: false hostPID: false runAsUser: # Require the container to run without root privileges. rule: ‘MustRunAsNonRoot’ seLinux: # This policy assumes the nodes are using AppArmor rather than SELinux. rule: ‘RunAsAny’ supplementalGroups: rule: ‘MustRunAs’ ranges: # Forbid adding the root group. – min: 1 max: 65535 fsGroup: rule: ‘MustRunAs’ ranges: # Forbid adding the root group. – min: 1 max: 65535 readOnlyRootFilesystem: falseResources:<a href=”https://kubernetes.io/docs/concepts/policy/pod-security-policy/”>Pod Security Policy</a><a href=”https://docs.aws.amazon.com/eks/latest/userguide/pod-security-policy.html”>Default EKS Pod Security Policy</a> |
| AWS – Ensure that envelope encryption of Kubernetes secrets using Amazon KMS is enabled | Description If you enable <a href=”https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/”>secrets encryption</a>, the Kubernetes secrets are encrypted using the AWS KMS key that you select. The KMS key must meet the following conditions: – Symmetric – Can encrypt and decrypt data – Created in the same AWS Region as the cluster – If the KMS key was created in a different account, the user must have access to the KMS key. For more information, see <a href=”https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html”>Allowing users in other accounts to use a KMS key</a> in the <a href=”https://docs.aws.amazon.com/kms/latest/developerguide/overview.html”>AWS Key Management Service Developer Guide</a>. Warning: You can’t disable secrets encryption after enabling it. This action is irreversible. To enable secrets encryption through AWS Management Console Open the Amazon EKS console at <a href=”https://console.aws.amazon.com/eks/home#/clusters”>https://console.aws.amazon.com/eks/home#/clusters</a>. Choose the cluster that you want to add KMS encryption to. Choose the Overview tab (this is selected by default). Scroll down to the Secrets encryption section and choose Enable. Select a key from the dropdown list and choose the Enable button. If no keys are listed, you must create one first. For more information, see Creating keys. Choose the Confirm button to use the chosen key. After you enabled encryption on your cluster, you must encrypt all existing secrets with the new key: Note: If you use eksctl, running the following command is necessary only if you opt out of re-encrypting your secrets automatically. kubectl get secrets –all-namespaces -o json | kubectl annotate –overwrite -f – kms-encryption-timestamp=”time value” Warning: If you enable secrets encryption for an existing cluster and the KMS key that you use is ever deleted, then there’s no way to recover the cluster. If you delete the KMS key, you permanently put the cluster in a degraded state. For more information, see Deleting AWS KMS keys. Note By default, the create-key command creates a <a href=”https://docs.aws.amazon.com/kms/latest/developerguide/symmetric-asymmetric.html”>symmetric encryption KMS key</a> with a key policy that gives the account root admin access on AWS KMS actions and resources. If you want to scope down the permissions, make sure that the kms:DescribeKey and kms:CreateGrant actions are permitted on the policy for the principal that calls the create-cluster API. For clusters using KMS Envelope Encryption, kms:CreateGrant permissions are required. The condition kms:GrantIsForAWSResource is not supported for the CreateCluster action, and should not be used in KMS policies to control kms:CreateGrant permissions for users performing CreateCluster. Resources: <a href=”https://docs.aws.amazon.com/eks/latest/userguide/enable-kms.html”>Enabling secret encryption on an existing cluster</a> <a href=”https://aws.amazon.com/blogs/security/tag/amazon-eks/”>AWS EKS Security Blog</a> |
| AWS – Configure internal load balancers | Amazon EKS supports the Network Load Balancer and the Classic Load Balancer for pods running on Amazon EC2 instance worker nodes through the Kubernetes service of type LoadBalancer. By default, services of type LoadBalancer create public-facing load balancers. To use an internal load balancer, apply the following annotation to your service:service.beta.kubernetes.io/aws-load-balancer-internal: 0.0.0.0/0For internal load balancers, your Amazon EKS cluster must be configured to use at least one private subnet in your VPC. Kubernetes examines the route table for your subnets to identify whether they are public or private. Public subnets have a route directly to the internet using an internet gateway, but private subnets do not.Resource:<a href=”https://docs.aws.amazon.com/eks/latest/userguide/load-balancing.html”>Configuring internal load balancers</a> |
| AWS – EKS with cluster should be added to the cluster security group | If your cluster is running Kubernetes version 1.14 and platform version eks.3 or later, we recommend that you add the cluster security group to all existing and future worker node groupsSecurity Group BasicsThe following are the basic characteristics of security groups for your VPC:There are quotas on the number of security groups that you can create per VPC, the number of rules that you can add to each security group, and the number of security groups that you can associate with a network interface. For more information, see Amazon VPC Quotas.You can specify allow rules, but not deny rules.You can specify separate rules for inbound and outbound traffic.When you create a security group, it has no inbound rules.Amazon EKS strongly recommends that you use a dedicated security group for each control plane (one per cluster).If you launch worker nodes with the AWS CloudFormation template in the Getting Started with Amazon EKS walkthrough, AWS CloudFormation modifies the control plane security group to allow communication with the worker nodes.Settings can be found: <a href=”https://docs.aws.amazon.com/eks/latest/userguide/sec-group-reqs.html”>Security Group Requirements</a>Resources:<a href=”https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html”>VPC Security Groups</a> |
| AWS – Minimize cluster access to read-only for Amazon ECR | Description Configure the Cluster Service Account with Storage Object Viewer Role to only allow read- only access to Amazon ECR. Rationale: The Cluster Service Account does not require administrative access to Amazon ECR, only requiring pull access to containers to deploy onto Amazon EKS. Restricting permissions follows the principles of least privilege and prevents credentials from being abused beyond the required role. Impact: A separate dedicated service account may be required for use by build servers and other robot users pushing or managing container images. Audit: Review AWS ECS worker node IAM role (NodeInstanceRole) IAM Policy Permissions to verify that they are set and the minimum required level. If utilizing a 3rd party tool to scan images utilize the minimum required permission level required to interact with the cluster – generally this should be read-only. Remediation: You can use your Amazon ECR images with Amazon EKS, but you need to satisfy the following prerequisites. The Amazon EKS worker node IAM role (NodeInstanceRole) that you use with your worker nodes must possess the following IAM policy permissions for Amazon ECR. { “Version”: “2012-10-17”, “Statement”: [ { “Effect”: “Allow”, “Action”: [ “ecr:BatchCheckLayerAvailability”, “ecr:BatchGetImage”, “ecr:GetDownloadUrlForLayer”, “ecr:GetAuthorizationToken” ], “Resource”: “*” } ] } Default Value: If you used eksctl or the AWS CloudFormation templates in <a href=”https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html”>Getting Started with Amazon EKS</a> to create your cluster and worker node groups, these IAM permissions are applied to your worker node IAM role by default. References: <a href=”https://docs.aws.amazon.com/AmazonECR/latest/userguide/ECR_on_EKS.html”>Using Amazon ECR Images with Amazon EKS</a> |
| AWS – Minimize user access to Amazon ECR | Restrict user access to Amazon ECR, limiting interaction with build images to only authorized personnel and service accounts. Rationale: Weak access control to Amazon ECR may allow malicious users to replace built images with vulnerable containers. Impact: Care should be taken not to remove access to Amazon ECR for accounts that require this for their operation. Audit: Remediation: Before you use IAM to manage access to Amazon ECR, you should understand what IAM features are available to use with Amazon ECR. To get a high-level view of how Amazon ECR and other AWS services work with IAM, see <a href=”https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html”>AWS Services That Work with IAM</a> in the IAM User Guide. Topics Amazon ECR Identity-Based Policies Amazon ECR Resource-Based Policies Authorization Based on Amazon ECR Tags Amazon ECR IAM Roles Amazon ECR Identity-Based Policies With IAM identity-based policies, you can specify allowed or denied actions and resources as well as the conditions under which actions are allowed or denied. Amazon ECR supports specific actions, resources, and condition keys. To learn about all of the elements that you use in a JSON policy, see <a href=”https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html”>IAM JSON Policy Elements Reference</a> in the IAM User Guide. Actions The Action element of an IAM identity-based policy describes the specific action or actions that will be allowed or denied by the policy. Policy actions usually have the same name as the associated AWS API operation. The action is used in a policy to grant permissions to perform the associated operation. Policy actions in Amazon ECR use the following prefix before the action: ecr:. For example, to grant someone permission to create an Amazon ECR repository with the Amazon ECR CreateRepository API operation, you include the ecr:CreateRepository action in their policy. Policy statements must include either an Action or NotAction element. Amazon ECR defines its own set of actions that describe tasks that you can perform with this service. To specify multiple actions in a single statement, separate them with commas as follows: “Action”: [ “ecr:action1”, “ecr:action2” You can specify multiple actions using wildcards (*). For example, to specify all actions that begin with the word Describe, include the following action: “Action”: “ecr:Describe*” To see a list of Amazon ECR actions, see <a href=”https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerregistry.html”>Actions, Resources, and Condition Keys for Amazon Elastic Container Registry</a> in the IAM User Guide. Resources The Resource element specifies the object or objects to which the action applies. Statements must include either a Resource or a NotResource element. You specify a resource using an ARN or using the wildcard (*) to indicate that the statement applies to all resources. An Amazon ECR repository resource has the following ARN: arn:${Partition}:ecr:${Region}:${Account}:repository/${Repository-name} For more information about the format of ARNs, see <a href=”https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html”>Amazon Resource Names (ARNs) and AWS Service Namespaces</a>. For example, to specify the my-repo repository in the us-east-1 Region in your statement, use the following ARN: “Resource”: “arn:aws:ecr:us-east-1:123456789012:repository/my-repo” To specify all repositories that belong to a specific account, use the wildcard (*): “Resource”: “arn:aws:ecr:us-east-1:123456789012:repository/*” To specify multiple resources in a single statement, separate the ARNs with commas. “Resource”: [ “resource1”, “resource2” To see a list of Amazon ECR resource types and their ARNs, see <a href=”https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerregistry.html”>Resources Defined by Amazon Elastic Container Registry</a> in the IAM User Guide. To learn with which actions you can specify the ARN of each resource, see <a href=”https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerregistry.html”>Actions Defined by Amazon Elastic Container Registry</a>.Condition KeysThe Condition element (or Condition block) lets you specify conditions in which a statement is in effect. The Condition element is optional. You can build conditional expressions that use condition operators, such as equals or less than, to match the condition in the policy with values in the request. If you specify multiple Condition elements in a statement, or multiple keys in a single Condition element, AWS evaluates them using a logical AND operation. If you specify multiple values for a single condition key, AWS evaluates the condition using a logical OR operation. All of the conditions must be met before the statement’s permissions are granted. You can also use placeholder variables when you specify conditions. For example, you can grant an IAM user permission to access a resource only if it is tagged with their IAM user name. For more information, see <a href=”https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html”>IAM Policy Elements: Variables and Tags</a> in the IAM User Guide. Amazon ECR defines its own set of condition keys and also supports using some global condition keys. To see all AWS global condition keys, see <a href=”https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html”>AWS Global Condition Context Keys</a> in the IAM User Guide. Most Amazon ECR actions support the aws:ResourceTag and ecr:ResourceTag condition keys. For more information, see <a href=”https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html”>Using Tag-Based Access Control</a>. To see a list of Amazon ECR condition keys, see <a href=”https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerregistry.html”>Condition Keys Defined by Amazon Elastic Container Registry</a> in the IAM User Guide. To learn with which actions and resources you can use a condition key, see <a href=”https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerregistry.html”>Actions Defined by Amazon Elastic Container Registry</a>. References: <a href=”https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-scanning.html#scanning-repository”>Image scanning</a> |
| AWS – Minimize Container Registries to only those approved | Use approved container registries. Rationale: Allowing unrestricted access to external container registries provides the opportunity for malicious or unapproved containers to be deployed into the cluster. Allowlisting only approved container registries reduces this risk. Impact: All container images to be deployed to the cluster must be hosted within an approved container image registry. References: <a href=”https://aws.amazon.com/blogs/opensource/using-open-policy-agent-on-amazon-eks/”>Using Open Policy Agent on Amazon EKS</a> |
| AWS – Consider Fargate for running untrusted workloads | It is best practice to restrict or fence untrusted workloads when running in a multi-tenant environment. Remediation: Before you can schedule pods running on Fargate in your cluster, you must define a Fargate profile that specifies which pods should use Fargate when they are launched. For more information, see AWS Fargate profile. Note: If you created your cluster with eksctl using the –fargate option, then a Fargate profile has already been created for your cluster with selectors for all pods in the kube-system and default namespaces. Use the following procedure to create Fargate profiles for any other namespaces you would like to use with Fargate. To create a Fargate profile for a cluster with the AWS Management Console:1. Open the Amazon EKS console at <a href=”https://console.aws.amazon.com/eks/home#/clusters.”>https://console.aws.amazon.com/eks/home#/clusters.</a>2. Choose the cluster to create a Fargate profile for.3. Under Fargate profiles, choose Add Fargate profile,4. On the Configure Fargate profile page, enter the following information and choose Next. – For Name, enter a unique name for your Fargate profile. – For Pod execution role, choose the pod execution role to use with your Fargate profile. Only IAM roles with the eks-fargate-pods.amazonaws.com service principal are shown. If you do not see any roles listed here, you must create one. For more information, see <a href=”https://docs.aws.amazon.com/eks/latest/userguide/pod-execution-role.html”>Pod execution role</a>. – For Subnets, choose the subnets to use for your pods. By default, all subnets in your cluster’s VPC are selected. Only private subnets are supported for pods running on Fargate; you must deselect any public subnets. – For Tags, you can optionally tag your Fargate profile. These tags do not propagate to other resources associated with the profile, such as its pods.5. On the Configure pods selection page, enter the following information and choose Next. – For Namespace, enter a namespace to match for pods, such as kube-system or default. – (Optional) Add Kubernetes labels to the selector that pods in the specified namespace must have to match the selector. For example, you could add the label infrastructure: fargate to the selector so that only pods in the specified namespace that also have the infrastructure: fargate Kubernetes label match the selector. 6. On the Review and create page, review the information for your Fargate profile and choose Create. Default Value:By default, AWS Fargate is not utilized.References: <a href=”https://docs.aws.amazon.com/eks/latest/userguide/fargate.html”>AWS Fargate</a> |
| EKS – Logging – Enable audit logs | Control plane logs provide visibility into operation of the EKS Control plane component systems. The API server audit logs record all accepted and rejected requests in the cluster. When enabled via EKS configuration the control plane logs for a cluster are exported to a CloudWatch Log Group for persistence |
| EKS – Worker Node – Ensure that the kubeconfig file permissions are set to 644 or more restrictive | If kubelet is running, and if it is configured by a kubeconfig file, ensure that the proxy kubeconfig file has permissions of 644 or more restrictive. |
| EKS – Worker Node – Ensure that the kubelet kubeconfig file ownership is set to root:root | If kubelet is running, ensure that the file ownership of its kubeconfig file is set to root:root. |
| EKS – Worker Node – Ensure that the kubelet configuration file has permissions set to 644 or more restrictive | Ensure that if the kubelet refers to a configuration file with the –config argument, that file has permissions of 644 or more restrictive. |
| EKS – Worker Node – Ensure that the kubelet configuration file ownership is set to root:root | Ensure that if the kubelet refers to a configuration file with the –config argument, that file is owned by root:root |
| EKS – Kubelet – Ensure that the Anonymous Auth is Not Enabled | When enabled, requests that are not rejected by other configured authentication methods are treated as anonymous requests. These requests are then served by the Kubelet server. You should rely on authentication to authorize access and disallow anonymous requests. |
| EKS – Kubelet – Ensure that the –authorization-mode argument is not set to AlwaysAllow | Kubelets can be configured to allow all authenticated requests (even anonymous ones) without needing explicit authorization checks from the apiserver. You should restrict this behavior and only allow explicitly authorized requests. |
| EKS – Kubelet – Ensure that a Client CA File is Configured | Enable Kubelet authentication using certificates. Enabling Kubelet certificate authentication ensures that the API server could authenticate the Kubelet before submitting any requests |
| EKS – Kubelet – Ensure that the –read-only-port is disabled | The Kubelet process provides a read-only API in addition to the main Kubelet API. Unauthenticated access is provided to this read-only API which could possibly retrieve potentially sensitive information about the cluster |
| EKS – Kubelet – Ensure that the –streaming-connection-idle-timeout argument is not set to 0 | Do not disable timeouts on streaming connections. Setting idle timeouts ensures that you are protected against Denial-of-Service attacks, inactive connections and running out of ephemeral ports |
| EKS – Kubelet – Ensure that the –protect-kernel-defaults argument is set to true | Protect tuned kernel parameters from overriding kubelet default kernel parameter values |
| EKS – Kubelet – Ensure that the –make-iptables-util-chains argument is set to true | Allow Kubelet to manage iptables. Kubelets can automatically manage the required changes to iptables based on how you choose your networking options for the pods. It is recommended to let kubelets manage the changes to iptables. This ensures that the iptables configuration remains in sync with pods networking configuration. Manually configuring iptables with dynamic pod network configuration changes might hamper the communication between pods/containers and to the outside world. You might have iptables rules too restrictive or too open |
| EKS – Kubelet – Ensure that the –hostname-override argument is not set | Do not override node hostnames. Overriding hostnames could potentially break TLS setup between the kubelet and the apiserver. Additionally, with overridden hostnames, it becomes increasingly difficult to associate logs with a particular node and process them for security analytics |
| EKS – Kubelet – Ensure that the –eventRecordQPS argument is set to 0 or a level which ensures appropriate event capture | Security relevant information should be captured. The –eventRecordQPS flag on the Kubelet can be used to limit the rate at which events are gathered. Setting this too low could result in relevant events not being logged, however the unlimited setting of 0 could result in a denial of service on the kubelet |
| EKS – Kubelet – Ensure that the –rotate-certificates argument is not present or is set to true | Enable kubelet client certificate rotation. The –rotate-certificates setting causes the kubelet to rotate its client certificates by creating new CSRs as its existing credentials expire. This automated periodic rotation ensures that the there is no downtime due to expired certificates and thus addressing availability in the CIA (Confidentiality, Integrity, and Availability) security triad |
| EKS – Kubelet – Ensure that the RotateKubeletServerCertificate argument is set to true | Enable kubelet server certificate rotation. RotateKubeletServerCertificate causes the kubelet to both request a serving certificate after bootstrapping its client credentials and rotate the certificate as its existing credentials expire. This automated periodic rotation ensures that the there are no downtimes due to expired certificates and thus addressing availability in the CIA (Confidentiality, Integrity, and Availability) security triad |
| EKS – Container Optimized OS – Prefer using a container-optimized OS when possible | A container-optimized OS is an operating system image that is designed for secure managed hosting of containers on compute instances. |
| EKS – RBAC – Ensure that the cluster-admin role is only used where required | The RBAC role cluster-admin provides wide-ranging powers over the environment and should be used only where and when needed |
| EKS – RBAC – Minimize access to secrets | The Kubernetes API stores secrets, which may be service account tokens for the Kubernetes API or credentials used by workloads in the cluster. Access to these secrets should be restricted to the smallest possible group of users to reduce the risk of privilege escalation |
| EKS – RBAC – Minimize wildcard use in Roles and ClusterRoles | Kubernetes Roles and ClusterRoles provide access to resources based on sets of objects and actions that can be taken on those objects. It is possible to set either of these to be the wildcard “*” which matches all items. Use of wildcards is not optimal from a security perspective as it may allow for inadvertent access to be granted when new resources are added to the Kubernetes API either as CRDs or in later versions of the product. |
| EKS – RBAC – Minimize access to create pods | The ability to create pods in a namespace can provide a number of opportunities for privilege escalation, such as assigning privileged service accounts to these pods or mounting hostPaths with access to sensitive data (unless Pod Security Policies are implemented to restrict this access) As such, access to create new pods should be restricted to the smallest possible group of users |
| EKS – RBAC – Ensure that default service accounts are not actively used | The default service account should not be used to ensure that rights granted to applications can be more easily audited and reviewed. |
| EKS – RBAC – Ensure that Service Account Tokens are only mounted where necessary | Service accounts tokens should not be mounted in pods except where the workload running in the pod explicitly needs to communicate with the API server |
| EKS – RBAC – Avoid use of system:masters group | The special group system:masters should not be used to grant permissions to any user or service account, except where strictly necessary (e.g. bootstrapping access prior to RBAC being fully available) |
| EKS – RBAC – Limit use of the Bind, Impersonate and Escalate permissions in the Kubernetes cluster | Cluster roles and roles with the impersonate, bind or escalate permissions should not be granted unless strictly required. Each of these permissions allow a particular subject to escalate their privileges beyond those explicitly granted by cluster administrators |
| EKS – Pod Security – Minimize the admission of privileged containers | Do not generally permit containers to be run with the securityContext.privileged flag set to true. Reference: <a href=”https://kubernetes.io/docs/concepts/policy/pod-security-policy”>https://kubernetes.io/docs/concepts/policy/pod-security-policy</a> |
| EKS – Pod Security – Minimize the admission of containers wishing to share the host process ID namespace | Do not generally permit containers to be run with the hostPID flag set to true Reference: <a href=”https://kubernetes.io/docs/concepts/policy/pod-security-policy”>https://kubernetes.io/docs/concepts/policy/pod-security-policy</a> |
| EKS – Pod Security – Minimize the admission of containers wishing to share the host IPC namespace | Do not generally permit containers to be run with the hostIPC flag set to true. Reference: <a href=”https://kubernetes.io/docs/concepts/security/pod-security-policy/”>https://kubernetes.io/docs/concepts/security/pod-security-policy/</a> |
| EKS – Pod Security – Minimize the admission of containers wishing to share the host network namespace | Do not generally permit containers to be run with the hostNetwork flag set to true. Reference: <a href=”https://kubernetes.io/docs/concepts/policy/pod-security-policy”>https://kubernetes.io/docs/concepts/policy/pod-security-policy</a> |
| EKS – Pod Security – Minimize the admission of containers with allowPrivilegeEscalation | Do not generally permit containers to be run with the allowPrivilegeEscalation flag set to true Reference: <a href=”https://kubernetes.io/docs/concepts/policy/pod-security-policy”>https://kubernetes.io/docs/concepts/policy/pod-security-policy</a> |
| EKS – Pod Security – Minimize the admission of root containers | Do not generally permit containers to be run as the root user. Reference: <a href=”https://kubernetes.io/docs/concepts/policy/pod-security-policy”>https://kubernetes.io/docs/concepts/policy/pod-security-policy</a> |
| EKS – Pod Security – Minimize the admission of containers with added capabilities | Do not generally permit containers with capabilities assigned beyond the default set. Containers run with a default set of capabilities as assigned by the Container Runtime. Capabilities outside this set can be added to containers which could expose them to risks of container breakout attacks. There should be at least one PodSecurityPolicy (PSP) defined which prevents containers with capabilities beyond the default set from launching. If you need to run containers with additional capabilities, this should be defined in a separate PSP and you should carefully check RBAC controls to ensure that only limited service accounts and users are given permission to access that PSP Reference: <a href=”https://kubernetes.io/docs/concepts/policy/pod-security-policy”>https://kubernetes.io/docs/concepts/policy/pod-security-policy</a> |
| EKS – Pod Security – Minimize the admission of containers with capabilities assigned | Do not generally permit containers with capabilities Reference: <a href=”https://kubernetes.io/docs/concepts/policy/pod-security-policy”>https://kubernetes.io/docs/concepts/policy/pod-security-policy</a> |
| EKS – CNI Plugin – Ensure CNI plugin supports network policies. | There are a variety of CNI plugins available for Kubernetes. If the CNI in use does not support Network Policies it may not be possible to effectively restrict traffic in the cluster. |
| EKS – CNI Plugin – Ensure that all Namespaces have Network Policies defined | Use network policies to isolate traffic in your cluster network. |
| EKS – Secrets Management – Prefer using secrets as files over secrets as environment variables | Kubernetes supports mounting secrets as data volumes or as environment variables. Minimize the use of environment variable secrets. |
| EKS – Secrets Management – Consider external secret storage | Consider the use of an external secrets storage and management system, instead of using Kubernetes Secrets directly, if you have more complex secret management needs. Ensure the solution requires authentication to access secrets, has auditing of access to and use of secrets, and encrypts secrets. Some solutions also make it easier to rotate secrets |
| EKS – General Policy – Create administrative boundaries between resources using namespaces | Use namespaces to isolate your Kubernetes objects. Reference: <a href=”http://blog.kubernetes.io/2016/08/security-best-practices-kubernetes-deployment.html”>http://blog.kubernetes.io/2016/08/security-best-practices-kubernetes-deployment.html</a> |
| EKS – General Policy – Apply Security Context to Your Pods and Containers | Apply Security Context to Your Pods and Containers Reference: <a href=”https://kubernetes.io/docs/concepts/policy/security-context/”>https://kubernetes.io/docs/concepts/policy/security-context/</a> |
| EKS – General Policy – The default namespace should not be used | Kubernetes provides a default namespace, where objects are placed if no namespace is specified for them. Placing objects in this namespace makes application of RBAC and other controls more difficult. |
| EKS – Image Registry & Scanning – Ensure Image Vulnerability Scanning using Amazon ECR image scanning or a third party provider | Scan images being deployed to Amazon EKS for vulnerabilities. Reference: <a href=”https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-scanning.html”>https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-scanning.html</a> |
| EKS – Image Registry & Scanning – Minimize user access to Amazon ECR | Restrict user access to Amazon ECR, limiting interaction with build images to only authorized personnel and service accounts |
| EKS – Image Registry & Scanning – Minimize cluster access to read-only for Amazon ECR | Configure the Cluster Service Account with Storage Object Viewer Role to only allow read-only access to Amazon ECR |
| EKS – Image Registry & Scanning – Minimize Container Registries to only those approved | Use approved container registries. Allowing unrestricted access to external container registries provides the opportunity for malicious or unapproved containers to be deployed into the cluster. Allowlisting only approved container registries reduces this risk |
| EKS – IAM – Prefer using dedicated EKS Service Accounts | Kubernetes workloads should not use cluster node service accounts to authenticate to Amazon EKS APIs. Each Kubernetes workload that needs to authenticate to other AWS services using AWS IAM should be provisioned with a dedicated Service account Reference: <a href=”https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html”>https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html</a> |
| EKS – KMS – Ensure Kubernetes Secrets are encrypted using Customer Master Keys managed in AWS KMS | Encrypt Kubernetes secrets, stored in etcd, using secrets encryption feature during Amazon EKS cluster creation. Reference: <a href=”https://aws.amazon.com/about-aws/whats-new/2020/03/amazon-eks-adds-envelope-encryption-for-secrets-with-aws-kms/”>https://aws.amazon.com/about-aws/whats-new/2020/03/amazon-eks-adds-envelope-encryption-for-secrets-with-aws-kms/</a> |
| EKS – Cluster Networking – Restrict Access to the Control Plane Endpoint | Enable Endpoint Private Access to restrict access to the cluster’s control plane to only an allowlist of authorized IPs Reference: https://docs.aws.amazon.com/eks/latest/userguide/cluster-endpoint.html |
| EKS – Cluster Networking – Ensure clusters are created with Private Endpoint Enabled and Public Access Disabled | Disable access to the Kubernetes API from outside the node network if it is not required. |
| EKS – Cluster Networking – Ensure clusters are created with Private Nodes | Disable public IP addresses for cluster nodes, so that they only have private IP addresses. Private Nodes are nodes with no public IP addresses |
| EKS – Cluster Networking – Ensure Network Policy is Enabled and set as appropriate | Amazon EKS provides two ways to implement network policy. You choose a network policy option when you create an EKS cluster. The policy option can’t be changed after the cluster is created: Calico Network Policies, an open-source network and network security solution founded by Tigera. Both implementations use Linux IPTables to enforce the specified policies. Policies are translated into sets of allowed and disallowed IP pairs. These pairs are then programmed as IPTable filter rules |
| EKS – Cluster Networking – Encrypt traffic to HTTPS load balancers with TLS certificates | Encrypt traffic to HTTPS load balancers using TLS certificates. |
| EKS – Authentication & Authorization – Manage Kubernetes RBAC users with AWS IAM Authenticator for Kubernetes | Amazon EKS uses IAM to provide authentication to your Kubernetes cluster through the AWS IAM Authenticator for Kubernetes. You can configure the stock kubectl client to work with Amazon EKS by installing the AWS IAM Authenticator for Kubernetes and modifying your kubectl configuration file to use it for authentication. |
| EKS – Other Config – Consider Fargate for running untrusted workloads | It is Best Practice to restrict or fence untrusted workloads when running in a multi-tenant environment |
aws-kms
| AWS – Ensure communication to global resources is only through VPC endpoints or Privatelink | A VPC endpoint enables you to privately connect your VPC to supported AWS services and VPC endpoint services powered by PrivateLink without requiring an internet gateway, NAT device, VPN connection, or AWS Direct Connect connection. Instances in your VPC do not require public IP addresses to communicate with resources in the service. Traffic between your VPC and the other service does not leave the Amazon network. Endpoints are virtual devices. They are horizontally scaled, redundant, and highly available VPC components that allow communication between instances in your VPC and services without imposing availability risks or bandwidth constraints on your network traffic. There are two types of VPC endpoints: interface endpoints and gateway endpoints. Steps to Implement:To create an interface endpoint to an AWS service using the consoleOpen the Amazon VPC console at <a href=”https://console.aws.amazon.com/vpc/”>https://console.aws.amazon.com/vpc/</a><a href=”https://console.aws.amazon.com/vpc/”></a>In the navigation pane, choose Endpoints, Create Endpoint.For the Service category, ensure that AWS services are selectedFor Service Name, choose the service to which to connect. For Type, ensure that it indicates InterfaceComplete the following information and then choose Create endpoint: VPC: Select VPC in which to create the endpoint; Subnets: select the subnets (Availability Zones) in which to create the endpoint network interfaces; DNS: To enable private DNS for the interface endpoint, for Enable Private DNS Name, select the check box; Security group: select the security groups to associate with the endpoint network interfaces; Tags: (Optional) add any tags.Resources:<a href=”https://docs.aws.amazon.com/AmazonS3/latest/dev/security-best-practices.html#end-points”>S3 Bucket</a> <a href=”https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-and-interface-VPC.html”>Cloudwatch</a> <a href=”https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/load-balancer-vpc-endpoints.html”>ELB </a><a href=”https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/vpc-endpoints-dynamodb-tutorial.html”>DynamoDB</a> <a href=”https://docs.aws.amazon.com/AmazonECS/latest/developerguide/vpc-endpoints.html”>ECS</a> <a href=”https://docs.aws.amazon.com/amazonglacier/latest/dev/network-isolation.html”>Glacier </a><a href=”https://docs.aws.amazon.com/sns/latest/dg/sns-vpc-create-endpoint.html”>SNS</a> <a href=”https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-security-best-practices.html#consider-using-vpc-endpoints-access-sqs”>SQS</a> <a href=”https://docs.aws.amazon.com/athena/latest/ug/interface-vpc-endpoint.html”>Athena </a><a href=”https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html”>ECR</a><a href=”https://docs.aws.amazon.com/emr/latest/ManagementGuide/interface-vpc-endpoint.html”>EMR</a> <a href=”https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/vpc.html”>Elastic Beanstalk</a> <a href=”https://docs.aws.amazon.com/codebuild/latest/userguide/security-traffic-privacy.html”>CodeBuild </a><a href=”https://docs.aws.amazon.com/sagemaker/latest/dg/interface-vpc-endpoint.html”>SageMaker</a><a href=”https://docs.aws.amazon.com/datasync/latest/userguide/datasync-in-vpc.html”>DataSync</a><a href=”https://docs.aws.amazon.com/app-mesh/latest/userguide/vpc-endpoints.html”>App Mesh</a> <a href=”https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-internetwork-traffic-privacy.html”>SQS</a><a href=”https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-vpc-endpoints.html”>AWS EC2 Auto Scaling</a><a href=”https://docs.aws.amazon.com/config/latest/developerguide/config-VPC-endpoints.html”>Config</a><a href=”https://docs.aws.amazon.com/efs/latest/ug/efs-vpc-endpoints.html”>EFS</a><a href=”https://docs.aws.amazon.com/kms/latest/developerguide/kms-vpc-endpoint.html”>KMS</a> |
| AWS – Rotating Customer Master Keys | Cryptographic best practices discourage extensive reuse of encryption keys. To create new cryptographic material for your AWS Key Management Service (AWS KMS) customer master keys (CMKs), you can create new CMKs, and then change your applications or aliases to use the new CMKs. Or, you can enable automatic key rotation for an existing customer managed CMK.When you enable automatic key rotation for a customer managed CMK, AWS KMS generates new cryptographic material for the CMK every year. AWS KMS also saves the CMK’s older cryptographic material in perpetuity so it can be used to decrypt data that it encrypted. AWS KMS does not delete any rotated key material until you delete the CMK.Key rotation changes only the CMK’s backing key, which is the cryptographic material that is used in encryption operations. Automatic key rotation has the following benefits:The properties of the CMK, including its key ID, key ARN, region, policies, and permissions, do not change when the key is rotated.You do not need to change applications or aliases that refer to the CMK ID or ARN.After you enable key rotation, AWS KMS rotates the CMK automatically every year. You don’t need to remember or schedule the update.However, automatic key rotation has no effect on the data that the CMK protects. It does not rotate the data keys that the CMK generated or re-encrypt any data protected by the CMK, and it will not mitigate the effect of a compromised data key.Enabling and Disabling Key Rotation (Console)Sign in to the AWS Management Console and open the AWS Key Management Service (AWS KMS) console at <a href=”https://console.aws.amazon.com/kms.”>https://console.aws.amazon.com/kms.</a>To change the AWS Region, use the Region selector in the upper-right corner of the page.In the navigation pane, choose Customer managed keys. (You cannot enable or disable rotation of AWS managed keys. They are automatically rotated every three years.)Choose the alias or key ID of a CMK.Choose the Key rotation tab.The Key rotation tab only appears on the detail page of symmetric CMKs with key material that AWS KMS generated (the Origin is AWS_KMS). You cannot automatically rotate asymmetric CMKs, CMKs with imported key material, or CMKs in custom key stores. However, you can rotate them manually.Select or clear the Automatically rotate this CMK every year check box. If a CMK is disabled or pending deletion, the Automatically rotate this CMK every year check box is cleared, and you cannot change it. The key rotation status is restored when you enable the CMK or cancel deletion. For details, see How Automatic Key Rotation Works and How Key State Affects Use of a Customer Master Key.Choose Save.Resource:<a href=”https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html”>Rotating CMKs</a> |
| AWS – Use key policies in AWS KMS | Key policies are the primary way to control access to customer master keys (CMKs) in AWS KMS. They are not the only way to control access, but you cannot control access without them. A key policy is a document that uses JSON (JavaScript Object Notation) to specify permissions. You can work with these JSON documents directly, or you can use the AWS Management Console A key policy document cannot exceed 32 KB (32,768 bytes). Key policy documents use the same JSON syntax as other permissions policies in AWS and have the following basic structure:{ “Version”: “2012-10-17”, “Statement”: [{ “Sid”: “statement identifier”, “Effect”: “effect”, “Principal”: “principal”, “Action”: “action”, “Resource”: “resource”, “Condition”: {“condition operator”: {“condition context key”: “context key value”}} }]}Key policies are the primary way to control access to CMKs. For more information on key policies, see Using Key Policies in AWS KMS in the AWS Key Management Service Developer Guide.The following list describes all the AWS KMS-related permissions supported by Amazon FSx for encrypted at rest file systems:kms:Encrypt – (Optional) Encrypts plaintext into ciphertext. This permission is included in the default key policy.kms:Decrypt – (Required) Decrypts ciphertext. Ciphertext is plaintext that has been previously encrypted. This permission is included in the default key policy.kms:ReEncrypt – (Optional) Encrypts data on the server side with a new customer master key (CMK), without exposing the plaintext of the data on the client side. The data is first decrypted and then re-encrypted. This permission is included in the default key policy.kms:GenerateDataKeyWithoutPlaintext – (Required) Returns a data encryption key encrypted under a CMK. This permission is included in the default key policy under kms:GenerateDataKey*.kms:CreateGrant – (Required) Adds a grant to a key to specify who can use the key and under what conditions. Grants are alternate permission mechanisms to key policies. For more information on grants, see Using Grants in the AWS Key Management Service Developer Guide. This permission is included in the default key policy.kms:DescribeKey – (Required) Provides detailed information about the specified customer master key. This permission is included in the default key policy.kms:ListAliases – (Optional) Lists all of the key aliases in the account. When you use the console to create an encrypted file system, this permission populates the Select KMS master key list. We recommend using this permission to provide the best user experience. This permission is included in the default key policy.Resources:<a href=”https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html”>Using key policies in AWS KMS</a>FSx: <a href=”https://docs.aws.amazon.com/fsx/latest/WindowsGuide/encryption-at-rest.html”>Encryption at Rest</a><a href=”https://docs.aws.amazon.com/fsx/latest/WindowsGuide/encryption-at-rest.html”></a>CodeBuild: <a href=”https://docs.aws.amazon.com/codebuild/latest/userguide/setting-up.html#setting-up-kms”>Create and configure an AWS KMS CMK for CodeBuild</a> |
AWS- ALB
| AWS – Enable Access Logs | Access LogsElastic Load Balancing provides access logs that capture detailed information about requests sent to your load balancer. Each log contains information such as the time the request was received, the client’s IP address, latencies, request paths, and server responses. You can use these access logs to analyze traffic patterns and to troubleshoot issues.Implement the steps discussed belowTo enable access logging using the consoleStep 1: Create an S3 BucketStep 2: Attach a Policy to Your S3 Bucket.Step 3: Enable Access LogsStep 4: Verify that the Load Balancer Created a Test File in the S3 BucketCloudfront Access Logs: Server access logs provide detailed records about requests that are made to a distribution. Server access logs are useful for many applications. For example, access log information can be useful in security and access audits.The below links provide guidance on enabling logs for individual services:<a href=”https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/access-log-collection.html”>ELB Access Logs</a><a href=”https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html#access-log-file-format”>ELB</a><a href=”https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/logging-and-monitoring.html”>Cloudfront Access Logs</a><a href=”https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/query-logs.html”>Route53</a><a href=”https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/logging-using-cloudtrail.html”>DynamoDB</a><a href=”https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/logging-using-cloudtrail.html”>RDS</a><a href=”https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/AWSHowTo.cloudtrail.html”>Elastic Beanstalk</a><a href=”https://docs.aws.amazon.com/athena/latest/ug/monitor-with-cloudtrail.html”></a><a href=”https://docs.aws.amazon.com/athena/latest/ug/monitor-with-cloudtrail.html”>Athena</a> |
| AWS – Ensure communication to global resources is only through VPC endpoints or Privatelink | A VPC endpoint enables you to privately connect your VPC to supported AWS services and VPC endpoint services powered by PrivateLink without requiring an internet gateway, NAT device, VPN connection, or AWS Direct Connect connection. Instances in your VPC do not require public IP addresses to communicate with resources in the service. Traffic between your VPC and the other service does not leave the Amazon network. Endpoints are virtual devices. They are horizontally scaled, redundant, and highly available VPC components that allow communication between instances in your VPC and services without imposing availability risks or bandwidth constraints on your network traffic. There are two types of VPC endpoints: interface endpoints and gateway endpoints. Steps to Implement:To create an interface endpoint to an AWS service using the consoleOpen the Amazon VPC console at <a href=”https://console.aws.amazon.com/vpc/”>https://console.aws.amazon.com/vpc/</a><a href=”https://console.aws.amazon.com/vpc/”></a>In the navigation pane, choose Endpoints, Create Endpoint.For the Service category, ensure that AWS services are selectedFor Service Name, choose the service to which to connect. For Type, ensure that it indicates InterfaceComplete the following information and then choose Create endpoint: VPC: Select VPC in which to create the endpoint; Subnets: select the subnets (Availability Zones) in which to create the endpoint network interfaces; DNS: To enable private DNS for the interface endpoint, for Enable Private DNS Name, select the check box; Security group: select the security groups to associate with the endpoint network interfaces; Tags: (Optional) add any tags.Resources:<a href=”https://docs.aws.amazon.com/AmazonS3/latest/dev/security-best-practices.html#end-points”>S3 Bucket</a> <a href=”https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-and-interface-VPC.html”>Cloudwatch</a> <a href=”https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/load-balancer-vpc-endpoints.html”>ELB </a><a href=”https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/vpc-endpoints-dynamodb-tutorial.html”>DynamoDB</a> <a href=”https://docs.aws.amazon.com/AmazonECS/latest/developerguide/vpc-endpoints.html”>ECS</a> <a href=”https://docs.aws.amazon.com/amazonglacier/latest/dev/network-isolation.html”>Glacier </a><a href=”https://docs.aws.amazon.com/sns/latest/dg/sns-vpc-create-endpoint.html”>SNS</a> <a href=”https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-security-best-practices.html#consider-using-vpc-endpoints-access-sqs”>SQS</a> <a href=”https://docs.aws.amazon.com/athena/latest/ug/interface-vpc-endpoint.html”>Athena </a><a href=”https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html”>ECR</a><a href=”https://docs.aws.amazon.com/emr/latest/ManagementGuide/interface-vpc-endpoint.html”>EMR</a> <a href=”https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/vpc.html”>Elastic Beanstalk</a> <a href=”https://docs.aws.amazon.com/codebuild/latest/userguide/security-traffic-privacy.html”>CodeBuild </a><a href=”https://docs.aws.amazon.com/sagemaker/latest/dg/interface-vpc-endpoint.html”>SageMaker</a><a href=”https://docs.aws.amazon.com/datasync/latest/userguide/datasync-in-vpc.html”>DataSync</a><a href=”https://docs.aws.amazon.com/app-mesh/latest/userguide/vpc-endpoints.html”>App Mesh</a> <a href=”https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-internetwork-traffic-privacy.html”>SQS</a><a href=”https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-vpc-endpoints.html”>AWS EC2 Auto Scaling</a><a href=”https://docs.aws.amazon.com/config/latest/developerguide/config-VPC-endpoints.html”>Config</a><a href=”https://docs.aws.amazon.com/efs/latest/ug/efs-vpc-endpoints.html”>EFS</a><a href=”https://docs.aws.amazon.com/kms/latest/developerguide/kms-vpc-endpoint.html”>KMS</a> |
| AWS – Configure the security groups for your load balancers | Configure the security groups for your Application Load Balancers and Classic Load Balancers to accept traffic only from specific clients. These security groups must allow inbound traffic from clients on the listener ports and outbound traffic to the clients.A security group acts as a virtual stateful firewall that controls the traffic for one or more instances.When you launch an instance, you associate one or more security groups with the instance.You add rules to each security group that allows traffic to or from its associated instances.You can modify the rules for a security group at any time; the new rules are automatically applied to all instances that are associated with the security group after a short period. Note: security groups are more effective at restricting/regulating network traffic than NACLs (Network Access Control Lists)Resource:<a href=”https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/infrastructure-security.html”>Infrastructure Security for Load Balancing</a><a href=”https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html”>https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html</a> |
| AWS – Use AWS WAF to allow or block requests based on the rules in a web access control list | A web access control list (web ACL) gives you fine-grained control over the web requests that your Amazon CloudFront distribution, Amazon API Gateway API, or Application Load Balancer responds to. You can use criteria like the following to allow or block requests: IP address origin of the request Country of origin of the request String match or regular expression (regex) match in a part of the request Size of a particular part of the request Detection of malicious SQL code or scripting.When you make changes to web ACLs or web ACL components, like rules and rule groups, AWS WAF propagates the changes everywhere that the web ACL and its components are stored and used. Your changes are applied within seconds, but there might be a brief period of inconsistency when the changes have arrived in some places and not in others. So, for example, if you add an IP address to an IP set that’s referenced by a blocking rule in a web ACL, the new address might briefly be blocked in one area while still allowed in another. This temporary inconsistency can occur when you first associate a web ACL with an AWS resource and when you change a web ACL that is already associated with a resource. Generally, any inconsistencies of this type last only a few seconds. Working with Web ACLs To create a web ACL 1. Sign in to the AWS Management Console and open the AWS WAF console at <a href=”https://console.aws.amazon.com/wafv2/”>https://console.aws.amazon.com/wafv2/</a>. 2. Choose Web ACLs in the navigation pane, and then choose Create web ACL. 3. For Name, enter the name that you want to use to identify this web ACL. Note: You can’t change the name after you create the web ACL. 4. (Optional) For Description – optional, enter a longer description for the web ACL if you want to. 5. For CloudWatch metric name, change the default name if applicable. Follow the guidance on the console for valid characters. The name can’t contain special characters, white space, or metric names reserved for AWS WAF, including “All” and “Default_Action.” Note: You can’t change the CloudWatch metric name after you create the web ACL. 6. For Resource type, choose the category of AWS resource that you want to associate with this web ACL. For more information, see Associating or disassociating a Web ACL with an AWS resource. 7. For Region, if you’ve chosen a regional resource type, choose the Region where you want AWS WAF to store the web ACL. – You only need to choose this option for regional resource types. For CloudFront distributions, the region is hardcoded to the US East (N. Virginia) Region, us-east-1, for Global (CloudFront) applications. 8. For Associated AWS resources – optional, choose Add AWS resources. In the dialog box, choose the resources that you want to associate, and then choose Add. AWS WAF returns you to the Describe web ACL and associated AWS resources page. 9. Choose Next. 10. (Optional) If you want to add managed rule groups, on the Add rules and rule groups page, choose Add rules, and then choose Add managed rule groups. Do the following for each managed rule group that you want to add: 10a. On the Add managed rule groups page, expand the listing for AWS managed rule groups or for the AWS Marketplace seller of your choice. 10b. For the rule group that you want to add, turn on the Add to web ACL toggle in the Action column. 10c. If you want to set the action for all rules in the rule group to count only, turn on the Set rule’s action to count toggle. For information about this option, see Overriding the actions of an entire rule group. 10d. Choose Add rules to finish adding managed rules and return to the Add rules and rule groups page. 11. (Optional) If you want to add your own rule group, on the Add rules and rule groups page, choose Add rules, and then choose Add my own rules and rule groups. Do the following for each rule group that you want to add: 11a. On the Add my own rules and rule groups page, choose Rule group. 11b. Choose your rule group from the list. If you want to override the rule actions for the group, turn on the Set rule’s action to count toggle. For information about this option, see Overriding the actions of an entire rule group. 12. (Optional) If you want to add your own rule, on the Add rules and rule groups page, choose Add rules, Add my own rules and rule groups, Rule builder, then Rule visual editor. Note: The console Rule visual editor supports one level of nesting. For example, you can use a single logical AND or OR statement and nest one level of other statements inside it, but you can’t nest logical statements within logical statements. To manage more complex rule statements, use the Rule JSON editor. For information about all options for rules, see AWS WAF rules. This procedure covers the Rule visual editor. 12a. For Name, enter the name that you want to use to identify this rule. 12b. Enter your rule definition, according to your needs. You can combine rules inside logical AND and OR rule statements. The wizard guides you through the options for each rule, according to context. For information about your rules options, see AWS WAF rules. 12c. For Action, select the action you want the rule to take when it matches a web request. For information on your choices, see AWS WAF rule action and How AWS WAF processes a Web ACL. 12d. Choose Add rule. 13. Choose the default action for the web ACL. This is the action that AWS WAF takes when a web request doesn’t match any of the rules in the web ACL. For more information, see Deciding on the default action for a Web ACL. 14. Choose Next. 15. In the Set rule priority page, select and move your rules and rule groups to the order that you want AWS WAF to process them. For more information, see How AWS WAF processes a Web ACL. 16. Choose Next. 17. In the Configure metrics page, deselect anything you don’t want metrics for, and update names as needed. You can combine metrics from multiple sources by providing the same CloudWatch metric name. 18. Choose Next. 19. In the Review and create web ACL page, check over your definitions. If you want to change any area, choose Edit for the area. This returns you to the page in the web ACL wizard. Make any changes, then choose Next through the pages until you come back to the Review and create a web ACL page. 20. Choose Create web ACL. Your new web ACL is listed on the Web ACLs page. Reference: <a href=”https://docs.aws.amazon.com/waf/latest/developerguide/web-acl-creating.html”>https://docs.aws.amazon.com/waf/latest/developerguide/web-acl-creating.html</a><a href=”https://docs.aws.amazon.com/waf/latest/developerguide/web-acl-creating.html”></a> <a href=”https://docs.aws.amazon.com/waf/latest/developerguide/web-acl-editing.html”>https://docs.aws.amazon.com/waf/latest/developerguide/web-acl-editing.html</a> |
| AWS – Configure an Application Load Balancer to securely authenticate users as they access your applications | You can configure an Application Load Balancer to securely authenticate users as they access your applications. This enables you to offload the work of authenticating users to your load balancer so that your applications can focus on their business logic.The following use cases are supported:Authenticate users through an identity provider (IdP) that is OpenID Connect (OIDC) compliant.Authenticate users through well-known social IdPs, such as Amazon, Facebook, or Google, through the user pools supported by Amazon Cognito.Authenticate users through corporate identities, using SAML, LDAP, or Microsoft AD, through the user pools supported by Amazon Cognito.Resource:<a href=”https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-authenticate-users.html”>Authenticate Users Using an Application Load Balancer</a> |