Skip to main content
Skyhigh Security

Policy Templates for AWS

This table lists the Policy Templates provided for use with AWS.  

For Policy Templates for Amazon ECS, EKS, Google Kubernetes Engine (GKE), and Azure Kubernetes Services (AKS), and AWS Fargate, see Policy Templates for Container Security

For response actions, see Auto-Remediation of AWS Incidents

For instructions on how to find Policy templates that are new or updated due to changed recommendations, see Find New and Updated Policy Templates

Policy Name

Resource/
Entity Type

Skyhigh CASB Recommended

CIS v1.2.0   Level 1

CIS v1.2.0  Level 2

CIS v1.3.0 Level 1

CIS v1.3.0 Level 2

CIS v1.4.0 Level 1 CIS
v1.4.0
Level 2

PCI DSS  v3.2

HIPAA

NIST 800-53 Rev4 

Policy Description

IAM user should have only one active access key User           1.13     164.308(a)(4)   Access keys are long-term credentials for an IAM user or the AWS account 'root' user. You can use access keys to sign programmatic requests to the AWS CLI or AWS API. One of the best ways to protect your account is to not allow users to have multiple access keys. 
AWS IAM should not have expired SSL/TLS certificates AWS IAM Server Certificate           1.19   4.1.1, 4.2 164.308(a)(3)   Removing expired SSL/TLS certificates eliminates the risk that an invalid certificate will be deployed accidentally to a resource such as AWS Elastic Load Balancer (ELB), which can damage the credibility of the application/website behind the ELB. As a best practice, it is recommended to delete expired certificates.
IAM Access Analyzer should be enabled in all region AWS Region           1.20         AWS IAM Access Analyzer helps you identify the resources in your organization and accounts, such as Amazon S3 buckets or IAM roles, that are shared with an external entity. 
S3 Bucket Policy should deny HTTP Request S3                     By default, Amazon S3 allows both HTTP and HTTPS requests. To achieve only allowing access to Amazon S3 objects through HTTPS you also have to explicitly deny access to HTTP requests. 
Network ACLs should not have unrestricted SSH access AWS Network Acl           5.1   1.2.1, 1.1.6, 1.3.4, 1.3.5 164.312(e)(1)   Public access to remote server administration port 22, increases the resource attack surface and unnecessarily raises the risk of resource compromise.
Network ACLs should not have unrestricted Remote Desktop access AWS Network Acl           5.1   1.2.1, 1.1.6, 1.3.4, 1.3.5 164.312(e)(1)   Public access to remote server administration port 3389, increases the resource attack surface and unnecessarily raises the risk of resource compromise. 
Default Security Group of every VPC should restrict all traffic Security Group           5.3   1.2.1, 1.1.6, 1.3.4, 1.3.5 164.312(e)(1)   Configuring all VPC default security groups to restrict all traffic will encourage least privilege security group development and mindful placement of AWS resources into security groups which will in-turn reduce the exposure of those resources. 
Root account access key should not exist IAM Level 1 1.12   1.4         164.312(a)(2)(i), 164.312(e)(1)   Using access keys with the root account is a direct vector of account compromise. Anyone who gets access to the key has access to all the services in the AWS account. Creating role based accounts with appropriate privileges and access keys is the recommended best practice.
CloudTrail trails should be integrated with CloudWatch logs CloudTrail Level 1 2.4   3.4         164.312(e)(1)   With this integration, real-time and historic activity logging based on user, API, resource, and IP address is facilitated. It also enables an opportunity to establish alarms and notifications for anomalous or sensitive account activity.
CloudTrail logging should be enabled for the account CloudTrail               10.2 164.308(a)(1)(ii)(D), 164.312(a)(2)(i), 164.312(c)(2)   CloudTrail provides a history of AWS API calls for an account, including API calls made via the Management Console, SDKs, command line tools, and higher-level AWS services (such as CloudFormation). This enables security analysis, resource change tracking, and compliance auditing.
CloudTrail logging should be enabled for multi-regions CloudTrail Level 1 2.1   3.1         164.312(b)   CloudTrail provides a history of AWS API calls for an account, including API calls made via the Management Console, SDKs, command line tools, and higher-level AWS services (such as CloudFormation). This enables security analysis, resource change tracking, and compliance auditing. Additionally, ensuring that a multi-regions trail exists will ensure that unexpected activity occurring in otherwise unused regions is detected.
EC2 instance should belong to a VPC EC2               1.1.7, 1.2, 1.3, 2.4, 1.1.4     Checks whether your EC2 instances belong to a Virtual Private Cloud (VPC) which is logically isolated to your AWS account. This allows controlling the outbound traffic from your instances (egress filtering) in addition to controlling the inbound traffic to them (ingress filtering). It also allows to add an additional layer of access control to your instances in the form of network access control lists (ACL).
Hardware MFA should be enabled for the root account IAM Level 1   1.14   1.6           Secure access to your AWS resources by ensuring hardware MFA is enabled for your root account. A hardware MFA has a negligible attack surface and cannot be hacked unless the malicious user gain physical access to the hardware device.
MFA Delete should be enabled on S3 buckets S3               8.3     Ensure that your S3 buckets are using MFA Delete feature which requires additional authentication for either versioning change of bucket or permanent deletion of an object version operations.
MFA should be enabled for root account IAM Level 1 1.13   1.5         164.312(e)(1)   Enabling MFA for the root account provides increased security for console access as it requires the authenticating principal to possess a device that emits a time-sensitive key and have knowledge of a credential.
IAM instance roles should be used to provision access to AWS resources EC2 Level 1   1.19   1.18           Provisioning access to resources using IAM roles is recommended versus providing individual set of credentials to access. This ensures that credentials are not lost or misplaced accidentally, leading to account compromise.
The S3 bucket used to store CloudTrail logs should not be publicly accessible CloudTrail Level 1 2.3   3.3       10.2.3, 10.5.2, 1.2.1     Risk of unauthorized access or account compromise increases with unrestricted access to CloudTrail logs.
Non HTTP/HTTPS ports should not have unrestricted access EC2               1.1.7, 1.2, 1.3, 1.2.1     Ensure that only ports 80 and 443 can be accessed publicly. Unrestricted access could lead to unauthorized access to data or lead to an accidental breach.
Security Groups should not have unrestricted CIFS access EC2 Level 2             1.2.1     If you are using DNS, ensure that access through port 53 is restricted to required entities only.
Security Groups should not have unrestricted DNS access EC2 Level 2             1.2.1     If you are using DNS, ensure that access through port 53 is restricted to required entities only.
Security Groups should not have unrestricted FTP access EC2 Level 2             1.2.1     Ensure that access through port 20/21 (FTP) is restricted to required entities only. FTP is a commonly used protocol for sharing data. Unrestricted access could lead to unauthorized access to data or lead to an accidental breach.
Security Groups should not have unrestricted ICMP access EC2 Level 2             1.2.1     Ensure that access for ICMP is restricted to required entities only. Unrestricted access could lead to unauthorized access to data as attackers could use ICMP to test for network vulnerabilities or employ DDOS against your infrastructure.
Security Groups should not have unrestricted inbound access on uncommon ports  EC2 Best Practice             1.2.1     Allowing unrestricted inbound access to uncommon ports can increase opportunities for malicious activity such as hacking, data loss and all multiple types of attacks (brute-force attacks, Denial of Service (DoS) attacks, etc).
Security Groups should not have unrestricted MySQL access EC2 Level 2             1.2.1     If you are using MySQL, ensure that access through port 3306, used for MySQL, is restricted to required entities only.
Security Groups should not have unrestricted NetBIOS access EC2 Level 2             1.2.1     If you are using NetBIOS, ensure that access through port 139 (TCP) and 137/138 (UDP) are restricted to required entities only.
Security Groups should not have unrestricted outbound access EC2 Level 2             1.2.1     Outbound access from ports must be restricted to required entities only such as specific ports or specific destinations.
Security Groups should not have unrestricted Remote Desktop access EC2 Level 1 4.2   5.2       1.2.1, 1.1.6, 1.3.4, 1.3.5 164.312(e)(1)   If you are using Remote Desktop, ensure that access through port 3389, used for Remote Desktop, is restricted to required entities only.
Security Groups should not have unrestricted RPC access EC2 Level 2             1.2.1     If you are using RPC, ensure that access through port 135, used for RPC, is restricted to required entities only.
Security Groups should not have unrestricted SMTP access EC2 Level 2             1.2.1     If you are using SMTP, ensure that access through port 25, used for SMTP, is restricted to required entities only. Unrestricted SMTP access can be misused to spam your enterprise, DDOS, etc.
Security Groups should not have unrestricted SSH access EC2 Level 1 4.1   5.2       1.2.1, 1.1.6, 1.3.4, 1.3.5 164.312(e)(1)   If you are using SSH, ensure that access through port 22, used for SSH, is restricted to required entities only.
Security Groups should not have unrestricted Telnet access EC2 Level 2             1.2.1     If you are using Telnet, ensure that access through port 23, used for Telnet, is restricted to required entities only.
EC2 instance should not use default security group EC2               1.1.7     Default Security Group allows all inbound traffic from other instances associated with the default security group. It also allows all outbound traffic from the instance.
S3 buckets should not be world readable S3 Best Practice               164.312(a)(1), 164.308(a)(4)(i), 164.308(a)(4)(i)   Risk of unauthorized access or loss of customer data increases with an S3 bucket that grants READ (LIST), READ_ACP (VIEW PERMISSIONS) access to everyone or AWS signed users. Malicious users can exploit the information acquired through the listing process to find objects with misconfigured Access Control Lists (ACLs) permissions and access these compromised objects. This is a Skyhigh recommended best practice.
Resources should always be tagged All Best Practice                   A tag is a label that you assign to a resource. Each tag consists of a key and an optional value, both of which you define. Tags enable you to categorize your resources in different ways, for example, by purpose, owner, or environment. Ensure that user-defined tags (metadata) are being used for labelling, collecting and organizing resources available within your environment.
KMS keys should not be scheduled for deletion KMS Best Practice                   Deleting a Key Management Service (KMS) CMK prevents all associated encrypted data from later being decrypted. Disabling, rather than deleting, a KMS/CMK allows users with access to the key to re-enable it and recover encrypted data in the future..
CloudFront Distribution should use secure ciphers CloudFront Best Practice             4.1, 2.3, 2.2.3 164.312(a)(2)(iv), 164.312 (e)(1), 164.312(e)(2)(ii)   CloudFront, a content delivery network (CDN) offered by AWS, is not using a secure cipher for distribution. It is a best security practice to enforce the use of secure ciphers TLSv1.1 and TLSv1.2 in a CloudFront Distributions certificate configuration. This policy scans for any deviations from this practice.
AWS account should not have single IAM admin IAM Best Practice                   IAM Administrator roles should never reside on only one individual's IAM account. The risk of that individual losing access to those credentials, through a variety of possibilities, creates undue risk for an organization.There should be at least two IAM Admins configured to prevent a Single-Point-of-Failure (SPoF)
SQS should not have cross account access SQS Best Practice                   Recommended best practice is for SQS queues to not support cross-account access if the list account IDs are on another account or if the access is exposed to everyone. This policy scans any violation to this.
Lifecycle configuration should be applied to S3 buckets S3               3.1     Checks if lifecycle configuration is applied to S3 buckets which allows you to manage your objects so that they are stored cost effectively. These rules define ‚ÄòTransition‚Äô or ‚ÄòExpiration‚Äô actions that Amazon S3 applies to a group of objects.
Access Logging should be enabled for ELB ELB Best Practice               164.308(a)(1)(ii)(D), 164.312(c)(2), 164.312(e)(1), 164.312(b) AU-2a, AU-8a, AU-8b Enabling ELB access logging will allow ELB to record and save information about each TCP and HTTP request made. The access logging data can be extremely useful for security audits and troubleshooting sessions. For example your ELB logging data can be used to analyze traffic patterns in order to detect different types of attacks and help implementing custom protection plans.
IAM policies should be attached to groups and roles only IAM Level 1 1.16   1.15             IAM Policies are recommended to be associated with groups or roles only. This prevents the risk for users to get excessive permissions or privileges accidentally, in large enterprise deployments.
Access keys should not be unused  IAM Best Practice             8.1.4     Unused access keys minimize the risk aperture of an enterprise to a compromised account or Insider threat. It is highly recommended that any access keys unused for over 30 days be terminated.
AWS account should not have unused IAM users IAM Level 1 1.3   1.12             Removing unused IAM users can reduce the risk of unauthorized access to your AWS resources, help you manage the user-based access to the AWS Management Console more efficiently and is a recommended best practice.
AWS account should not have unused SSH public keys EC2 Best Practice                   Lower the risk of unauthorized access to your data using SSH from unrestricted locations by deleting unused SSH Public Keys.
Last restorable time should be configured for RDS RDS Best Practice                   The Amazon RDS automated backup feature automatically creates a storage volume snapshot of your DB instance, backing up the entire DB instance and not just individual databases.You can restore to any point in time during your backup retention period. The latest restorable time for a DB instance should be typically within 5 minutes of the current time..
Backup retention period for RDS should be sufficient RDS               3.1     Longer backup retention periods might be required for compliance purposes. If the maximum retention period for automated backups is greater, it enables you to store more and hence recover your database to any point in time during the backup retention period.
CloudTrail log file validation should be enabled CloudTrail     2.2   3.2     10.5.5 164.312(b)   Validated log files are invaluable in security and forensic investigations. Determine whether a log file was modified, deleted, or unchanged after CloudTrail delivered it.
AWS CloudFront CDN should be used CloudFront Best Practice                   The AWS account is not currently leveraging any CloudFront distributions. CloudFront provides scalable, distributed, and inexpensive Content Distribution Network (CDN) within AWS. Using a content delivery network (CDN) can provide a layer of security between your origin content and its destination. CDNs can ensure consistent delivery of content during a distributed denial of service (DDoS) attack or unexpected increase in traffic volume by providing you time to scale infrastructure to meet traffic demands or helping to identify the origin and mitigate the risk of an attack.
AWS Config should be enabled in all regions AWS Account   2.5   3.5       2.2     The AWS Config service provides visibility to user configuration history and configuration change notifications. Along with use of CloudTrail, we consider enabling AWS Config to be a best practice for users.
AWS DNS service should not be used AWS Account Best Practice                   Using DNS resolution on VPC gives Amazon provided host names to all the instances behind it. Turn this OFF if that is not desired and specific host names are needed
EC2 instances should not reach regional limit for elastic IP addresses  AWS Account Best Practice                   The EC2 instance is nearing the regional limit for allowed elastic IP addresses.
RDS event notification subscription should be enabled RDS Best Practice                   An Amazon RDS event notification subscription can be created to be notified when an event occurs for a given DB instance. This policy checks to see if RDS event subscription DB instance sourcetype is enabled and active.
Object versioning should be enabled for S3 buckets S3 Best Practice               164.312(c)(1), 164.312(c)(2) SC-28 Verify if object versioning is enabled on your S3 buckets.
Access logging should be enabled on the CloudTrail S3 bucket  CloudTrail Level 1 2.6   3.6       10.2.3 164.312(e)(1) 164.312(b),164.312(c)(2) AC-2g CloudTrail buckets contain sensitive information. These should be protected from unauthorized viewing. With S3 Server Access Logging enabled for your CloudTrail buckets, you can track any requests made to access the buckets or even limit who can alter or delete the access logs to prevent a user from covering their tracks. S3 Bucket Access Logging generates a log that contains access records for each request made to your CloudTrail S3 bucket.
CloudTrail logs should be encrypted at rest CloudTrail Level 1   2.7   3.7         SC-28 Ensure that CloudTrail logs are encrypted at Rest to minimize the risk of unauthorized access.
CloudTrail logs should be encrypted with CMKs CloudTrail Level 2   2.7   3.7     2.7, 3.5 164.312(e)(1)   Ensure that CloudTrail logs are encrypted with Customer Master Key (CMK) to minimize the risk of unauthorized access.
RDS should be encrypted RDS Best Practice             3.4 164.312(a)(2)(iv), 164.312 (e)(1), 164.312(e)(2)(ii) SC-28,SC-13 To be compliant with data at rest encryption policies, ensure that your database is being encrypted.
EBS should be encrypted EBS Best Practice     2.2.1 2.2.1     3.4     To be compliant with data at rest encryption policies, ensure that your data volumes and snapshots are being encrypted.
EC2 security group should have inbound access configured to specific IP addresses EC2 Best Practice                   Ensure that excessive permissions to access EC2 instances is not specified, such as using RFC 1918 to whitelist large ranges of IP Addresses. Only specific Private IP Addresses must have inbound access.
EC2 security group should have specific ports configured EC2 Best Practice                   Ensure that ranges of ports are not open on your EC2 security groups. Leaving large ranges of ports open leads to vulnerabilities potentially being exposed. In addition, attackers can scan ports and expose vulnerabilities of applications hosted without easy traceability due to large port ranges being open.
CloudFront Distribution should use HTTPS protocol CloudFront Best Practice             4.1 164.312(a)(2)(iv), 164.312 (e)(1), 164.312(e)(2)(i), 164.312(e)(2)(ii)   If you are using CloudFront, ensure that CloudFront distributions use HTTPS. This ensures all traffic to and from CloudFront is encrypted and minimizes the risk of MITM.
IAM access keys should be rotated periodically IAM Best Practice 1.4   1.14         164.312(e)(1), 164.312(d)   Rotating AWS IAM access keys reduces the risk of compromised credentials or malicious insiders using stale credentials to exfiltrate or misuse sensitive data.
IAM users should not have multi-mode access IAM Best Practice                   IAM users must be enabled for either API Access or for Console Access to reduce the risk of unauthorized access in case their credentials (access keys or passwords) are compromised. Application users should use only access keys to programmatically access data in AWS and administrators who need console access should use only passwords to manage AWS resources.
Unused access keys should be disabled IAM Level 1 1.4   1.14             Removing unused AWS IAM credentials can significantly reduce the risk of unauthorized access to your AWS resources. Access must not be enabled to resources for IAM users who have left the organization or applications tools that are no longer using these resources.
Access for inactive IAM users should be disabled IAM   1.3   1.12       8.1.4 164.312(e)(1)   Disabling access for inactive IAM users can reduce the risk of unauthorized access to your AWS resources and helps you manage the user-based access more efficiently.
Rotation for customer created CMKs should be enabled KMS Best Practice   2.8   3.8       164.312(d), 164.312(e)(1)   Reduce the possibility that a compromised customer master key (CMK) could be used without your knowledge to access certain AWS resources. Enabling KMS Key Rotation will allow you to set a yearly rotation schedule for your CMK such that the KMS service can automatically use the latest version of the HSA Backing key to perform encryption.
MFA should be enabled for deleting CloudTrail bucket CloudTrail Best Practice                   Deleting the CloudTrail logs without authorization is the first step, after an account is compromised. Enabling MFA for deleting the CloudTrail bucket provides increased security to your CloudTrail logs.
MFA should be enabled for all IAM users that have a console password IAM Level 1 1.2   1.10       8.3     Multi-Factor Authentication (MFA) adds an extra layer of protection on top of a user name and password. It is recommended that MFA be enabled for all accounts that have a console password.
S3 buckets should not be publicly writable S3 Best Practice               164.312(a)(1), 164.308(a)(4)(i)   Risk of unauthorized access or loss of customer data increases with unrestricted access to S3 buckets
Password Policy should be strong IAM Level 1 1.5-1.11   1.8-1.9         164.312(d), 164.308(a)(5)(ii)(D)   Ensure that a password policy is specified for use with user accounts to minimize the risk of compromise. For example, a strong password policy requires atleast one uppercase, one lowercase, one symbol, one number, is atleast 14 characters long, prevents reuse of older passwords and expires periodically.
S3 buckets should not be unencrypted S3 Best Practice     2.1.1 2.1.1       164.312(a)(2)(iv), 164.312 (e)(1), 164.312(e)(2)(ii) SC-28,SC-13 The risk of sensitive data being compromised is significantly lower if a S3 bucket is encrypted.
AMIs should not have unrestricted access AMI Level 2             1.2.1, 2.2.4     Unrestricted access to AMIs makes these AMIs available in the Community AMIs where everyone with an AWS account can use them to launch EC2 instances. Most of the time, AMIs will contain snapshots of enterprise specific applications (including configuration and application data). Hence, unrestricted access to AMIs is not recommended.
RDS instances should not have unrestricted access RDS Best Practice             1.2.1 164.312(e)(1) 164.312(c)(1)   When the VPC security group associated with an RDS instance allows unrestricted access (0.0.0.0/0), entities on the Internet can establish a connection to your databases. This increases the risk for malicious activities such as brute force attacks, SQL injections or DoS/DDoS attacks.
S3 buckets should not have unrestricted access S3 Best Practice     1.20       1.2.1 164.312(a)(1), 164.308(a)(4)(i)   Risk of unauthorized access or loss of customer data increases with unrestricted access to S3 buckets.
Security Groups should not have unrestricted MongoDB access EC2 Level 2                   If you are using MongoDB, ensure that access through port 27017, used for MongoDB, is restricted to required entities only.
Security Groups should not have unrestricted MSSQL access EC2 Level 2                   If you are using MSSQL, ensure that access through port 1433, used for MSSQL, is restricted to required entities only.
Security Groups should not have unrestricted Oracle Database access EC2 Level 2                   If you are using Oracle DB, ensure that access through port 1521, used for Oracle DB, is restricted to required entities only.
Security Groups should not have unrestricted PostgreSQL access EC2 Level 2                   If you are using PostgreSQL, ensure that access through port 5432, used for PostgreSQL, is restricted to required entities only.
VPC flow logging should be enabled for all VPCs VPC Level 1   2.9   3.9       164.312(b), 164.312(e)(1)   VPC Flow Logs provide visibility into network traffic that traverses the VPC and can be used to detect anomalous traffic or insight during security workflows. Enabling it will detect security and access issues like overly permissive security groups, network ACLs and alert abnormal activities such as rejected connection requests or unusual levels of data transfer.
Default VPCs should not be used VPC Best Practice                   A default VPC is ready for use so that you dont have to create and configure your own VPC. It allows to immediately start launching Amazon EC2 instances into the default VPC which comes with a default Security Group that denies all inbound traffic but allows all outbound traffic. Default VPC in any unused region allows you to launch resources, and hence should be removed or reviewed and updated according to your requirements. A default VPC may be suitable for a small non-critical single tier application, but is not ideal for a robust production environment
AWS account should not reach limit for max subnets per VPC VPC Best Practice                   Detects when your account is approaching the maximum allowable number of subnets per Virtual Private Cloud (VPC)
AWS account should not reach configured limit for EC2 instances AWS Account Best Practice                   Detects if the account is near or at the limit of EC2 instances allowed by AWS
RDS DB should always be encrypted with Customer Managed KMS key RDS Best Practice                 SC-12 Customer-managed KMS keys should be used instead of AWS-managed keys in order to have more granular control over encrypting and encrypting data. Or, if you want full control, then you must create a customer-managed key and use the same for encryption.
Security Groups should not have unrestricted MSSQL Database (UDP) access EC2 Level 2             1.2.1     Check your EC2 security groups for inbound rules that allow unrestricted access to UDP port 1434 and restrict access to required IP addresses only. UDP port 1434 is used by the Microsoft SQL Server.
Security Groups should not have unrestricted PostgreSQL access EC2 Level 2             1.2.1     If you are using PostgreSQL, ensure that access through port 5432, used for PostgreSQL, is restricted to required entities only.
Security Groups should not have unrestricted VNC listener access EC2 Level 2             1.2.1     Check your EC2 security groups for inbound rules that allow unrestricted access to TCP port 5500 and restrict access to required IP addresses only. TCP port 5500 is used by the VNC Listener
Security Groups should not have unrestricted VNC Server access EC2 Level 2             1.2.1     Check your EC2 security groups for inbound rules that allow unrestricted access to TCP port 5900 and restrict access to required IP addresses only. TCP port 5900 is used by the VNC Server
Security groups should never remain unused Security Group Best Practice               164.312(e)(1) 164.312(c)(1)   Cleaning unused security groups eliminates the risk of a forgotten security group policy being used to accidentally open an attack surface. Delete those that you are certain are not being used or don‚Äôt belong to a default security group.
AWS account should not reach its configured limit for VPCs per region AWS Account Best Practice                   Detects if your account is near the limit of VPCs per Region. Increasing this limit increases the limit on internet gateways per region by the same amount. Usually, you can request an increase for these limits using the AWS Support Center
AWS account should not reach limit for security group in a VPC VPC Best Practice                   Detects if your account is near the EC2 Security Group Limit for your security group in a VPC
Access logging should be enabled for S3 bucket S3               10.2 164.312(e)(1), 164.312(b), 164.308(a)(1)(ii)(D), 164.312(a)(2)(i), 164.312(c)(2) AU-2a S3 Logging provides a way for you to get details about S3 bucket activity. By default, AWS does not enable logging for S3 buckets. This additional insight into bucket activity can be useful when troubleshooting and may be requested by AWS Support.
Customer Managed Keys should be used KMS Best Practice                   Customer managed key management service (KMS) keys are not in use. To provide more granular control of your data encryption, we recommend using customer-managed KMS keys instead of AWS managed KMS keys.
RDS cluster snapshot should not be publicly accessible RDS Best Practice                   If you set DB Snapshot Visibility to Public, all AWS accounts can restore a DB instance from your DB snapshot and have access to your data. Best practice is to not share any RDS Cluster Snapshots that contain private information as Public. This policy detects manual RDS Cluster Snapshots with Public Permissions.
RDS snapshot should not be publicly accessible RDS Best Practice                   If you set DB Snapshot Visibility to public, all AWS accounts can restore a DB instance from your DB snapshot and have access to your data. Best practice is to not share any DB snapshots that contain private information as Public. This policy detects manual RDS Snapshots that are marked as public.
Redshift cluster should be encrypted with Customer Managed KMS key Redshift               3.5 164.312(a)(2)(iv), 164.312 (e)(1), 164.312(e)(2)(ii)   The recommended best practice is for customer-managed KMS keys to be used instead of AWS-managed keys to have granular control over encrypting and encrypting data. Redshift clusters should be encrypted with a Customer-managed KMS key.
Redshift Cluster should not be publicly accessible Redshift Best Practice                   It is the recommended best practice that Redshift cluster nodes should not accessible to the public internet, outside of your VPC. This is dangerous, as Redshift databases should normally be privately accessible only from within your VPC. This policy scans for such incidents when one is discovered.
AMIs should not be unencrypted AMI Best Practice                   Instances that are not based on encrypted EBS root volumes pose a security threat due to potential data snooping. This policy scans for AMIs that are based on unencrypted root volume snapshots and returns an alert notifying you of any occurrences that fail this standard.
Redshift cluster should not be unencrypted Redshift               3.4     Database encryption is available for Redshift. It is recommended to create Redshift clusters with encryption turned on. Regulations and Compliance such as PCI DSS, SOX and HIPAA generally require encryption of Redshift clusters.
AWS account should not reach VPC Private Gateway regional limit VPC Best Practice                   Detects if your account is near the private gateway limitation per VPC per Region
Custom IAM policy should grant least privileges IAM Level 1 1.22   1.16       1.24, 7.1.1, 1.22, 2.2.4 164.308(a)(4)(i)   IAM policies are the means by which privileges are granted to users, groups, or roles. It is recommended and considered a standard security advice to grant the least privilege‚Äîthat is, granting only the permissions required to perform a task
Default access keys should not be unused  IAM Best Practice                   When a new IAM user is created, it generates an API access key for the user by default. This detects any unused default access keys in the account
EBS volumes should have recent snapshot  EBS Best Practice                   Elastic Block Store (EBS) volumes have no snapshots in recent history per the configured value specified in the policy. These are needed to retain critical system data, security logs, and system state. EBS volume snapshots are an important tool to record system state, security log data, and critical system data at various points in your EC2 instance lifecycle. Snapshots provide point-in-time recovery and review capability that is necessary for many operational and security practices.
EBS volumes should always be attached to EC2 instances EBS               3.5     One or more EBS volumes appear to not be attached to an EC2 instance. EBS volumes often persist after an EC2 instance has been terminated. We recommend regular review of these volumes, since they can contain sensitive data related to your company, application, infrastructure, or even users.
At least one IAM group/role should be assigned to the policy AWSSupportAccess IAM   1.20   1.17             The best security practice is to assign the least privilege available for access control to a user's role to manage Incidents with AWS Support. This policy scans to ensure that at least one policy group or policy role is assigned to AWSSupportAccess
NAT gateway should be used VPC Best Practice                   Use a network address translation (NAT) gateway to enable instances in a private subnet to connect to the internet or other AWS services, but prevent the internet from initiating a connection with those instances. AWS recommends to use NAT gateways, as they provide better availability and bandwidth over NAT instances
SNS should not support cross account access SNS Best Practice                   Recommended best practice is for SNS queues to not support cross-account access if the list account IDs are on another account or if the access is exposed to everyone. This policy scans any violation to this.
AWS account should not reach Customer gateway limit per region VPC Best Practice                   Detects if your account is near the VPC Customer Gateway limit per Region
AWS ELB listener should be secure ELB                     Check your Elastic Load Balancers (ELBs) listener for secure configurations. Skyhigh Security recommends using HTTPS or SSL protocols to encrypt the communication between the client and your load balancers.
AWS account should have IAM user IAM                     Ensure that the access to your AWS services and resources is made only through individual IAM users instead of the root account.
AWS Lambda Lambda                     Upload or Import AWS Lambda code using Skyhigh's custom policy to identify non-compliant services.

