Checks

Using AWS managed keys does not allow for fine grained control. DynamoDB tables are encrypted by default using AWS managed encryption keys. To increase control of the encryption and control the management of factors like key rotation, use a Customer Managed Key.

By enabling encryption on EBS volumes you protect the volume, the disk I/O and any derived snapshots from compromise if intercepted.

Encryption using AWS keys provides protection for your EBS volume. To increase control of the encryption and manage factors like rotation use customer managed keys.

IMDS v2 (Instance Metadata Service) introduced session authentication tokens which improve security when talking to IMDS.

By default <code>aws_instance</code> resource sets IMDS session auth tokens to be optional.

To fully protect IMDS you need to enable session tokens by using <code>metadata_options</code> block and its <code>http_tokens</code> variable set to <code>required</code>.

EC2 instance data is used to pass start up information into the EC2 instance. This userdata must not contain access key credentials. Instead use an IAM Instance Profile assigned to the instance to grant access to other AWS Services.

Repository image scans should be enabled to ensure vulnerable software can be discovered and remediated as soon as possible.

ECR images should be set to IMMUTABLE to prevent code injection through image mutation. This can be done by setting <code>image_tag_mutability</code> to <code>IMMUTABLE</code>

Allowing public access to the ECR repository risks leaking sensitive of abusable information

Images in the ECR repository are encrypted by default using AWS managed encryption keys. To increase control of the encryption and control the management of factors like key rotation, use a Customer Managed Key.

Cloudwatch Container Insights provide more metrics and logs for container based applications and micro services.

ECS task definitions that have volumes using EFS configuration should explicitly enable in transit encryption to prevent the risk of data loss due to interception.

You should not make secrets available to a user in plaintext in any scenario. Secrets can instead be pulled from a secure secret storage system by the service requiring them.

If your organization is subject to corporate or regulatory policies that require encryption of data and metadata at rest, we recommend creating a file system that is encrypted at rest, and mounting your file system using encryption of data in transit.

By default cluster control plane logging is not turned on. Logging is available for audit, api, authenticator, controllerManager and scheduler. All logging should be turned on for cluster control plane.

EKS cluster resources should have the encryption_config block set with protection of the secrets resource.

EKS clusters are available publicly by default, this should be explicitly disabled in the vpc_config of the EKS cluster resource.

EKS Clusters have public access cidrs set to 0.0.0.0/0 by default which is wide open to the internet. This should be explicitly set to a more specific private CIDR range

Amazon ES exposes four Elasticsearch logs through Amazon CloudWatch Logs: error logs, search slow logs, index slow logs, and audit logs. Search slow logs, index slow logs, and error logs are useful for troubleshooting performance and stability issues. Audit logs track user activity for compliance purposes. All the logs are disabled by default.

Traffic flowing between Elasticsearch nodes should be encrypted to ensure sensitive data is kept private.

Data stored within an Elasticache replication node should be encrypted to ensure sensitive data is kept private.

Plain HTTP is unencrypted and human-readable. This means that if a malicious actor was to eavesdrop on your connection, they would be able to see all of your data flowing back and forth. You should use HTTPS, which is HTTP over an encrypted (TLS) connection, meaning eavesdroppers cannot read your traffic.

You should not use outdated/insecure TLS versions for encryption. You should be using TLS v1.2+.

You should ensure your Elasticsearch data is encrypted at rest to help prevent sensitive information from being read by unauthorised users.

Security groups and security group rules should include a description for auditing purposes. Simplifies auditing, debugging, and managing security groups.