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. |
| CKV2_AWS_5 | Ensure that Security Groups are attached to another resource | Security groups are created and attached to resources as part of the workshop infrastructure setup. This warning may appear during intermediate Terraform states but resolves once all resources are provisioned. In production, ensure security groups are properly attached to prevent unused resources. |
| CKV_AWS_260 | Ensure no security groups allow ingress from 0.0.0.0:0 to port 80 | GitLab and ALB security groups allow HTTP access from anywhere for demonstration purposes, enabling easy access to the GitLab web interface and load balancer. For production environments, restrict access to specific IP ranges or use VPN/bastion hosts as documented in the README security warnings. |
| CKV_AWS_24 | Ensure no security groups allow ingress from 0.0.0.0:0 to port 22 | GitLab EC2 instance allows SSH access from anywhere for workshop troubleshooting and setup purposes. This enables participants to access the instance if needed during the learning process. For production, restrict SSH access to specific IP ranges and use AWS Systems Manager Session Manager instead. |
| CKV_AWS_23 | Ensure every security group and rule has a description | Some security group rules lack detailed descriptions for simplicity in the demo environment. In production deployments, add comprehensive descriptions to all security group rules for better documentation and compliance requirements. |
| CKV_AWS_261 | Ensure HTTP HTTPS Target group defines Healthcheck | ALB target groups use default health check settings for demonstration simplicity. The default health checks are sufficient for the demo applications (nginx-hello). For production workloads, configure custom health checks appropriate for your application requirements. |
| CKV2_AWS_20 | Ensure that ALB redirects HTTP requests into HTTPS ones | ALB is configured for HTTP access to simplify the workshop setup and avoid SSL certificate management complexity. This allows easy access to demo applications without certificate configuration. For production, implement HTTPS redirection and proper SSL/TLS certificates. |
| CKV_AWS_131 | Ensure that ALB drops HTTP headers | ALB retains HTTP headers for demonstration purposes to maintain compatibility with demo applications and simplify troubleshooting. For production environments, configure header dropping based on security requirements and application needs. |
| CKV2_AWS_28 | Ensure public facing ALB are protected by WAF | ALB is not protected by AWS WAF to reduce complexity and cost in the demonstration environment. The demo applications don't require WAF protection for learning purposes. For production deployments, implement AWS WAF to protect against common web exploits and attacks. |
| CKV_AWS_103 | Ensure that load balancer is using at least TLS 1.2 | ALB uses HTTP instead of HTTPS for demonstration simplicity, avoiding SSL certificate setup complexity. This allows immediate access to demo applications without certificate management. For production, configure TLS 1.2 or higher with proper SSL certificates. |
| CKV_AWS_150 | Ensure that Load Balancer has deletion protection enabled | ALB deletion protection is disabled to allow easy cleanup of workshop resources without additional steps. This enables participants to cleanly remove all resources at the end of the workshop. For production environments, enable deletion protection to prevent accidental load balancer deletion. |
| CKV_AWS_2 | Ensure ALB protocol is HTTPS | ALB uses HTTP protocol for demonstration simplicity and to avoid SSL certificate management complexity during the workshop. This allows immediate access to applications without certificate setup. For production deployments, use HTTPS protocol with valid SSL certificates. |
| CKV_AWS_91 | Ensure the ELBv2 (Application/Network) has access logging enabled | ALB access logging is disabled to reduce complexity and avoid S3 bucket setup for log storage in the demonstration environment. For production deployments, enable access logging to monitor traffic patterns and troubleshoot issues. |
| CKV_AWS_274 | Disallow IAM roles, users, and groups from using the AWS AdministratorAccess policy | GitLab EC2 instance uses broad IAM permissions to enable workshop functionality including EKS cluster management, ALB operations, and resource provisioning. This simplifies the workshop setup by avoiding complex permission configurations. For production, implement least privilege access with specific permissions for required operations only. |
This project uses Semgrep for additional security scanning. The following configurations are documented for transparency:
| Rule | Details | Reasons |
|---|---|---|
| jquery-insecure-selector | User controlled data in a $(...) is an anti-pattern that can lead to XSS vulnerabilities |
This infrastructure project contains no jQuery code. The rule triggers false positives on shell script command substitution patterns like $(aws sts get-caller-identity) in automation scripts. The rule is configured in .semgrep.yml to exclude shell scripts, infrastructure files, and documentation where these bash patterns legitimately appear. For projects with actual jQuery usage, this rule should remain active to prevent XSS vulnerabilities. |