Infrastructure as Code (IaC) has transformed how you deploy and manage cloud infrastructure. Tools like Azure Resource Manager, AWS CloudFormation, Docker, Kubernetes, Ansible, and Terraform have made deploying infrastructure faster and more scalable. However, they’ve also introduced a new set of security challenges.
In recent years, there have been numerous security incidents caused by IaC misconfigurations. These include:
- Open Ports and Weak Security Groups: Exposing cloud resources to the public internet.
- Hardcoded Secrets: Credentials, API keys, or sensitive data embedded in code.
- Overly Permissive Policies: Granting unnecessary privileges to users or services.
- Missing Resource Limits: Allowing unrestricted use of cloud resources, leading to potential outages or abuse.
The consequences of these issues can be severe, from data breaches to financial loss and reputational damage. Moreover when Code GenAI is used in order to produce those artifacts.
Code GenAI is a great help to start code artifacts and produce boilerplate code, but it also needs to be reviewed to avoid the introduction of unexpected issues and vulnerabilities.
Fortunately, there are tools that can help identify critical vulnerabilities early in development.
From the SonarQube Cloud telemetry, I've gathered the most hit issues regarding IaC, with more than 6 million hits in total across all projects analyzed.
In this article, I focus on Azure, CloudFormation, Docker, Kubernetes, Ansible and Terraform as examples of IaC issues. I highlight each critical issue, its risks, and how to fix it.
As a bonus chapter, you can see the result of an experiment with Code GenAI using different providers to generate Kubernetes artifacts and check if they are as clean and secure as we expect.
Let's start with a list of examples of all the IaC artifacts covered in this article (and supported by SonarQube).
Azure Resource Manager
Restrict Public Access to Resources
Problem: Allowing unrestricted public access to Azure resources (e.g., Blob Storage) exposes them to unauthorized users.
Solution: Using publicNetworkAccess to control access to resources.
{ "type": "Microsoft.Web/sites", "apiVersion": "2020-12-01", "name": "example-site", "properties": { "siteConfig": { "publicNetworkAccess": "Disabled" } } } AWS CloudFormation
1. Ensure S3 Buckets Are Private
Problem: Publicly accessible S3 buckets can lead to data leaks.
Solution: Set the bucket's AccessControl to Private.
Resources: MyBucket: Type: AWS::S3::Bucket Properties: AccessControl: Private 2. Apply Least Privilege to IAM Roles
Problem: Granting broad permissions creates unnecessary security risks.
Solution: Limit actions and resources to only what’s required.
Resources: # Update Lambda code lambdaUpdatePolicy: Type: AWS::IAM::ManagedPolicy Properties: ManagedPolicyName: lambdaUpdatePolicy PolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Action: - lambda:UpdateFunctionCode Resource: "arn:aws:lambda:us-east-2:123456789012:function:my-function:1" Docker
Avoid Running Containers as Root
Problem: Running containers as root increases the risk of privilege escalation.
Solution: Create and use a non-root user in your Dockerfile.
FROM alpine RUN addgroup -S nonroot \ && adduser -S nonroot -G nonroot USER nonroot ENTRYPOINT ["id"] Kubernetes
1. Don’t Run Privileged Pods
Problem: Running containers in privileged mode can reduce the resilience of a cluster in the event of a security incident because it weakens the isolation between hosts and containers.
Solution: Disable privileged mode in your pod specification.
apiVersion: v1 kind: Pod metadata: name: example spec: containers: - name: web image: nginx ports: - name: web containerPort: 80 protocol: TCP securityContext: privileged: false 2. Define Resource Requests and Limits
Problem: Allowing pods to use unlimited resources can destabilize the cluster.
Solution: Specify resource requests and limits for containers.
apiVersion: v1 kind: Pod metadata: name: resource-limited-pod spec: containers: - name: app image: myapp:latest resources: requests: memory: "256Mi" cpu: "0.5" limits: memory: "512Mi" cpu: "1" 3. Specific version tag for image should be used
Problem: When a container image is not tagged with a specific version, it is referred to as latest. This means that every time the image is built, deployed, or run, it will always use the latest version of the image.
Solution: To avoid these issues, it is recommended to use specific version tags for container images.
apiVersion: v1 kind: Pod metadata: name: example spec: containers: - name: nginx image: nginx:1.14.2 - name: nginx image: nginx@sha256:b0ad43f7ee5edbc0effbc14645ae7055e21bc1973aee5150745632a24a752661 Terraform
Allowing public network access to cloud resources is security-sensitive
Problem: Enabling public network access to cloud resources can affect an organization’s ability to protect its data or internal operations from data theft or disruption.
Solution: Use private networks and VPC peering or other secure communication tunnels to communicate with other cloud components.
resource "google_compute_instance" "example" { network_interface { network = google_compute_network.vpc_network_example.name } } Ansible
1. Server certificates should be verified
Problem: This vulnerability makes it possible for encrypted communication to be intercepted.
Solution: Ensure playbooks do not bypass certificate validation.
- name: Example playbook hosts: server tasks: - name: Retrieve a web page ansible.builtin.uri: url: https://www.example.com validate_certs: true return_content: true 2. Loose POSIX permissions
Problem: Files with overly permissive POSIX permissions (e.g., 777) grant unnecessary read, write, or execute access to unauthorized users.
Solution: Ensure playbooks explicitly set restrictive permissions on sensitive files.
- name: My deployment hosts: all tasks: - name: Create /etc/demo with permissions ansible.builtin.file: path: /etc/demo state: directory mode: '0770' - name: Copy demo3.conf and set symbolic permissions ansible.builtin.copy: src: /files/demo.conf dest: /etc/demo/demo.conf mode: 'g=r,u+w,o=' Secrets management
Keys and passwords being disclosed
Problem: Secret leaks often occur when sensitive authentication data is stored with an application's source code. This is one example (OVH keys, the most hit issue) but the issue extends to several platforms.
props.set("ovh-key", "EXEgWIz07P0HYwtQDs7cNIqCiQaWSuHF") Solution:
props.set("ovh-key", System.getenv("OVH_KEY")) Experimenting with Code GenAI and IaC
In order to see how accurate is Code GenAI for IaC artifacts, I've done an experiment with an AI application made in Java using Qarkus. You can find the source code here.
Using my IDE I've asked two different code assistants to produce the Kubernetes Deployment yaml file to deploy the application.
I've used Github Copilot and Amazon Q as code assistants.
Let's see the results.
Github Copilot
apiVersion: apps/v1 kind: Deployment metadata: name: pingpong-ai-deployment labels: app: pingpong-ai spec: replicas: 3 selector: matchLabels: app: pingpong-ai template: metadata: labels: app: pingpong-ai spec: containers: - name: pingpong-ai-container image: your-docker-repo/pingpong-ai:latest ports: - containerPort: 8080 env: - name: QUARKUS_PROFILE value: prod - name: JAVA_OPTS value: "-Dquarkus.http.host=0.0.0.0" volumeMounts: - name: config-volume mountPath: /deployments/config volumes: - name: config-volume configMap: name: pingpong-ai-config --- apiVersion: v1 kind: Service metadata: name: pingpong-ai-service spec: selector: app: pingpong-ai ports: - protocol: TCP port: 80 targetPort: 8080 type: LoadBalancer It has been smart enough to generate a Service and a volume. But, not all is shiny. SonarQube for IDE has detected 6 issues :
Amazon Q
apiVersion: apps/v1 kind: Deployment metadata: name: my-application labels: app: my-application spec: replicas: 3 # Number of pod replicas you want to run selector: matchLabels: app: my-application template: metadata: labels: app: my-application spec: containers: - name: my-application image: your-registry/your-image:tag # Replace with your image ports: - containerPort: 8080 # Replace with your application port resources: requests: cpu: "200m" memory: "256Mi" limits: cpu: "500m" memory: "512Mi" env: - name: ENVIRONMENT value: "production" # Add any environment variables your application needs livenessProbe: httpGet: path: /health # Replace with your health check endpoint port: 8080 initialDelaySeconds: 30 periodSeconds: 10 readinessProbe: httpGet: path: /health # Replace with your health check endpoint port: 8080 initialDelaySeconds: 5 periodSeconds: 10 This output is way cleaner and of higher quality than the previous one, and SonarQube for IDE has detected only 2 issues. However, it doesn't provide a Service or a volume for configuration files.
In both cases, it's been fast and without the problem of typing errors (wrong attribute name, wrong number of spaces, tabs, etc..)., but as with any code generated by AI, it needed a review phase to detect issues that are not always obvious in order to submit good-quality code to our repository and lead to smooth Pull Request reviews.
Conclusion
IaC enables teams to automate and scale infrastructure efficiently, but with great power comes great responsibility. Misconfigurations, hardcoded secrets, and overly permissive access controls are common mistakes that can lead to serious security vulnerabilities.
By following best practices and leveraging tools like SonarQube, developers can identify and resolve critical security issues early in the development process.
More than just security, maintaining code quality in IaC is essential. Well-structured, maintainable IaC ensures teams can quickly adapt to new requirements and maintain a robust, secure infrastructure.
Combining high-quality code with automated tooling is the key to avoiding costly security mishaps. SonarQube has rules to check all these issues in Azure Resource Manager, Docker, Kubernetes, CloudFormation, Terraform, Ansible and Secrets in general.
Top comments (0)