AWS resources should be tagged

                      Ensure that user-defined tags (metadata) are being used for labeling, collecting and organizing resources available within your AWS environment.
AWS Route 53 should have SPF DNS Records Route53                     Ensure your AWS Route 53 hosted zones have a TXT DNS record that contains a corresponding Sender Policy Framework (SPF) value set for each MX record available. The SPF record enables your Route 53 registered domains to publicly state which mail servers are authorized to send emails on its behalf.
EC2 instance should be configured to use Instance Metadata Service version 2 (IMDSv2) EC2                     AWS recommends adopting IMDS v2 and restricting access to v2 only for added security against open firewalls, reverse proxies and SSRF vulnerabilities. With IMDSv2, every request is now protected by session authentication.
EBS Snapshots should not be publicly accessible EBS                     Ensure that your AWS Elastic Block Store (EBS) volume snapshots are not public (i.e. publicly shared with other AWS accounts) in order to avoid exposing personal and sensitive data. Skyhigh strongly recommends against sharing your EBS snapshots with all AWS accounts. If required, you can share your volume snapshots with particular AWS accounts without making them publicly accessible
A daemon wide custom seccomp profile should be applied in ECS Fargate cluster FARGATE ECS Level 1                   You can choose to apply your custom seccomp profile at the daemon-wide level if needed and override Docker's default seccomp profile. 
A non-root user should be created for the container in ECS Fargate cluster FARGATE ECS Level 1                   Create a non-root user for the container in the Dockerfile for the container image. 
AWS account should not have unused IAM users IAM Level 1                   Removing unused IAM users can reduce the risk of unauthorized access to your AWS resources, help you manage the user-based access to the AWS Management Console more efficiently and is a recommended best practice.
Centralized and remote logging should be configured in ECS Fargate cluster FARGATE ECS Level 1                   Docker now supports various log drivers. A preferable way to store logs is the one that supports centralized and remote logging.
Container's file system should be mounted in read-only mode in ECS Fargate cluster FARGATE ECS Level 1                   The container's root file system should be treated as a 'golden image' and any writes to the root filesystem should be avoided. You should explicitly define a container volume for writing. 
Container CPU priority should be set appropriately in ECS Fargate cluster FARGATE ECS Level 1                   By default, all containers on a Docker host share the resources equally. By using the resource management capabilities of Docker host, such as CPU shares, you can control the host CPU resources that a container may consume. 
Container health should be checked at runtime in ECS Fargate cluster FARGATE ECS Level 1                   If the container image does not have an HEALTHCHECK instruction defined, use --health-cmd parameter at container runtime for checking container health. 
Container should be restricted from acquiring additional privileges in ECS Fargate cluster FARGATE ECS Level 1                   Restrict the container from acquiring additional privileges via suid or sgid bits. 
Containers should be restricted from acquiring additional previleges Docker Host Level 1                   By default you should restrict containers from acquiring additional privileges via suid or sgid. 
Content Trust should be enabled For Docker in ECS Fargate cluster FARGATE ECS Level 1                   Content trust is disabled by default and should be enabled in line with organizational security policy.Content trust provides the ability to use digital signatures for data sent to and received from remote Docker registries. These signatures allow client-side verification of the identity and the publisher of specific image tags and ensures the provenance of container images. 
Default seccomp profile should not be disabled in ECS Fargate cluster FARGATE ECS Level 1                   Seccomp filtering provides a means for a process to specify a filter for incoming system calls. The default Docker seccomp profile works on whitelist basis and allows 311 system calls blocking all others. It should not be disabled unless it hinders your container application usage. 
Docker Version should be kept up to date in ECS Fargate cluster FARGATE ECS Level 1                   Frequent releases for Docker are issued which address security vulnerabilities, resolve product bugs and bring in new functionality. You should keep a tab on these product updates and upgrade as frequently as possible in line with the general IT security policy of your organization. 
Docker host's network namespace should not be shared Docker Host Level 1                   When the networking mode on a container is set to --net=host, the container is not placed inside a separate network stack. Effectively, applying this option instructs Docker to not containerize the container's networking. The consequence of this is that the container lives "outside" in the main Docker host and has full access to its network interfaces. 
Docker socket should not be mounted inside any containers in ECS Fargate cluster FARGATE ECS Level 1                   The docker socket (docker.sock) should not be mounted inside a container.
Docker.socket file ownership should be set to root  EKS Level 1                   You should verify that the docker.socket file ownership and group ownership are correctly set to root. 
ECS Docker Host: A separate partition for containers should be created Docker Host Level 1                   All Docker containers and their data and metadata is stored under /var/lib/docker directory. By default, /var/lib/docker should be mounted under either the / or /var partitions dependent on how the Linux operating system in use is configured. 
ECS Docker Host: An user for the container should be created Docker Host Level 1                   Containers should run as a non-root user. 
ECS Docker Host: AppArmor Profile should be enabled if applicable Docker Host Level 1                   AppArmor is an effective and easy-to-use Linux application security system. It is available on some Linux distributions by default, for example, on Debian and Ubuntu. 
ECS Docker Host: Authorization for Docker client commands should be enabled Docker Host Level 1                   You should use native Docker authorization plugins or a third party authorization mechanism with the Docker daemon to manage access to Docker client commands. 
ECS Docker Host: Base device size should not be changed untill needed Docker Host Level 1                   Under certain circumstances, you might need containers larger than 10G. Where this applies you should carefully choose the base device size. 
ECS Docker Host: COPY should be used instead of ADD in Dockerfiles Docker Host Level 1                   You should use the COPY instruction instead of the ADD instruction in the Dockerfile. 
ECS Docker Host: CPU priority should be set appropriately on containers Docker Host Level 2                   By default, all containers on a Docker host share resources equally. By using the resource management capabilities of the Docker host you can control the host CPU resources that a container may consume. 
ECS Docker Host: Centralized and remote logging should be configured. Docker Host Level 1                   Docker supports various logging mechanisms. A preferable method for storing logs is one that supports centralized and remote management.
ECS Docker Host: Daemon.json file ownership should set to root:root Docker Host Level 1                   You should verify that the daemon.json file individual ownership and group ownership is correctly set to root. 
ECS Docker Host: Default cgroup usuage should be confirmed. Docker Host Level 1                   The --cgroup-parent option allows you to set the default cgroup parent to use for all containers. If there is no specific usage requirement for this, the setting should be left at its default. 
ECS Docker Host: Default ulimit should be  configured appropriately Docker Host Level 1                   Set the default ulimit options as appropriate in your environment. 
ECS Docker Host: Docker Daemon json file permissions should be set to 644 or more restrictive Docker Host Level 1                   You should verify that the file permissions on the docker daemonfile are correctly set to 644 or more restrictively. 
ECS Docker Host: Docker Default seccomp profile should not be disabled Docker Host Level 1                   Seccomp filtering provides a means for a process to specify a filter for incoming system calls. The default Docker seccomp profile works on a whitelist basis and allows for a large number of common system calls, whilst blocking all others. This filtering should not be disabled unless it causes a problem with your container application usage.
ECS Docker Host: Docker Host process namespace should not be shared Docker Host Level 1                   Process ID (PID) namespaces isolate the process ID number space, meaning that processes in different PID namespaces can have the same PID. This is process level isolation between containers and the host.
ECS Docker Host: Docker Host's IPC namespace should not be shared Docker Host Level 1                   IPC (POSIX/SysV IPC) namespace provides separation of named shared memory segments, semaphores and message queues. IPC namespace on the host thus should not be shared with the containers and should remain isolated.
ECS Docker Host: Docker Privileged ports should not be mapped within containers Docker Host Level 1                   The TCP/IP port numbers below 1024 are considered privileged ports. Normal users and processes are not allowed to use them for various security reasons. Docker does, however allow a container port to be mapped to a privileged port. 
ECS Docker Host: Docker host socket should not be mounted inside any containers Docker Host Level 1                   The Docker socket docker.sock should not be mounted inside a container. 
ECS Docker Host: Docker's default bridge docker0 should not be used DockDocker Hoster Host Level 1                   You should not use Docker's default bridge docker0. Instead you should use Docker's user-defined networks for container networking. 
ECS Docker Host: Docker.socket file permissions should be set to 644 or more restrictive Docker Host Level 1                   You should verify that the file permissions on the docker.socket file are correctly set to 644 or more restrictively. 
ECS Docker Host: Experimental features should not be implemented in production Docker Host Level 1                   Experimental is currently a runtime Docker daemon flag rather than being a feature of a separate build. Passing --experimental as a runtime flag to the docker daemon activates experimental features. Whilst Experimental is considered a stable release, it has a number of features which may not have been fully tested and do not guarantee API stability. 
ECS Docker Host: Host's user namespaces should not be shared Docker Host Level 2                   User namespaces ensure that a root process inside the container will be mapped to a non-root process outside the container. Sharing the user namespaces of the host with the container does not therefore isolate users on the host from users in the containers. 
ECS Docker Host: Incoming container traffic should be bound to a specific host interface Docker Host Level 1                   By default, Docker containers can make connections to the outside world, but the outside world cannot connect to containers and each outgoing connection will appear to originate from one of the host machine's own IP addresses. You should only allow container services to be contacted through a specific external interface on the host machine.. 
ECS Docker Host: Insecure registries should not be used Docker Host Level 1                   Docker considers a private registry either secure or insecure. By default, registries are considered secure. 
ECS Docker Host: IpTables should be allowed to be changed by Docker Docker Host Level 1                   The iptables firewall is used to set up, maintain, and inspect the tables of IP packet filter rules within the Linux kernel. The Docker daemon should be allowed to make changes to the iptables ruleset. 
ECS Docker Host: Logging level should be set to info Docker Host Level 2                   Set Docker daemon log level to info. 
ECS Docker Host: Network traffic should be restricted within containers Docker Host Level 1                   By default, all network traffic is allowed between containers on the same host on the default network bridge. If not desired, restrict all inter-container communication. Link specific containers together that require communication. Alternatively, you can create custom network and only join containers that need to communicate to that custom network. 
ECS Docker Host: TLS authentication should be configured for docker daemon Docker Host Level 1                   It is possible to make the Docker daemon available remotely over a TCP port. If this is required, you should ensure that TLS authentication is configured in order to restrict access to the Docker daemon via IP address and port. 
ECS Docker Host: The 'on-failure' container restart policy should be set to '5' Docker Host Level 1                   By using the --restart flag in the docker run command you can specify a restart policy for how a container should or should not be restarted on exit. You should choose the on-failure restart policy and limit the restart attempts to 5. 
ECS Docker Host: Userland Proxy should be disabled Docker Host Level 1                   The Docker daemon starts a userland proxy service for port forwarding whenever a port is exposed. Where hairpin NAT is available, this service is generally superfluous to requirements and can be disabled.
ECS Docker Host: Version of Docker should be kept up to date Docker Host Level 1                   Frequent releases for Docker are issued which address security vulnerabilities, resolve product bugs and bring in new functionality. You should keep a tab on these product updates and upgrade as frequently as possible in line with the general IT security policy of your organization.
ECS Docker Host: aufs storage driver should not be used Docker Host Level 1                   Docker considers a private registry either secure or insecure. By default, registries are considered secure. 
ECS Docker Host: cgroup usage should  be confirmed Docker Host Level 1                   Seccomp filtering provides a means for a process to specify a filter for incoming system calls. The default Docker seccomp profile works on a whitelist basis and allows for a large number of common system calls, whilst blocking all others. This filtering should not be disabled unless it causes a problem with your container application usage.
ECS Docker Host: container's root filesystem should be mounted as read only Docker Host Level 2                   The container's root filesystem should be treated as a 'golden image' by using Docker run's --read-only option. This prevents any writes to the container's root filesystem at container runtime and enforces the principle of immutable infrastructure. 
ECS Docker Host: host system directories should not be mounted on containers Docker Host Level 1                   The container's root filesystem should be treated as a 'golden image' by using Docker run's --read-only option. This prevents any writes to the container's root filesystem at container runtime and enforces the principle of immutable infrastructure. 
ECS Docker Host: memory usage for containers should be limited Docker Host Level 2                   By default, all containers on a Docker host share resources equally. By using the resource management capabilities of the Docker host, you can control the amount of memory that a container is able to use.. 
ECS Docker Host: trusted users should be allowed to control Docker daemon Docker Host Level 1                   The Docker daemon currently requires access to the Docker socket which is, by default, owned by the user root and the group docker. 
ECS Docker Host: update instructions should not be use alone in the Dockerfile Docker Host Level 1                   You should not use OS package manager update instructions such as apt-get update or yum update either alone or in a single line in the Dockerfile. 
ECS: A non-root user should be created for the container ECS Container Definition Level 1                   Create a non-root user for the container in the Dockerfile for the container image. 
ECS: Centralized and remote logging should be configured ECS Container Definition Level 1                   Docker now supports various log drivers. A preferable way to store logs is the one that supports centralized and remote logging. 
ECS: Container CPU priority should be set appropriately ECS Service Level 1                   By default, all containers on a Docker host share the resources equally. By using the resource management capabilities of Docker host, such as CPU shares, you can control the host CPU resources that a container may consume. 
ECS: Container health should be checked at runtime ECS Container Definition Level 1                   If the container image does not have an HEALTHCHECK instruction defined, use --health-cmd parameter at container runtime for checking container health. 
ECS: Container should be restricted from acquiring additional privileges ECS Container Definition Level 1                   Restrict the container from acquiring additional privileges via suid or sgid bits. 
ECS: Container sprawl should be avoided ECS Service Level 1                   Do not keep a large number of containers on the same host. 
ECS: Container's file system should be mounted in read-only mode ECS Container Definition Level 1                   The container's root file system should be treated as a 'golden image' and any writes to the root filesystem should be avoided. You should explicitly define a container volume for writing. 
ECS: Default seccomp profile should not be disabled ECS Container Definition Level 1                   Seccomp filtering provides a means for a process to specify a filter for incoming system calls. The default Docker seccomp profile works on whitelist basis and allows 311 system calls blocking all others. It should not be disabled unless it hinders your container application usage. 
ECS: Docker Version should be kept up to date ECS Container Definition Level 1                   Frequent releases for Docker are issued which address security vulnerabilities, resolve product bugs and bring in new functionality. You should keep a tab on these product updates and upgrade as frequently as possible in line with the general IT security policy of your organization. 
ECS: Docker socket should not be mounted inside any containers ECS Container Definition Level 2                  

