Our code is continuously scanned using Checkov. The following security considerations are documented for transparency:
| Checks | Details | Reasons |
|---|---|---|
| CKV_TF_1 | Ensure Terraform module sources use a commit hash | For easy experimentation, we set version of module, instead of setting a commit hash. Consider implementing a commit hash in a production cluster. Read more on why we need to set commit hash for modules here. |
| CKV_SECRET_6 | Base64 High Entropy String | This check flags Base64-encoded, high-entropy strings, which are typical for Kubernetes secrets (all values under the data field must be Base64-encoded). While this is a best practice for storing sensitive data, it results in expected false positives during scans. We acknowledge this is required for Kubernetes, and secrets are managed securely outside of version control. |
| CKV2_K8S_6 | Minimize the admission of pods which lack an associated NetworkPolicy | All Pod to Pod communication is allowed by default for easy experimentation in this project. Amazon VPC CNI now supports Kubernetes Network Policies to secure network traffic in kubernetes clusters |
| CKV_K8S_8 | Liveness Probe Should be Configured | For easy experimentation, no health checks is to be performed against the container to determine whether it is alive or not. Consider implementing health checks in a production cluster. |
| CKV_K8S_9 | Readiness Probe Should be Configured | For easy experimentation, no health checks is to be performed against the container to determine whether it is alive or not. Consider implementing health checks in a production cluster. |
| CKV_K8S_11 | CPU limits should be set | For easy experimentation, CPU limits are not configured on containers. In production environments, consider setting CPU limits to prevent resource exhaustion and ensure fair resource allocation. Learn more about resource management. |
| CKV_K8S_22 | Use read-only filesystem for containers where possible | We've made an exception for the workloads that requires are Read/Write file system. Configure your images with read-only root file system |
| CKV_K8S_23 | Minimize the admission of root containers | This project uses default root container configurations for demonstration purposes. While this doesn't follow security best practices, it ensures compatibility with demo images. For production, configure runAsNonRoot: true and follow guidance on building images with specified user ID. |
| CKV_K8S_35 | Prefer using secrets as files over secrets as environment variables | For demonstration purposes, some secrets are passed as environment variables for simplicity. In production environments, consider mounting secrets as files using Kubernetes secret volumes instead of environment variables to reduce the risk of accidental exposure. Learn more about secret best practices. |
| CKV_K8S_37 | Minimize the admission of containers with capabilities assigned | For easy experimentation, we've made exception for the workloads that requires added capability. For production purposes, we recommend capabilities field that allows granting certain privileges to a process without granting all the privileges of the root user. |
| CKV_K8S_40 | Containers should run as a high UID to avoid host conflict | We've used publicly available container images in this project for customers' easy access. For test purposes, the container images user id are left intact. See how to define UID. |
| CKV_AWS_51 | Ensure ECR Image Tags are immutable | For demonstration and development flexibility, ECR repositories use mutable image tags to allow easy updates and experimentation with container images. In production environments, consider enabling image tag immutability to prevent accidental overwrites and ensure deployment consistency. |
| CKV_AWS_184 | Ensure resource is encrypted by KMS using a customer managed Key (CMK) | Uses AWS managed keys for simplicity in demo environments, reducing setup complexity and key management overhead. For production environments, implement customer-managed KMS keys for enhanced security control and compliance requirements. |
| CKV_DOCKER_2 | Ensure that HEALTHCHECK instructions have been added to container images | Container images lack explicit HEALTHCHECK instructions for demonstration simplicity, relying on Kubernetes liveness/readiness probes instead. In production environments, consider adding HEALTHCHECK instructions to Dockerfiles for better container health monitoring at the Docker layer. |
| CKV_DOCKER_3 | Ensure that a user for the container has been created | Containers run as default root user for compatibility with demo images and to avoid permission issues during experimentation. For production environments, create and use non-root users in container images following security best practices to minimize attack surface. |