> ## Documentation Index
> Fetch the complete documentation index at: https://docs.codeant.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Kubernetes

<AccordionGroup>
  <Accordion title="Mounting sensitive file system paths is security-sensitive">
    <div class="literalblock">
      <div class="content">
        <pre>system paths can lead to information disclosure and compromise of the host systems.</pre>
      </div>
    </div>

    <div class="paragraph">
      <p>System paths can contain sensitive information like configuration files or cache files.
      Those might be used by attackers to expand permissions or to collect information for further attacks.
      System paths can also contain binaries and scripts that might be executed by the host system periodically.
      A compromised or rogue container with access to sensitive files could endanger the integrity of the whole Kubernetes cluster.</p>
    </div>

    <CodeGroup>
      ```kubernetes Bad theme={null}
      apiVersion: v1
      kind: Pod
      metadata:
      name: test
      spec:
      containers:
      - image: k8s.gcr.io/test-webserver
      name: test-container
      volumeMounts:
      - mountPath: /data
        name: test-volume
      volumes:
      - name: test-volume
      hostPath:
        path: /etc # Sensitive
      ```

      ```kubernetes Fix theme={null}
      apiVersion: v1
      kind: Pod
      metadata:
      name: test
      spec:
      containers:
      - image: k8s.gcr.io/test-webserver
      name: test-container
      volumeMounts:
      - mountPath: /data
        name: test-volume
      volumes:
      - name: test-volume
      hostPath:
        path: /mnt/nfs
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Exposing administration services is security-sensitive">
    <div class="literalblock">
      <div class="content">
        <pre>services can lead to unauthorized access to pods or escalation of privileges inside pods.</pre>
      </div>
    </div>

    <div class="paragraph">
      <p>A port that is commonly used for administration services is open or marked as being open. Administration services like SSH might contain vulnerabilities, hard-coded credentials, or other security issues that increase the attack surface of a Kubernetes deployment.
      Even if the ports of the services do not get forwarded to the host system, by default they are reachable from other containers in the same network. A malicious actor that gets access to one container could use such services to escalate access and privileges.</p>
    </div>

    <div class="paragraph">
      <p>If the administrative port is forwarded through a load balancer, then in most cases this port should be removed from the configuration to make sure it is not reachable externally.
      Setting the containerPort on a pod is purely informative. Therefore, removing the property is not sufficient to be secure. The port is still open and the service is still accessible.</p>
    </div>

    <div class="paragraph">
      <p>In both cases, it is most secure to not start any administrative services in deployments. Instead, try to access the required information using Kubernetes’s own administrative tools. For example, to execute code inside a container, <code>kubectl exec</code> can be used. If the administration service is included to access logs, Kubernetes suggests using a sidecar container with a logging agent.</p>
    </div>

    <CodeGroup>
      ```kubernetes Bad theme={null}
      apiVersion: v1
      kind: Pod
      metadata:
      labels:
          app: example_app
      spec:
      containers:
      - name: applications
        image: my_image_with_ssh
        ports:
        - containerPort: 22  # NonCompliant: Merely informative, removing this property does not
                             # close port 22.
      ```

      ```kubernetes Fix theme={null}
      apiVersion: apps/v1
      kind: Service
      metadata:
      name: example_lb
      spec:
      type: LoadBalancer
      ports:
      - port: 8022
        targetPort: 22  # Compliant
      selector:
      app: example_app
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="CPU requests should be specified">
    <div class="paragraph">
      <p>Without a CPU request, a container can potentially be scheduled on a node where
      there are not enough resources for it. This can lead to unpredictable behavior of the container and the node itself.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```kubernetes Bad theme={null}
      apiVersion: v1
      kind: Pod
      metadata:
      name: example
      spec:
      containers:
      - name: web # Noncompliant
        image: nginx
      ```

      ```kubernetes Fix theme={null}
      apiVersion: v1
      kind: Pod
      metadata:
      name: example
      spec:
      containers:
      - name: web
        image: nginx
        resources:
          requests:
            cpu: 0.5
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Setting capabilities is security-sensitive">
    <div class="paragraph">
      <p>n lead to privilege escalation and container escapes.</p>
    </div>

    <div class="paragraph">
      <p>Linux capabilities allow you to assign narrow slices of \`root's permissions to processes. A thread with capabilities bypasses the normal kernel security checks to execute high-privilege actions such as mounting a device to a directory, without requiring additional root privileges.</p>
    </div>

    <div class="paragraph">
      <p>In a container, capabilities might allow to access resources from the host system which can result in container escapes. For example, with the capability SYS\_ADMIN\` an attacker might be able to mount devices from the host system inside of the container.</p>
    </div>

    <CodeGroup>
      ```kubernetes Bad theme={null}
      apiVersion: v1
      kind: Pod
      metadata:
      name: example
      spec:
      containers:
      - image: k8s.gcr.io/test-webserver
      name: test-container
      securityContext:
        capabilities:
          add: ["SYS_ADMIN"] # Sensitive
      ```

      ```kubernetes Fix theme={null}
      apiVersion: v1
      kind: Pod
      metadata:
      name: example
      spec:
      containers:
      - image: k8s.gcr.io/test-webserver
      name: test-container
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Ensure whitespace in-between braces in template directives">
    <div class="paragraph">
      <p>The absence of whitespace in template directives in Helm can lead to several issues:</p>
    </div>

    <div class="paragraph">
      <p><strong>Readability</strong>: Code is read more often than it is written.
      When template directives are tightly packed without whitespaces, it can be challenging to distinguish between the braces and the content inside.
      This can slow down the process of understanding the code, especially for those who are new to the codebase.</p>
    </div>

    <div class="paragraph">
      <p><strong>Maintainability</strong>: Hard-to-read code is also hard to maintain.
      If a developer struggles to understand what a piece of code does due to poor formatting, they may introduce bugs when they try to modify it.</p>
    </div>

    <div class="paragraph">
      <p>In summary, not having a whitespace after the opening brace and before the closing brace in template directives can make the code harder to read, understand, and maintain.</p>
    </div>

    <CodeGroup>
      ```kubernetes Bad theme={null}
      apiVersion: v1
      kind: Pod
      metadata:
      name: {{.Values.podName}} # Noncompliant
      spec:
      containers:
      - name: {{-.Values.containerName-}} # Noncompliant
      ```

      ```kubernetes Fix theme={null}
      apiVersion: v1
      kind: Pod
      metadata:
      name: {{ .Values.podName }}
      spec:
      containers:
      - name: {{- .Values.containerName -}}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Allowing process privilege escalations is security-sensitive">
    <div class="paragraph">
      <p>ege escalations exposes the Pod to attacks that exploit
      setuid binaries.</p>
    </div>

    <div class="paragraph">
      <p>This field directly controls whether the no\_new\_privs flag is set in the
      container process.
      When this flag is enabled, binaries configured with setuid or setgid bits
      cannot change their runtime uid or gid: Potential attackers must rely on other
      privilege escalation techniques to successfully operate as root on the Pod.</p>
    </div>

    <div class="paragraph">
      <p>Depending on how resilient the Kubernetes cluster and Pods are, attackers can
      extend their attack to the cluster by compromising the nodes from which the
      cluster started the Pod.</p>
    </div>

    <div class="paragraph">
      <p>The allowPrivilegeEscalation field should not be set to true unless the Pod’s
      risks related to setuid or setgid bits have been mitigated.</p>
    </div>

    <CodeGroup>
      ```kubernetes Bad theme={null}
      apiVersion: v1
      kind: Pod
      metadata:
      name: example
      spec:
      containers:
      - name: web
        image: nginx
        ports:
          - name: web
            containerPort: 80
            protocol: TCP
        securityContext:
          allowPrivilegeEscalation: true # Sensitive
      ```

      ```kubernetes Fix theme={null}
      apiVersion: v1
      kind: Pod
      metadata:
      name: example
      spec:
      containers:
      - name: web
        image: nginx
        ports:
          - name: web
            containerPort: 80
            protocol: TCP
        securityContext:
          allowPrivilegeEscalation: false
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Storage limits should be enforced">
    <div class="paragraph">
      <p>Ephemeral storage is a type of storage that is temporary and non-persistent,
      meaning it does not retain data once the process is terminated. In the context
      of Kubernetes, ephemeral storage is used for storing temporary files that a
      running container can write and read.</p>
    </div>

    <div class="paragraph">
      <p>The issue at hand pertains to the creation of a container without any defined
      limits for this ephemeral storage. This means that the container can potentially
      consume as much ephemeral storage as is available on the node where it is
      running.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```kubernetes Bad theme={null}
      apiVersion: v1
      kind: Pod
      metadata:
      name: example
      spec:
      containers:
      - name: web # Noncompliant
        image: nginx
        volumeMounts:
          - name: ephemeral
            mountPath: "/tmp"
      ```

      ```kubernetes Fix theme={null}
      apiVersion: v1
      kind: Pod
      metadata:
      name: example
      spec:
      containers:
      - name: web
        image: nginx
        resources:
          limits:
            ephemeral-storage: "2Gi"
        volumeMounts:
          - name: ephemeral
            mountPath: "/tmp"
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Environment variables for a container should not be duplicated">
    <div class="paragraph">
      <p>If an environment variable of a container is declared multiple times with different values, it can become unclear which value will be used by the application and can lead to unpredictable behavior. Also, if an issue arises related to the environment variable, debugging can be challenging. The problem could be due to the overwritten variable, but this might take time to be noticeable.</p>
    </div>

    <CodeGroup>
      ```kubernetes Bad theme={null}
      apiVersion: v1
      kind: Pod
      metadata:
      name: env-example
      spec:
      containers:
      - name: nginx
      image: nginx:1.7.9
      env:
      - name: VAR1 # Noncompliant
        value: "value1"
      - name: VAR1 # Noncompliant
        value: "value2"
      ```

      ```kubernetes Fix theme={null}
      apiVersion: v1
      kind: Pod
      metadata:
      name: env-example
      spec:
      containers:
      - name: nginx
      image: nginx:1.7.9
      env:
      - name: VAR1
        value: "value1"
      - name: VAR2
        value: "value2"
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Memory requests should be specified">
    <div class="paragraph">
      <p>Without a memory request, a container can potentially be scheduled on a node where
      there are not enough resources for it. This can lead to unpredictable behavior of the container and the node itself.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```kubernetes Bad theme={null}
      apiVersion: v1
      kind: Pod
      metadata:
      name: example
      spec:
      containers:
      - name: web # Noncompliant
        image: nginx
      ```

      ```kubernetes Fix theme={null}
      apiVersion: v1
      kind: Pod
      metadata:
      name: example
      spec:
      containers:
      - name: web
        image: nginx
        resources:
          requests:
            memory: 100Mi
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Running containers in privileged mode is security-sensitive">
    <div class="paragraph">
      <p>rivileged mode can reduce the resilience of a cluster in
      the event of a security incident because it weakens the isolation between hosts
      and containers.</p>
    </div>

    <div class="paragraph">
      <p>Process permissions in privileged containers are essentially the same as root
      permissions on the host. If these processes are not protected by robust
      security measures, an attacker who compromises a root process on a Pod’s host
      is likely to gain the ability to pivot within the cluster.
      Depending on how resilient the cluster is, attackers can extend their attack to
      the cluster by compromising the nodes from which the cluster launched the
      process.</p>
    </div>

    <CodeGroup>
      ```kubernetes Bad theme={null}
      apiVersion: v1
      kind: Pod
      metadata:
      name: example
      spec:
      containers:
      - name: web
        image: nginx
        ports:
          - name: web
            containerPort: 80
            protocol: TCP
        securityContext:
          privileged: true # Sensitive
      ```

      ```kubernetes Fix theme={null}
      apiVersion: v1
      kind: Pod
      metadata:
      name: example
      spec:
      containers:
      - name: web
        image: nginx
        ports:
          - name: web
            containerPort: 80
            protocol: TCP
        securityContext:
          privileged: false
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Memory limits should be enforced">
    <div class="paragraph">
      <p>A memory limit is a configuration that sets the maximum amount of memory that a
      container can use. It is part of the resource management functionality of
      Kubernetes, which allows for the control and allocation of computational
      resources to containers.</p>
    </div>

    <div class="paragraph">
      <p>When a memory limit is set for a container, Kubernetes ensures that the
      container does not exceed the specified limit. If a container tries to use more
      memory than its limit, the system will reclaim the excess memory, which could
      lead to termination of processes within the container.</p>
    </div>

    <div class="paragraph">
      <p>Without a memory limit, a container can potentially consume all available memory
      on a node, which can lead to unpredictable behavior of the container or the node
      itself. Therefore, defining a memory limit for each container is a best practice
      in Kubernetes configurations. It helps in managing resources effectively and
      ensures that a single container does not monopolize the memory resources of a
      node.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```kubernetes Bad theme={null}
      apiVersion: v1
      kind: Pod
      metadata:
      name: example
      spec:
      containers:
      - name: web # Noncompliant
        image: nginx
      ```

      ```kubernetes Fix theme={null}
      apiVersion: v1
      kind: Pod
      metadata:
      name: example
      spec:
      containers:
      - name: web
        image: nginx
        resources:
          limits:
            memory: 100Mi
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="CPU limits should be enforced">
    <div class="paragraph">
      <p>A CPU limitation for a container is a specified boundary or restriction that
      determines the maximum amount of CPU resources that a container can utilize. It
      is a part of resource management in a containerized environment, and it is set
      to ensure that a single container does not monopolize the CPU resources of the
      host machine.</p>
    </div>

    <div class="paragraph">
      <p>CPU limitations are important for maintaining a balanced and efficient system.
      They help in distributing resources fairly among different containers, ensuring
      that no single container can cause a system-wide slowdown by consuming more than
      its fair share of CPU resources.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```kubernetes Bad theme={null}
      apiVersion: v1
      kind: Pod
      metadata:
      name: example
      spec:
      containers:
      - name: web # Noncompliant
        image: nginx
      ```

      ```kubernetes Fix theme={null}
      apiVersion: v1
      kind: Pod
      metadata:
      name: example
      spec:
      containers:
      - name: web
        image: nginx
        resources:
          limits:
            cpu: 0.5
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Storage requests should be specified">
    <div class="paragraph">
      <p>Without a storage request, a container can potentially be scheduled on a node where
      there are not enough resources for it. This can lead to unpredictable behavior of the container and the node itself.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```kubernetes Bad theme={null}
      apiVersion: v1
      kind: Pod
      metadata:
      name: example
      spec:
      containers:
      - name: web # Noncompliant
        image: nginx
        volumeMounts:
          - name: ephemeral
            mountPath: "/tmp"
      ```

      ```kubernetes Fix theme={null}
      apiVersion: v1
      kind: Pod
      metadata:
      name: example
      spec:
      containers:
      - name: web
        image: nginx
        resources:
          requests:
            ephemeral-storage: "2Gi"
        volumeMounts:
          - name: ephemeral
            mountPath: "/tmp"
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Allowing command execution is security sensitive">
    <div class="paragraph">
      <p>Allowing command execution (exec) for roles in a Kubernetes cluster can pose a significant security risk. This is because it provides the user with the ability to execute arbitrary commands within a container, potentially leading to unauthorized access or data breaches.</p>
    </div>

    <div class="paragraph">
      <p>In a production Kubernetes cluster, exec permissions are typically unnecessary due to the principle of least privilege, which suggests that a user or process should only have the minimum permissions necessary to perform its function. Additionally, containers in production are often treated as immutable infrastructure, meaning they should not be changed once deployed. Any changes should be made to the container image, which is then used to deploy a new container.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```kubernetes Bad theme={null}
      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
      namespace: default
      name: example-role
      rules:
      - apiGroups: [""]
      resources: ["pods"]
      verbs: ["get"]
      - apiGroups: [""]
      resources: ["pods/exec"] # Noncompliant
      verbs: ["create"]
      ```

      ```kubernetes Fix theme={null}
      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
      namespace: default
      name: example-role
      rules:
      - apiGroups: [""]
      resources: ["pods"]
      verbs: ["get"]
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Service account tokens should not be mounted in pods">
    <div class="paragraph">
      <p>Service account tokens are Kubernetes secrets created automatically to authenticate applications running inside pods to the API server. If a pod is compromised, an attacker could use this token to gain access to other resources in the cluster.</p>
    </div>

    <div class="paragraph">
      <p>For example, they could create new pods, modify existing ones, or even delete critical system pods, depending on the permissions associated with the service account.</p>
    </div>

    <div class="paragraph">
      <p>Therefore, it’s recommended to disable the automounting of service account tokens when it’s not necessary for the application running in the pod.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```kubernetes Bad theme={null}
      apiVersion: v1
      kind: Pod
      metadata:
      name: example-pod
      spec: # Noncompliant
      containers:
      - name: example-pod
      image: nginx:1.25.3
      ```

      ```kubernetes Fix theme={null}
      apiVersion: v1
      kind: Pod
      metadata:
      name: example-pod
      spec:
      containers:
      - name: example-pod
      image: nginx:1.25.3
      automountServiceAccountToken: false
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Exposing Docker sockets is security-sensitive">
    <div class="literalblock">
      <div class="content">
        <pre>can lead to compromise of the host systems.</pre>
      </div>
    </div>

    <div class="paragraph">
      <p>The Docker daemon provides an API to access its functionality, for example through a UNIX domain socket.
      Mounting the Docker socket into a container allows the container to control the Docker daemon of the host system, resulting in full access over the whole system.
      A compromised or rogue container with access to the Docker socket could endanger the integrity of the whole Kubernetes cluster.</p>
    </div>

    <CodeGroup>
      ```kubernetes Bad theme={null}
      apiVersion: v1
      kind: Pod
      metadata:
      name: test
      spec:
      containers:
      - image: k8s.gcr.io/test-webserver
      name: test-container
      volumeMounts:
      - mountPath: /var/run/docker.sock
        name: test-volume
      volumes:
      - name: test-volume
      hostPath:
        path: /var/run/docker.sock # Sensitive
        type: Socket
      ```

      ```kubernetes Fix theme={null}
      apiVersion: v1
      kind: Pod
      metadata:
      name: test
      spec:
      containers:
      - image: k8s.gcr.io/test-webserver
      name: test-container
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Wildcards should not be used to define RBAC permissions">
    <div class="paragraph">
      <p>Using wildcards when defining Role-Based Access Control (RBAC) permissions in Kubernetes can lead to significant security issues. This is because it grants overly broad permissions, potentially allowing access to sensitive resources.</p>
    </div>

    <div class="paragraph">
      <p>RBAC is designed to limit the access rights of users within the system by assigning roles to them. These roles define what actions a user can perform and on which resources. When a wildcard is used, it means that the role has access to all resources/verbs, bypassing the principle of least privilege. This principle states that users should have only the minimal permissions they need to perform their job function.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```kubernetes Bad theme={null}
      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
      namespace: default
      name: example-role
      rules:
      - apiGroups: [""]
      resources: ["*"] # Noncompliant
      verbs: ["get", "list"]
      ```

      ```kubernetes Fix theme={null}
      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
      namespace: default
      name: example-role
      rules:
      - apiGroups: [""]
      resources: ["pods"]
      verbs: ["get", "list"]
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Using host operating system namespaces is security-sensitive">
    <div class="paragraph">
      <p>stem namespaces can lead to compromise of the host systems.
      These attacks would target:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>host processes</p>
        </li>

        <li>
          <p>host inter-process communication (IPC) mechanisms</p>
        </li>

        <li>
          <p>network services of the local host system</p>
        </li>
      </ul>
    </div>

    <div class="paragraph">
      <p>These three items likely include systems that support either the internal
      operation of the Kubernetes cluster or the enterprise’s internal
      infrastructure.</p>
    </div>

    <div class="paragraph">
      <p>Opening these points to containers opens new attack surfaces for attackers who
      have already successfully exploited services exposed by containers. Depending
      on how resilient the cluster is, attackers can extend their attack to the
      cluster by compromising the nodes from which the cluster started the process.</p>
    </div>

    <div class="paragraph">
      <p>Host network sharing could provide a significant performance advantage for
      workloads that require critical network performance. However, the successful
      exploitation of this attack vector could have a catastrophic impact on
      confidentiality within the cluster.</p>
    </div>

    <CodeGroup>
      ```kubernetes Bad theme={null}
      apiVersion: v1
      kind: Pod
      metadata:
      name: example
      spec:
      containers:
      - name: web
        image: nginx
        ports:
          - name: web
            containerPort: 80
            protocol: TCP
      hostPID: true     # Sensitive
      hostIPC: true     # Sensitive
      hostNetwork: true # Sensitive
      ```

      ```kubernetes Fix theme={null}
      apiVersion: v1
      kind: Pod
      metadata:
      name: example
      spec:
      containers:
      - name: web
        image: nginx
        ports:
          - name: web
            containerPort: 80
            protocol: TCP
      hostPID: false
      hostIPC: false
      hostNetwork: false
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Using clear-text protocols is security-sensitive">
    <div class="paragraph">
      <p>Clear-text protocols such as \`ftp, telnet, or http lack
      encryption of transported data, as well as the capability to build an
      authenticated connection. It means that an attacker able to sniff traffic from
      the network can read, modify, or corrupt the transported content. These
      protocols are not secure as they expose applications to an extensive range of
      risks:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>sensitive data exposure</p>
        </li>

        <li>
          <p>traffic redirected  to a malicious endpoint</p>
        </li>

        <li>
          <p>malware-infected software update or installer</p>
        </li>

        <li>
          <p>execution of client-side code</p>
        </li>

        <li>
          <p>corruption of critical information</p>
        </li>
      </ul>
    </div>

    <div class="paragraph">
      <p>Even in the context of isolated networks like offline environments or segmented
      cloud environments, the insider threat exists. Thus, attacks involving
      communications being sniffed or tampered with can still happen.</p>
    </div>

    <div class="paragraph">
      <p>For example, attackers could successfully compromise prior security layers by:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>bypassing isolation mechanisms</p>
        </li>

        <li>
          <p>compromising a component of the network</p>
        </li>

        <li>
          <p>getting the credentials of an internal IAM account (either from a service
          account or an actual person)</p>
        </li>
      </ul>
    </div>

    <div class="paragraph">
      <p>In such cases, encrypting communications would decrease the chances of attackers
      to successfully leak data or steal credentials from other network components.
      By layering various security practices (segmentation and encryption, for
      example), the application will follow the <em>defense-in-depth</em> principle.</p>
    </div>

    <div class="paragraph">
      <p>Note that using the http\` protocol is being deprecated by
      <a href="https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http">major web browsers</a>.</p>
    </div>

    <div class="paragraph">
      <p>In the past, it has led to the following vulnerabilities:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p><a href="https://nvd.nist.gov/vuln/detail/CVE-2019-6169">CVE-2019-6169</a></p>
        </li>

        <li>
          <p><a href="https://nvd.nist.gov/vuln/detail/CVE-2019-12327">CVE-2019-12327</a></p>
        </li>

        <li>
          <p><a href="https://nvd.nist.gov/vuln/detail/CVE-2019-11065">CVE-2019-11065</a></p>
        </li>
      </ul>
    </div>

    <CodeGroup>
      ```kubernetes Bad theme={null}
      apiVersion: batch/v1
      kind: Job
      metadata:
      name: curl
      spec:
      template:
      spec:
        containers:
        - name: curl
          image: curlimages/curl
          command: ["curl"]
          args: ["http://example.com/"] # Sensitive
      ```

      ```kubernetes Fix theme={null}
      apiVersion: batch/v1
      kind: Job
      metadata:
      name: curl
      spec:
      template:
      spec:
        containers:
        - name: curl
          image: curlimages/curl
          command: ["curl"]
          args: ["https://example.com/"]
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Deprecated code should not be used">
    <div class="paragraph">
      <p>Code is sometimes annotated as deprecated by developers maintaining libraries or APIs to indicate that the method, class, or other programming element is no longer recommended for use. This is typically due to the introduction of a newer or more effective alternative. For example, when a better solution has been identified, or when the existing code presents potential errors or security risks.</p>
    </div>

    <div class="paragraph">
      <p>Deprecation is a good practice because it helps to phase out obsolete code in a controlled manner, without breaking existing software that may still depend on it. It is a way to warn other developers not to use the deprecated element in new code, and to replace it in existing code when possible.</p>
    </div>

    <div class="paragraph">
      <p>Deprecated classes, interfaces, and their members should not be used, inherited or extended because they will eventually be removed. The deprecation period allows you to make a smooth transition away from the aging, soon-to-be-retired technology.</p>
    </div>

    <div class="paragraph">
      <p>Check the documentation or the deprecation message to understand why the code was deprecated and what the recommended alternative is.</p>
    </div>

    <CodeGroup>
      ```kubernetes Bad theme={null}
      apiVersion: v1
      kind: ConfigMap
      metadata:
      name: {{ .Release.Name }}-configmap
      data:
      myvalue: "Hello World"
      kubeVersionDeprecated: {{ .Capabilities.KubeVersion.GitVersion }} # Noncompliant
      kubeVersion: {{ .Capabilities.KubeVersion.Version }}
      ```

      ```kubernetes Fix theme={null}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Track uses of TODO tags">
    <div class="paragraph">
      <p>Developers often use TODO tags to mark areas in the code where additional work or improvements are needed but are not implemented immediately.
      However, these TODO tags sometimes get overlooked or forgotten, leading to incomplete or unfinished code.
      This rule aims to identify and address unattended TODO tags to ensure a clean and maintainable codebase.
      This description explores why this is a problem and how it can be fixed to improve the overall code quality.</p>
    </div>

    <CodeGroup>
      ```kubernetes Bad theme={null}
      apiVersion: v1
      kind: Pod
      metadata:
      name: example
      spec:
      containers: # TODO
      - image: k8s.gcr.io/test-webserver
      name: example
      volumeMounts:
      - mountPath: /data
        name: example
      ```

      ```kubernetes Fix theme={null}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Local variable and function parameter names should comply with a naming convention">
    <div class="paragraph">
      <p>A naming convention in software development is a set of guidelines for naming code elements like variables, functions, and classes.
      \{identifier\_capital\_plural} hold the meaning of the written code. Their names should be meaningful and follow a consistent and easily recognizable pattern.
      Adhering to a consistent naming convention helps to make the code more readable and understandable, which makes it easier to maintain and debug.
      It also ensures consistency in the code, especially when multiple developers are working on the same project.</p>
    </div>

    <div class="paragraph">
      <p>This rule checks that \{identifier} names match a provided regular expression.</p>
    </div>

    <CodeGroup>
      ```kubernetes Bad theme={null}
      {{- $my_Variable := .Values.myVariableValue -}} # Noncompliant
      ```

      ```kubernetes Fix theme={null}
      apiVersion: v1
      kind: ConfigMap
      metadata:
      name: {{ .Release.Name }}-configmap
      data:
      myvalue: "Hello World"
      {{- range $KeyNc, $val-nc := .Values.favorite }} # Noncompliant
      {{ $KeyNc }}: {{ $val-nc | quote }}
      {{- end }}
      ```
    </CodeGroup>
  </Accordion>
</AccordionGroup>