The docker socket (docker.sock) should not be mounted inside a container.

Rationale:

If the docker socket is mounted inside a container it would allow processes running within the container to execute docker commands which effectively allows for full control of the host.

ECS: Docker's default bridge networking mode should not be used ECS Container Definition Level 2                   Do not use Docker's default bridge docker0. Use docker's user-defined networks for container networking
ECS: Encrypt Transmission of Cardholder Data Across Open Public Networks ECS Level 1                    Load Balancers can offload encryption processing for secure communications for both internal and external connections. Load balancers are the easiest way to ensure compliance with PCI DSS. Without a load balancer, you must configure your own application and host with proper encryption protocols. That configuration would be outside the scope of AWS and therefore this workbook. 
ECS: HEALTHCHECK instruction should be added to the container image ECS Container Definition Level 1                   Add HEALTHCHECK instruction in your docker container images to perform the health check on running containers. 
ECS: Host devices should not be exposed directly to containers ECS Container Definition Level 1                   Host devices can be directly exposed to containers at runtime. Do not directly expose host devices to containers especially for containers that are not trusted. 
ECS: Host process namespace should not be shared ECS Service Level 2                   Process ID (PID) namespaces isolate the process ID number space, meaning that processes in different PID namespaces can have the same PID. This is process level isolation between containers and the host.
ECS: Host's IPC namespace should not be shared ECS Container Definition Level 1                   IPC (POSIX/SysV IPC) namespace provides separation of named shared memory segments, semaphores and message queues. IPC namespace on the host thus should not be shared with the containers and should remain isolated.
ECS: Host's UTS namespace should not be shared ECS Container Definition Level 1el 1                   UTS namespaces provide isolation of two system identifiers: the hostname and the NIS domain name. It is used for setting the hostname and the domain that is visible to running processes in that namespace. Processes running within containers do not typically require to know hostname and domain name. Hence, the namespace should not be shared with the host. 
ECS: Incoming container traffic should be binded to a specific host interface ECS Container Definition Level 2                   By default, Docker containers can make connections to the outside world, but the outside world cannot connect to containers. Each outgoing connection will appear to originate from one of the host machine's own IP addresses. Only allow container services to be contacted through a specific external interface on the host machine. 
ECS: Memory usage for container should be limited ECS Service Level 1                   By default, all containers on a Docker host share the resources equally. By using the resource management capabilities of Docker host, such as memory limit, you can control the amount of memory that a container may consume. 
ECS: Mount propagation mode should not be set to shared ECS Service Level 1                   A shared mount is replicated at all mounts and the changes made at any mount point are propagated to all mounts. Mounting a volume in shared mode does not restrict any other container to mount and make changes to that volume. This might be catastrophic if the mounted volume is sensitive to changes. Do not set mount propagation mode to shared until needed.
ECS: Network traffic should be restricted between containers ECS Service Level 1                   By default, all network traffic is allowed between containers on the same host. If not desired, restrict all the inter container communication. Link specific containers together that require inter communication. 
ECS: PIDs cgroup limit should be used ECS Container Definition Level 2                   Use --pids-limit flag at container runtime
ECS: Privileged containers should not be used ECS Container Definition Level 1                   The --privileged flag gives all capabilities to the container, and it also lifts all the limitations enforced by the device cgroup controller. In other words, the container can then do almost everything that the host can do. This flag exists to allow special use-cases, like running Docker within Docker.
ECS: Privileged ports should not be mapped within containers ECS Container Definition Level 1                   The TCP/IP port numbers below 1024 are considered privileged ports. Normal users and processes are not allowed to use them for various security reasons. Docker allows a container port to be mapped to a privileged port.
ECS: Setuid and Setgid permissions should be removed in the images ECS Container Definition Level 1                   Removing setuid and setgid permissions in the images would prevent privilege escalation attacks in the containers. 
ECS: Swarm mode should not be enabled ECS Service Level 1                   Do not enable swarm mode on a docker engine instance unless needed.
ECS: Use of secrets in docker image history or environmental variables   Level 1                   In addition to software defects, images may also have configuration defects. For example, an image may not be configured with a specific user account to “run as” and thus run with greater privileges than needed. As another example, an image may include an SSH daemon, which exposes the container to unnecessary network risk. Much like in a traditional server or VM,where a poor configuration can still expose a fully up-to-date system to attack, so too can a poorly configured image increase risk even if all the included components are up-to-date.
ECS: User namespace support should be enabled ECS Container Definition Level 2                   Enable user namespace support in Docker daemon to utilize container user to host user re-mapping. This recommendation is beneficial where containers you are using do not have an explicit container user defined in the container image. If container images that you are using have a pre-defined non-root user, this recommendation may be skipped since this feature is still in its infancy and might give you unpredictable issues and complexities. 
EKS Container Host: AppArmor Profile should be enabled if applicable EKS Level 1                   AppArmor is an effective and easy-to-use Linux application security system. It is available on some Linux distributions by default, for example, on Debian and Ubuntu. 
EKS Container Host: Aufs storage driver should not be used EKS Level 1                   By default, all containers on a Docker host share resources equally. By using the resource management capabilities of the Docker host you can control the host CPU resources that a container may consume. 
EKS Container Host: CPU priority should be set appropriately on containers EKS Level 1                   By default, all containers on a Docker host share resources equally. By using the resource management capabilities of the Docker host you can control the host CPU resources that a container may consume. 
EKS Container Host: Container .socket file permissions should be set to 644 or more restrictive EKS Level 1                   You should verify that the file permissions on the container .socket file are correctly set to 644 or more restrictively.
EKS Container Host: Container Daemon json file permissions should be set to 644 or more restrictive EKS Level 1                   You should verify that the file permissions on the docker daemon file are correctly set to 644 or more restrictively.
EKS Container Host: Container Host process namespace should not be shared EKS Level 1                   Process ID (PID) namespaces isolate the process ID number space, meaning that processes in different PID namespaces can have the same PID. This is process level isolation between containers and the host.
EKS Container Host: Container Host's IPC namespace should not be shared EKS Level 1                   IPC (POSIX/SysV IPC) namespace provides separation of named shared memory segments, semaphores and message queues. IPC namespace on the host thus should not be shared with the containers and should remain isolated.
EKS Container Host: Container host socket should not be mounted inside any containers EKS Level 2                   The Container socket Container .sock should not be mounted inside a container.
EKS Container Host: Container host's network namespace should not be shared EKS Level 1                   When the networking mode on a container is set to --net=host, the container is not placed inside a separate network stack. Effectively, applying this option instructs Docker to not containerize the container's networking. The consequence of this is that the container lives "outside" in the main Container host and has full access to its network interfaces. 
EKS Container Host: Containers should be restricted from acquiring additional previleges EKS Level 2                   By default you should restrict containers from acquiring additional privileges via suid or sgid. 
EKS Container Host: Daemon.json file ownership should set to root:root EKS Level 1                   You should verify that the daemon.json file individual ownership and group ownership is correctly set to root. 
EKS Container Host: Linux Kernel Capabilities should be restricted within containers EKS Level 1                   By default, container starts with a restricted set of Linux Kernel Capabilities. It means that any process may be granted the required capabilities instead of root access. Using Linux Kernel Capabilities, the processes do not have to run as root for almost all the specific areas where root privileges are usually needed. 
EKS Container Host: Logging level should be set to info EKS Level 1                   Set Container daemon log level to info.
EKS Container Host: SELinux security options should be enabled if applicable EKS Level 1                   SELinux is an effective and easy-to-use Linux application security system. It is available by default on some distributions such as Red Hat and Fedora. 
EKS Container Host: Trusted users should be allowed to control container daemon EKS Level 1                   The Container daemon currently requires access to the container socket which is, by default, owned by the user root and the group container. 
EKS Container Host: UTS namespace should not be shared EKS Level 1                   UTS namespaces provide isolation between two system identifiers: the hostname and the NIS domain name. It is used to set the hostname and the domain which are visible to running processes in that namespace. Processes running within containers do not typically require to know either the hostname or the domain name. The UTS namespace should therefore not be shared with the host.
EKS Container Host: host system directories should not be mounted on containers EKS Level 1                   You should not allow sensitive host system directories such as those listed below to be mounted as container volumes, especially in read-write mode. 
EKS Docker Host: A separate partition for containers should be created EKS Level 1                   All Docker containers and their data and metadata is stored under /var/lib/docker directory. By default, /var/lib/docker should be mounted under either the / or /var partitions dependent on how the Linux operating system in use is configured. 
EKS Docker Host: An user for the container should be created EKS Level 1                   Containers should run as a non-root user. 
EKS Docker Host: Authorization for Docker client commands should be enabled EKS Level 1                   You should use native Docker authorization plugins or a third party authorization mechanism with the Docker daemon to manage access to Docker client commands. 
EKS Docker Host: Base device size should not be changed until needed EKS Level 1                   Under certain circumstances, you might need containers larger than 10G. Where this applies you should carefully choose the base device size. 
EKS Docker Host: COPY should be used instead of ADD in Dockerfiles EKS Level 2                   You should use the COPY instruction instead of the ADD instruction in the Dockerfile. 
EKS Docker Host: Centralized and remote logging should be configured EKS Level 1                   Docker supports various logging mechanisms. A preferable method for storing logs is one that supports centralized and remote management.
EKS Docker Host: Cgroup usage should  be confirmed EKS Level 1                   It is possible to attach to a particular cgroup when a container is instantiated. Confirming cgroup usage would ensure that containers are running in defined cgroups
EKS Docker Host: Container health should be checked at runtime EKS Level 1                   If the container image does not have an HEALTHCHECK instruction defined, you should use the --health-cmd parameter at container runtime to check container health. 
EKS Docker Host: Container's root filesystem should be mounted as read only EKS Level 1                   The --cgroup-parent option allows you to set the default cgroup parent to use for all containers. If there is no specific usage requirement for this, the setting should be left at its default. 
EKS Docker Host: Default cgroup usage should be confirmed EKS Level 1                   The --cgroup-parent option allows you to set the default cgroup parent to use for all containers. If there is no specific usage requirement for this, the setting should be left at its default. 
EKS Docker Host: Default ulimit should be  configured appropriately EKS Level 1                   Set the default ulimit options as appropriate in your environment. 
EKS Docker Host: Docker Default seccomp profile should not be disabled EKS Level 1                   Seccomp filtering provides a means for a process to specify a filter for incoming system calls. The default Docker seccomp profile works on a whitelist basis and allows for a large number of common system calls, whilst blocking all others. This filtering should not be disabled unless it causes a problem with your container application usage.
EKS Docker Host: Docker Privileged ports should not be mapped within containers EKS Level 1                   The TCP/IP port numbers below 1024 are considered privileged ports. Normal users and processes are not allowed to use them for various security reasons. Docker does, however allow a container port to be mapped to a privileged port. 
EKS Docker Host: Docker's default bridge docker0 should not be used EKS Level 1                   You should not use Docker's default bridge docker0. Instead you should use Docker's user-defined networks for container networking. 
EKS Docker Host: Experimental features should not be implemented in production EKS Level 1                   Experimental is currently a runtime Docker daemon flag rather than being a feature of a separate build. Passing --experimental as a runtime flag to the docker daemon activates experimental features. Whilst Experimental is considered a stable release, it has a number of features which may not have been fully tested and do not guarantee API stability. 
EKS Docker Host: Host's user namespaces should not be shared EKS Level 2                   User namespaces ensure that a root process inside the container will be mapped to a non-root process outside the container. Sharing the user namespaces of the host with the container does not therefore isolate users on the host from users in the containers. 
EKS Docker Host: Incoming container traffic should be bound to a specific host interface EKS Level 1                   By default, Docker containers can make connections to the outside world, but the outside world cannot connect to containers and each outgoing connection will appear to originate from one of the host machine's own IP addresses. You should only allow container services to be contacted through a specific external interface on the host machine.. 
EKS Docker Host: Insecure registries should not be used EKS Level 1                   Docker considers a private registry either secure or insecure. By default, registries are considered secure. 
EKS Docker Host: IpTables should be allowed to be changed by Docker EKS Level 2                   The iptables firewall is used to set up, maintain, and inspect the tables of IP packet filter rules within the Linux kernel. The Docker daemon should be allowed to make changes to the iptables ruleset. 
EKS Docker Host: Live restore should be enabled EKS Level 1                   The --live-restore option enables full support of daemon-less containers within Docker. It ensures that Docker does not stop containers on shutdown or restore and that it properly reconnects to the container when restarted
EKS Docker Host: Network traffic should be restricted within containers EKS Level 2                   Attackers could launch a fork bomb with a single command inside the container. This fork bomb could crash the entire system and would require a restart of the host to make the system functional again. Using the PIDs cgroup parameter --pids-limit would prevent this kind of attack by restricting the number of forks that can happen inside a container within a specified time frame. 
EKS Docker Host: PIDs cgroup limit should be used EKS Level 2                   Attackers could launch a fork bomb with a single command inside the container. This fork bomb could crash the entire system and would require a restart of the host to make the system functional again. Using the PIDs cgroup parameter --pids-limit would prevent this kind of attack by restricting the number of forks that can happen inside a container within a specified time frame. 
EKS Docker Host: Privileged containers should not be used EKS Level 2                   Using the --privileged flag provides all Linux kernel capabilities to the container to which it is applied and therefore overwrites the --cap-add and --cap-drop flags. For this reason you should ensure that it is not used. 
EKS Docker Host: TLS authentication should be configured for docker daemon EKS Level 1                   It is possible to make the Docker daemon available remotely over a TCP port. If this is required, you should ensure that TLS authentication is configured in order to restrict access to the Docker daemon via IP address and port. 
EKS Docker Host: The 'on-failure' container restart policy should be set to '5' EKS Level 1                   By using the --restart flag in the docker run command you can specify a restart policy for how a container should or should not be restarted on exit. You should choose the on-failure restart policy and limit the restart attempts to 5. 
EKS Docker Host: Update instructions should not be use alone in the Dockerfile EKS Level 2                   You should not use OS package manager update instructions such as apt-get update or yum update either alone or in a single line in the Dockerfile. 
EKS Docker Host: User namespace support should be enabled for a container EKS Level 1                   You should enable user namespace support in Docker daemon to utilize container user to host user re-mapping. This recommendation is beneficial where the containers you are using do not have an explicit container user defined in the container image. If the container images that you are using have a pre-defined non-root user, this recommendation may be skipped as this feature is still in its infancy, and might result in unpredictable issues or difficulty in configuration. 
EKS Docker Host: Userland Proxy should be disabled EKS Level 1                   The Docker daemon starts a userland proxy service for port forwarding whenever a port is exposed. Where hairpin NAT is available, this service is generally superfluous to requirements and can be disabled.
EKS Docker Host: Version of Docker should be kept up to date EKS Level 1                   Frequent releases for Docker are issued which address security vulnerabilities, resolve product bugs and bring in new functionality. You should keep a tab on these product updates and upgrade as frequently as possible in line with the general IT security policy of your organization.
EKS Docker Host: memory usage for containers should be limited EKS Level 1                   By default, all containers on a Docker host share resources equally. By using the resource management capabilities of the Docker host, you can control the amount of memory that a container is able to use.. 
EKS FARGATE: Argument RotateKubeletServerCertificate should be set to true for Kubelet Server FARGATE EKS Level 1                   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 security triad. This recommendation only applies if you let kubelets get their certificates from the API server. In case your kubelet certificates come from an outside authority/tool (e.g. Vault) then you need to take care of rotation yourself.
EKS FARGATE: Argument anonymous-auth should be set to false for Kubelet Server FARGATE EKS Level 1                   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 FARGATE: Argument authorization-mode should not be set to AlwaysAllow for Kubelet Server FARGATE EKS Level 1                   Kubelets, by default, 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 FARGATE: Argument client-ca-file should be set as appropriate for Kubelet Server FARGATE EKS Level 1                   The connections from the apiserver to the kubelet are used for fetching logs for pods, attaching (through kubectl) to running pods, and using the kubelet’s port-forwarding functionality. These connections terminate at the kubelet’s HTTPS endpoint. By default, the apiserver does not verify the kubelet’s serving certificate, which makes the connection subject to man-in-the-middle attacks, and unsafe to run over untrusted and/or public networks. Enabling Kubelet certificate authentication ensures that the apiserver could authenticate the Kubelet before submitting any requests.
EKS FARGATE: Argument event-qps should be set to 0 for Kubelet Server FARGATE EKS Level 1                   It is important to capture all events and not restrict event creation. Events are an important source of security information and analytics that ensure that your environment is consistently monitored using the event data.
EKS FARGATE: Argument make-iptables-util-chains should be set to true for Kubelet Server FARGATE EKS Level 1                   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 FARGATE: Argument protect-kernel-defaults should be set to true for Kubelet Server FARGATE EKS Level 1                   Kernel parameters are usually tuned and hardened by the system administrators before putting the systems into production. These parameters protect the kernel and the system. Your kubelet kernel defaults that rely on such parameters should be appropriately set to match the desired secured system state. Ignoring this could potentially lead to running pods with undesired kernel behavior
EKS FARGATE: Argument read-only-port should be set to 0 for Kubelet Server FARGATE EKS Level 1                   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 FARGATE: Argument rotate-certificates should be set to true for Kubelet Server FARGATE EKS Level 1                   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 are no downtimes due to expired certificates and thus addressing availability in the CIA security triad. This recommendation only applies if you let kubelets get their certificates from the API server. In case your kubelet certificates come from an outside authority/tool (e.g. Vault) then you need to take care of rotation yourself
EKS FARGATE: Argument streaming-connection-idle-timeout should not be set to 0 for Kubelet Server FARGATE EKS Level 1                   Setting idle timeouts ensures that you are protected against Denial-of-Service attacks, inactive connections and running out of ephemeral ports. By default, --streaming-connection-idle-timeout is set to 4 hours which might be too high for your environment. Setting this as appropriate would additionally ensure that such streaming connections are timed out after serving legitimate use cases.
EKS FARGATE: Arguments tls-cert-file and tls-private-key-file should be set as appropriate for Kubelet Server FARGATE EKS Level 1                   Kubelet communication contains sensitive parameters that should remain encrypted in transit. Configure the Kubelets to serve only HTTPS traffic.
EKS FARGATE: Kubelet should only use strong Cryptographic Ciphers FARGATE EKS Level 1                   TLS ciphers have had a number of known vulnerabilities and weaknesses, which can reduce the protection provided by them. By default Kubernetes supports a number of TLS ciphersuites including some that have security concerns, weakening the protection provided.
EKS: Admission control plugin AlwaysAdmit should not be set for API Server EKS Level 1                   Setting admission control plugin AlwaysAdmit allows all requests and do not filter any requests.
EKS: Admission control plugin AlwaysPullImages should be set for API Server EKS Level 2                   Setting admission control policy to AlwaysPullImages forces every new pod to pull the required images every time. In a multi-tenant cluster users can be assured that their private images can only be used by those who have the credentials to pull them. Without this admission control policy, once an image has been pulled to a node, any pod from any user can use it simply by knowing the image’s name, without any authorization check against the image ownership. When this plug-in is enabled, images are always pulled prior to starting containers, which means valid credentials are required.
EKS: Admission control plugin EventRateLimit should be set for API Server EKS Level 1                   Using EventRateLimit admission control enforces a limit on the number of events that the API Server will accept in a given time slice. A misbehaving workload could overwhelm and DoS the API Server, making it unavailable. This particularly applies to a multi-tenant cluster, where there might be a small percentage of misbehaving tenants which could have a significant impact on the performance of the cluster overall. Hence, it is recommended to limit the rate of events that the API server will accept.
EKS: Admission control plugin NamespaceLifecycle should be set for API Server EKS Level 2                   Setting admission control policy to NamespaceLifecycle ensures that objects cannot be created in non-existent namespaces, and that namespaces undergoing termination are not used for creating the new objects. This is recommended to enforce the integrity of the namespace termination process and also for the availability of the newer objects
EKS: Admission control plugin NodeRestriction should be set for API Server EKS Level 1                   Using the NodeRestriction plug-in ensures that the kubelet is restricted to the Node and Pod objects that it could modify as defined. Such kubelets will only be allowed to modify their own Node API object, and only modify Pod API objects that are bound to their node.
EKS: Admission control plugin PodSecurityPolicy should be set for API Server EKS Level 1                   A Pod Security Policy is a cluster-level resource that controls the actions that a pod can perform and what it has the ability to access. The PodSecurityPolicy objects define a set of conditions that a pod must run with in order to be accepted into the system. Pod Security Policies are comprised of settings and strategies that control the security features a pod has access to and hence this must be used to control pod access permissions.
EKS: Admission control plugin SecurityContextDeny should be set if PodSecurityPolicy is not used for API Server EKS Level 1                   SecurityContextDeny can be used to provide a layer of security for clusters which do not have PodSecurityPolicies enabled.
EKS: Admission control plugin ServiceAccount should be set for API Server EKS Level 2                   When you create a pod, if you do not specify a service account, it is automatically assigned the default service account in the same namespace. You should create your own service account and let the API server manage its security tokens.
EKS: Argument AdvancedAuditing should not be set to false for API Server EKS Level 1                   AdvancedAuditing enables a much more general API auditing pipeline, which includes support for pluggable output backends and an audit policy specifying how different requests should be audited. Additionally, this enables auditing of failed authentication, authorization and login attempts which could prove crucial for protecting your production clusters. It is thus recommended not to disable advanced auditing   
EKS: Argument DenyServiceExternalIPs should not be set for API Server EKS Level 1                   This admission controller rejects all net-new usage of the Service field externalIPs. This feature is very powerful (allows network traffic interception) and not well controlled by policy. When enabled, users of the cluster may not create new Services which use externalIPs and may not add new values to externalIPs on existing Service objects. Existing uses of externalIPs are not affected, and users may remove values from externalIPs on existing Service objects. SecurityContextDeny can be used to provide a layer of security for clusters which do not have PodSecurityPolicies enabled.
EKS: Argument RotateKubeletServerCertificate should be set to true for Controller Manager EKS Level 1                   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 security triad.
EKS: Argument RotateKubeletServerCertificate should be set to true for Kubelet Server EKS Worker Node                     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 security triad. This recommendation only applies if you let kubelets get their certificates from the API server. In case your kubelet certificates come from an outside authority/tool (e.g. Vault) then you need to take care of rotation yourself.
EKS: Argument address should be set to 127.0.0.1 for Controller Manager EKS Level 1                   The Controller Manager API service which runs on port 10252/TCP by default is used for health and metrics information and is available without authentication or encryption. As such it should only be bound to a localhost interface, to minimize the cluster's attack surface
EKS: Argument address should be set to 127.0.0.1 for Scheduler EKS Level 1                   The Scheduler API service which runs on port 10251/TCP by default is used for health and metrics information and is available without authentication or encryption. As such it should only be bound to a localhost interface, to minimize the cluster's attack surface
EKS: Argument anonymous-auth should be set to false for API Server EKS Level 1                   When enabled, requests that are not rejected by other configured authentication methods are treated as anonymous requests. These requests are then served by the API server. You should rely on authentication to authorize access and disallow anonymous requests.
EKS: Argument anonymous-auth should be set to false for Kubelet Server EKS Worker Node                     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: Argument audit-log-maxage should be set to 30 or as appropriate for API Server EKS Level 1                   Retaining logs for at least 30 days ensures that you can go back in time and investigate or correlate any events. Set your audit log retention period to 30 days or as per your business requirements.
EKS: Argument audit-log-maxbackup should be set to 10 or as appropriate for API Server EKS Level 1                   Kubernetes automatically rotates the log files. Retaining old log files ensures that you would have sufficient log data available for carrying out any investigation or correlation. For example, if you have set file size of 100 MB and the number of old log files to keep as 10, you would approximate have 1 GB of log data that you could potentially use for your analysis.
EKS: Argument audit-log-maxsize should be set to 100 or as appropriate for API Server EKS Level 1                   Kubernetes automatically rotates the log files. Retaining old log files ensures that you would have sufficient log data available for carrying out any investigation or correlation. If you have set file size of 100 MB and the number of old log files to keep as 10, you would approximate have 1 GB of log data that you could potentially use for your analysis.
EKS: Argument audit-log-path should be set as appropriate for API Server EKS Level 1                   Auditing the API Server provides a security-relevant chronological set of records documenting the sequence of activities that have affected system by individual users, administrators or other components of the system. Even though currently, Kubernetes provides only basic audit capabilities, it should be enabled. You can enable it by setting an appropriate audit log path.
EKS: Argument authorization-mode should include Node for API Server EKS Level 1                   The Node authorization mode only allows kubelets to read Secret, ConfigMap, PersistentVolume, and PersistentVolumeClaim objects associated with their nodes.
EKS: Argument authorization-mode should include RBAC for API Server EKS Level 1                   Role Based Access Control (RBAC) allows fine-grained control over the operations that different entities can perform on different objects in the cluster. It is recommended to use the RBAC authorisation mode.
EKS: Argument authorization-mode should not be set to AlwaysAllow for API Server EKS Level 1                   The API Server, can be configured to allow all requests. This mode should not be used on any production cluster.
EKS: Argument authorization-mode should not be set to AlwaysAllow for Kubelet Server EKS Worker Node Level 1                   Kubelets, by default, 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: Argument basic-auth-file should not be set for API Server EKS Level 1                   Basic authentication uses plaintext credentials for authentication. Currently, the basic authentication credentials last indefinitely, and the password cannot be changed without restarting API server. The basic authentication is currently supported for convenience. Hence, basic authentication should not be used.
EKS: Argument client-ca-file should be set as appropriate for API Server EKS Level 1                   API server communication contains sensitive parameters that should remain encrypted in transit. Configure the API server to serve only HTTPS traffic. If --client-ca-file argument is set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client certificate.
EKS: Argument client-ca-file should be set as appropriate for Kubelet Server EKS Worker Node Level 1                   The connections from the apiserver to the kubelet are used for fetching logs for pods, attaching (through kubectl) to running pods, and using the kubelet’s port-forwarding functionality. These connections terminate at the kubelet’s HTTPS endpoint. By default, the apiserver does not verify the kubelet’s serving certificate, which makes the connection subject to man-in-the-middle attacks, and unsafe to run over untrusted and/or public networks. Enabling Kubelet certificate authentication ensures that the apiserver could authenticate the Kubelet before submitting any requests.
EKS: Argument encryption-provider-config should be set as appropriate for API Server EKS Level 1                   etcd is a highly available key-value store used by Kubernetes deployments for persistent storage of all of its REST API objects. These objects are sensitive in nature and should be encrypted at rest to avoid any disclosures.
EKS: Argument etcd-cafile should be set as appropriate for API Server EKS Level 1                   etcd is a highly-available key value store used by Kubernetes deployments for persistent storage of all of its REST API objects. These objects are sensitive in nature and should be protected by client authentication. This requires the API server to identify itself to the etcd server using a SSL Certificate Authority file.
EKS: Argument event-qps should be set to 0 or a level which ensures appropriate event capture for Kubelet Server EKS Worker Node Level 1                   It is important to capture all events and not restrict event creation. Events are an important source of security information and analytics that ensure that your environment is consistently monitored using the event data.
EKS: Argument insecure-allow-any-token should not be set for API Server EKS Level 1                   Accepting insecure tokens would allow any token without actually authenticating anything. User information is parsed from the token and connections are allowed.
EKS: Argument insecure-bind-address should not be set for API Server EKS Level 1                   If you bind the apiserver to an insecure address, basically anyone who could connect to it over the insecure port, would have unauthenticated and unencrypted access to your master node. The apiserver doesn't do any authentication checking for insecure binds and traffic to the Insecure API port is not encrpyted, allowing attackers to potentially read sensitive data in transit.
EKS: Argument insecure-port should be set to 0 for API Server EKS Level 1                   Setting up the apiserver to serve on an insecure port would allow unauthenticated and unencrypted access to your master node. This would allow attackers who could access this port, to easily take control of the cluster.
EKS: Argument kubelet-certificate-authority should be set as appropriate for API Server EKS Level 1                   The connections from the apiserver to the kubelet are used for fetching logs for pods, attaching (through kubectl) to running pods, and using the kubelet’s port-forwarding functionality. These connections terminate at the kubelet’s HTTPS endpoint. By default, the apiserver does not verify the kubelet’s serving certificate, which makes the connection subject to man-in-the-middle attacks, and unsafe to run over untrusted and/or public networks.
EKS: Argument kubelet-https should be set to true for API Server EKS Level 1                   Connections from apiserver to kubelets could potentially carry sensitive data such as secrets and keys. It is thus important to use in-transit encryption for any communication between the apiserver and kubelets.
EKS: Argument make-iptables-util-chains should be set to true for Kubelet Server EKS Worker Node Level 1                   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: Argument profiling should be set to false for API Server EKS Level 1                   Profiling allows for the identification of specific performance bottlenecks. It generates a significant amount of program data that could potentially be exploited to uncover system and program details. If you are not experiencing any bottlenecks and do not need the profiler for troubleshooting purposes, it is recommended to turn it off to reduce the potential attack surface.
EKS: Argument profiling should be set to false for Controller Manager EKS Level 1                   Profiling allows for the identification of specific performance bottlenecks. It generates a significant amount of program data that could potentially be exploited to uncover system and program details. If you are not experiencing any bottlenecks and do not need the profiler for troubleshooting purposes, it is recommended to turn it off to reduce the potential attack surface.
EKS: Argument profiling should be set to false for Scheduler EKS Level 1                   Profiling allows for the identification of specific performance bottlenecks. It generates a significant amount of program data that could potentially be exploited to uncover system and program details. If you are not experiencing any bottlenecks and do not need the profiler for troubleshooting purposes, it is recommended to turn it off to reduce the potential attack surface.
EKS: Argument protect-kernel-defaults should be set to true for Kubelet Server EKS Level 1                   Kernel parameters are usually tuned and hardened by the system administrators before putting the systems into production. These parameters protect the kernel and the system. Your kubelet kernel defaults that rely on such parameters should be appropriately set to match the desired secured system state. Ignoring this could potentially lead to running pods with undesired kernel behavior
EKS: Argument request-timeout should be set as appropriate for API Server EKS Level 1                   Setting global request timeout allows extending the API server request timeout limit to a duration appropriate to the user's connection speed. By default, it is set to 60 seconds which might be problematic on slower connections making cluster resources inaccessible once the data volume for requests exceeds what can be transmitted in 60 seconds. But, setting this timeout limit to be too large can exhaust the API server resources making it prone to Denial-of-Service attack. Hence, it is recommended to set this limit as appropriate and change the default limit of 60 seconds only if needed.
EKS: Argument root-ca-file should be set as appropriate for Controller Manager EKS Level 1                   Processes running within pods that need to contact the API server must verify the API server's serving certificate. Failing to do so could be a subject to man-in-the-middle attacks. Providing the root certificate for the API server's serving certificate to the controller manager with the --root-ca-file argument allows the controller manager to inject the trusted bundle into pods so that they can verify TLS connections to the API server.
EKS: Argument rotate-certificates should be set to true for Kubelet Server EKS Worker Node Level 1                   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 are no downtimes due to expired certificates and thus addressing availability in the CIA security triad. This recommendation only applies if you let kubelets get their certificates from the API server. In case your kubelet certificates come from an outside authority/tool (e.g. Vault) then you need to take care of rotation yourself
EKS: Argument secure-port should not be set to 0 for API Server EKS Level 1                   The secure port is used to serve https with authentication and authorization. If you disable it, no https traffic is served and all traffic is served unencrypted.
EKS: Argument service-account-key-file should be set as appropriate for API Server EKS Level 1                   By default, if no --service-account-key-file is specified to the apiserver, it uses the private key from the TLS serving certificate to verify service account tokens. To ensure that the keys for service account tokens could be rotated as needed, a separate public/private key pair should be used for signing service account tokens. Hence, the public key should be specified to the apiserver with --service-account-key-file.
EKS: Argument service-account-lookup should be set to true for API Server EKS Level 1                   If --service-account-lookup is not enabled, the apiserver only verifies that the authentication token is valid, and does not validate that the service account token mentioned in the request is actually present in etcd. This allows using a service account token even after the corresponding service account is deleted. This is an example of time of check to time of use security issue
EKS: Argument service-account-private-key-file should be set as appropriate for Controller Manager EKS Level 1                   To ensure that keys for service account tokens can be rotated as needed, a separate public/private key pair should be used for signing service account tokens. The private key should be specified to the controller manager with --service-account-private-key-file as appropriate.
EKS: Argument streaming-connection-idle-timeout should not be set to 0 for Kubelet Server EKS Worker Node Level 1                   Setting idle timeouts ensures that you are protected against Denial-of-Service attacks, inactive connections and running out of ephemeral ports. By default, --streaming-connection-idle-timeout is set to 4 hours which might be too high for your environment. Setting this as appropriate would additionally ensure that such streaming connections are timed out after serving legitimate use cases.
EKS: Argument terminated-pod-gc-threshold should be set as appropriate for Controller Manager EKSEKS Level 1                   Garbage collection is important to ensure sufficient resource availability and avoiding degraded performance and availability. In the worst case, the system might crash or just be unusable for a long period of time. The current setting for garbage collection is 12,500 terminated pods which might be too high for your system to sustain. Based on your system resources and tests, choose an appropriate threshold value to activate garbage collection.
EKS: Argument token-auth-file should not be set for API Server EKS Level 1                   The token-based authentication utilizes static tokens to authenticate requests to the apiserver. The tokens are stored in clear-text in a file on the apiserver, and cannot be revoked or rotated without restarting the apiserver. Hence, do not use static token-based authentication.
EKS: Argument use-service-account-credentials should be set to true for Controller Manager EKS Level 1                   The controller manager creates a service account per controller in the kube-system namespace, generates a credential for it, and builds a dedicated API client with that service account credential for each controller loop to use. Setting the --use-service-accountcredentials to true runs each control loop within the controller manager using a separate service account credential. When used in combination with RBAC, this ensures that the control loops run with the minimum permissions required to perform their intended tasks.
EKS: Arguments etcd-certfile and etcd-keyfile should be set as appropriate for API Server EKS Level 1                   etcd is a highly-available key value store used by Kubernetes deployments for persistent storage of all of its REST API objects. These objects are sensitive in nature and should be protected by client authentication. This requires the API server to identify itself to the etcd server using a client certificate and key
EKS: Arguments kubelet-client-certificate and kubelet-client-key should be set as appropriate for API Server EKS Level 1                   The apiserver, by default, does not authenticate itself to the kubelet's HTTPS endpoints. The requests from the apiserver are treated anonymously. You should set up certificatebased kubelet authentication to ensure that the apiserver authenticates itself to kubelets when submitting requests.
EKS: Arguments tls-cert-file and tls-private-key-file should be set as appropriate for API Server EKS Level 1                   API server communication contains sensitive parameters that should remain encrypted in transit. Configure the API server to serve only HTTPS traffic.
EKS: Arguments tls-cert-file and tls-private-key-file should be set as appropriate for Kubelet Server EKS Worker Node Level 1                   The connections from the apiserver to the kubelet are used for fetching logs for pods, attaching (through kubectl) to running pods, and using the kubelet’s port-forwarding functionality. These connections terminate at the kubelet’s HTTPS endpoint. By default, the apiserver does not verify the kubelet’s serving certificate, which makes the connection subject to man-in-the-middle attacks, and unsafe to run over untrusted and/or public networks.
EKS: Do Not Use Vendor-Supplied Defaults for System Passwords and Other Security Parameters EKS Level 1                   Just like custom AMIs allow you to launch images based on your standards, CloudFormation allows you to build templates (described in JSON or YAML) for entire AWS environments. These templates help eliminate human error in the build process, and can ensure your AWS environments are built according to your documented standards. You can even use the CloudFormer tool to create templates based on AWS resources you are already running. This allows rapid environment duplication, providing a likely-compliant starting place for new AWS environments.
EKS: Do not admit containers wishing to share the host IPC namespace in Pod Security Policies EKS Level 1                   A container running in the host's network namespace could access the local loopback device, and could access network traffic to and from other pods. There should be at least one admission control policy defined which does not permit containers to share the host network namespace. If you need to run containers which require access to the host's network namesapces, this should be defined in a separate policy and you should carefully check to ensure that only limited service accounts and users are given permission to use that policy.
EKS: Do not admit containers wishing to share the host network namespace in Pod Security Policies EKS Level 1                   A container running in the host's network namespace could access the local loopback device, and could access network traffic to and from other pods. There should be at least one admission control policy defined which does not permit containers to share the host network namespace. If you need to run containers which require access to the host's network namesapces, this should be defined in a separate policy and you should carefully check to ensure that only limited service accounts and users are given permission to use that policy.
EKS: Do not admit containers wishing to share the host process ID namespace in Pod Security Policies EKS Level 1                   A container running in the host's PID namespace can inspect processes running outside the container. If the container also has access to ptrace capabilities this can be used to escalate privileges outside of the container. There should be at least one admission control policy defined which does not permit containers to share the host PID namespace. If you need to run containers which require hostPID, this should be defined in a separate policy and you should carefully check to ensure that only limited service accounts and users are given permission to use that policy.
EKS: Do not admit containers with allowPrivilegeEscalation in Pod Security Policies EKS Level 1                   A container running with the allowPrivilegeEscalation flag set to true may have processes that can gain more privileges than their parent. There should be at least one admission control policy defined which does not permit containers to allow privilege escalation. The option exists (and is defaulted to true) to permit set uid binaries to run. If you have need to run containers which use set uid binaries or require privilege escalation, this should be defined in a separate policy and you should carefully check to ensure that only limited service accounts and users are given permission to use that policy.
EKS: Do not admit privileged containers in Pod Security Policies EKS Level 1                   Privileged containers have access to all Linux Kernel capabilities and devices. A container running with full privileges can do almost everything that the host can do. This flag exists to allow special use-cases, like manipulating the network stack and accessing devices. There should be at least one admission control policy defined which does not permit privileged containers. If you need to run privileged containers, this should be defined in a separate policy and you should carefully check to ensure that only limited service accounts and users are given permission to use that policy.
EKS: Do not generally permit containers with capabilities assigned beyond the default set in Pod Security Policies EKS Level 1                   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 policy 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 policy and you should carefully check to ensure that only limited service accounts and users are given permission to use that policy.
EKS: Fixing of malformed requests should be disabled EKS Level 1                   The API Server will potentially attempt to fix the update requests to pass the validation even if the requests are malformed. Malformed requests are one of the potential ways to interact with a service without legitimate information. Such requests could potentially be used to sabotage API Server responses.
EKS: Only use Strong Cryptographic Ciphers for API Server EKS Level 1                   TLS ciphers have had a number of known vulnerabilities and weaknesses, which can reduce the protection provided by them. By default Kubernetes supports a number of TLS ciphersuites including some that have security concerns, weakening the protection provided.
EKS: Only use strong Cryptographic Ciphers for Kubelet Server EKS Worker Node Level 1                   TLS ciphers have had a number of known vulnerabilities and weaknesses, which can reduce the protection provided by them. By default Kubernetes supports a number of TLS ciphersuites including some that have security concerns, weakening the protection provided.
EKS: Recommended outbound traffic to all other security groups Security Group Level 1                   Recommended outbound traffic to all other security groups
HEALTHCHECK instruction should be added to the container image in ECS Fargate cluster FARGATE ECS Level 1                   Add HEALTHCHECK instruction in your docker container images to perform the health check on running containers. 
Host devices should not be exposed directly to containers in ECS Fargate cluster FARGATE ECS Level 1                   Host devices can be directly exposed to containers at runtime. Do not directly expose host devices to containers especially for containers that are not trusted. 
Incoming container traffic should be binded to a specific host interface in ECS Fargate cluster FARGATE ECS Level 1                   By default, Docker containers can make connections to the outside world, but the outside world cannot connect to containers. Each outgoing connection will appear to originate from one of the host machine's own IP addresses. Only allow container services to be contacted through a specific external interface on the host machine. 
Linux Kernel Capabilities should be restricted within containers in ECS Fargate cluster FARGATE ECS Level 1                   By default, Docker starts containers with a restricted set of Linux Kernel Capabilities. It means that any process may be granted the required capabilities instead of root access. Using Linux Kernel Capabilities, the processes do not have to run as root for almost all the specific areas where root privileges are usually needed. 
Memory usage for container should be limited in ECS Fargate cluster FARGATE ECS Level 1                   By default, all containers on a Docker host share the resources equally. By using the resource management capabilities of Docker host, such as memory limit, you can control the amount of memory that a container may consume. 
Privileged containers should not be used in ECS Fargate cluster FARGATE ECS Level 1                   The --privileged flag gives all capabilities to the container, and it also lifts all the limitations enforced by the device cgroup controller. In other words, the container can then do almost everything that the host can do. This flag exists to allow special use-cases, like running Docker within Docker.
Privileged ports should not be mapped within containers in ECS Fargate cluster FARGATE ECS Level 1                   The TCP/IP port numbers below 1024 are considered privileged ports. Normal users and processes are not allowed to use them for various security reasons. Docker allows a container port to be mapped to a privileged port.
SELinux security options should be verified in ECS Fargate cluster FARGATE ECS Level 1                   SELinux is an effective and easy-to-use Linux application security system. It is available on quite a few Linux distributions by default such as Red Hat and Fedora. 
Sensitive host system directories should not be mounted on containers in ECS Fargate cluster FARGATE ECS Level 2                   Sensitive host system directories such as below should not be allowed to be mounted as container volumes especially in read-write mode. 
Setuid and Setgid permissions should be removed in the images in ECS Fargate cluster FARGATE ECS Level 1                   Removing setuid and setgid permissions in the images would prevent privilege escalation attacks in the containers. 
User namespace support should be enabled in ECS Fargate cluster FARGATE ECS Level 1                   Enable user namespace support in Docker daemon to utilize container user to host user re-mapping. This recommendation is beneficial where containers you are using do not have an explicit container user defined in the container image. If container images that you are using have a pre-defined non-root user, this recommendation may be skipped since this feature is still in its infancy and might give you unpredictable issues and complexities. 
live restore should be enabled. Docker Host Level 1                   The --live-restore option enables full support of daemon-less containers within Docker. It ensures that Docker does not stop containers on shutdown or restore and that it properly reconnects to the container when restarted
EKS: Do not admit containers with NET_RAW capabilities in Pod Security Policies EKS Level 1                   Containers run with a default set of capabilities as assigned by the Container Runtime. By default this can include potentially dangerous capabilities. With Docker as the container runtime the NET_RAW capability is enabled which may be misused by malicious containers. Ideally, all containers should drop this capability. There should be at least one admission control policy defined which does not permit containers with the NET_RAW capability. If you need to run containers with this capability, this should be defined in a separate policy and you should carefully check to ensure that only limited service accounts and users are given permission to use that policy.
EKS: Do not generally permit containers to be run as the root user in Pod Security Policies EKS Level 2                   Containers may run as any Linux user. Containers which run as the root user, whilst constrained by Container Runtime security features still have a escalated likelihood of container breakout. Ideally, all containers should run as a defined non-UID 0 user. There should be at least one admission control policy defined which does not permit root containers. If you need to run root containers, this should be defined in a separate policy and you should carefully check to ensure that only limited service accounts and users are given permission to use that policy.
ECS: Content Trust should be enabled For Docker ECS Level 2                   By default, all containers on a Docker host share the resources equally. By using the resource management capabilities of Docker host, such as memory limit, you can control the amount of memory that a container may consume. 
ECS: Sensitive host system directories should not be mounted on containers ECS Level 2                   Sensitive host system directories such as below should not be allowed to be mounted as container volumes especially in read-write mode. 
ECS: Linux Kernel Capabilities should be restricted within containers ECS Level 2                   By default, Docker starts containers with a restricted set of Linux Kernel Capabilities. It means that any process may be granted the required capabilities instead of root access. Using Linux Kernel Capabilities, the processes do not have to run as root for almost all the specific areas where root privileges are usually needed. 
ECS: SELinux security options should be verified ECS Level 2                   SELinux is an effective and easy-to-use Linux application security system. It is available on quite a few Linux distributions by default such as Red Hat and Fedora. 
ECS: A daemon wide custom seccomp profile should be applied ECS Level 2                   You can choose to apply your custom seccomp profile at the daemon-wide level if needed and override Docker's default seccomp profile. 
SELinux security options should be enabled if applicable ECS Level 1                   SELinux is an effective and easy-to-use Linux application security system. It is available by default on some distributions such as Red Hat and Fedora. 

 

Deprecated Policy Templates 

The following Policy Templates for AWS are deprecated in Skyhigh CASB 5.2.0. 

Policy Name Comments Web Link
Nearing Limits of EC2 Instances

max-instances: This attribute is no longer supported. The returned value does not reflect your actual vCPU limit for running On-Demand Instances. Hence deprecating the policy

For more information, see On-Demand Instance Limits in the Amazon Elastic Compute Cloud User Guide.

 

https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-account-attributes.html
  • Was this article helpful?