mondoo-kubernetes-best-practices.mql.yaml

# Copyright (c) Mondoo, Inc.
# SPDX-License-Identifier: BUSL-1.1

policies:
  - uid: mondoo-kubernetes-best-practices
    name: Kubernetes Best Practices
    version: 1.1.1
    license: BUSL-1.1
    tags:
      mondoo.com/category: best-practices
      mondoo.com/platform: kubernetes
    authors:
      - name: Mondoo, Inc
        email: hello@mondoo.com
    docs:
      desc: |-
        ## Overview

        The Kubernetes Best Practices by Mondoo policy bundle provides guidance for establishing reliable Kubernetes clusters by encouraging the adoption of best practices.

        ## Remote scan

        Remote scans use cnspec providers to retrieve on-demand scan results without having to install any agents.

        For a complete list of providers run:

        ```bash
        cnspec scan --help
        ```

        ### Prerequisites

        Remote scans of Kubernetes clusters requires a `KUBECONFIG` with access to the cluster you want to scan.

        ### Scan a Kubernetes cluster

        Open a terminal and configure an environment variable with the path to your `KUBECONFIG`:

        ```bash
        export KUBECONFIG=/path/to/kubeconfig
        ```

        Run a scan of the Kubernetes cluster:

        ```bash
        cnspec scan k8s
        ```

        ## Join the community!

        Our goal is to build policies that are simple to deploy, accurate, and actionable.

        If you have any suggestions for how to improve this policy, or if you need support, [join the community](https://github.com/orgs/mondoohq/discussions) in GitHub Discussions.
    groups:
      - title: CronJobs
        filters: asset.platform == "k8s-cronjob"
        checks:
          - uid: mondoo-kubernetes-best-practices-cronjob-default-namespace
          - uid: mondoo-kubernetes-best-practices-cronjob-hostalias
          - uid: mondoo-kubernetes-best-practices-cronjob-ports-hostport
          - uid: mondoo-kubernetes-best-practices-cronjob-requestcpu
          - uid: mondoo-kubernetes-best-practices-cronjob-requestmemory
      - title: StatefulSets
        filters: asset.platform == "k8s-statefulset"
        checks:
          - uid: mondoo-kubernetes-best-practices-statefulset-default-namespace
          - uid: mondoo-kubernetes-best-practices-statefulset-hostalias
          - uid: mondoo-kubernetes-best-practices-statefulset-livenessprobe
          - uid: mondoo-kubernetes-best-practices-statefulset-ports-hostport
          - uid: mondoo-kubernetes-best-practices-statefulset-readinessProbe
          - uid: mondoo-kubernetes-best-practices-statefulset-requestcpu
          - uid: mondoo-kubernetes-best-practices-statefulset-requestmemory
      - title: Deployments
        filters: asset.platform == "k8s-deployment"
        checks:
          - uid: mondoo-kubernetes-best-practices-deployment-default-namespace
          - uid: mondoo-kubernetes-best-practices-deployment-hostalias
          - uid: mondoo-kubernetes-best-practices-deployment-livenessprobe
          - uid: mondoo-kubernetes-best-practices-deployment-ports-hostport
          - uid: mondoo-kubernetes-best-practices-deployment-readinessProbe
          - uid: mondoo-kubernetes-best-practices-deployment-requestcpu
          - uid: mondoo-kubernetes-best-practices-deployment-requestmemory
      - title: Jobs
        filters: asset.platform == "k8s-job"
        checks:
          - uid: mondoo-kubernetes-best-practices-job-default-namespace
          - uid: mondoo-kubernetes-best-practices-job-hostalias
          - uid: mondoo-kubernetes-best-practices-job-ports-hostport
          - uid: mondoo-kubernetes-best-practices-job-requestcpu
          - uid: mondoo-kubernetes-best-practices-job-requestmemory
      - title: Replicasets
        filters: asset.platform == "k8s-replicaset"
        checks:
          - uid: mondoo-kubernetes-best-practices-replicaset-default-namespace
          - uid: mondoo-kubernetes-best-practices-replicaset-hostalias
          - uid: mondoo-kubernetes-best-practices-replicaset-livenessprobe
          - uid: mondoo-kubernetes-best-practices-replicaset-ports-hostport
          - uid: mondoo-kubernetes-best-practices-replicaset-readinessProbe
          - uid: mondoo-kubernetes-best-practices-replicaset-requestcpu
          - uid: mondoo-kubernetes-best-practices-replicaset-requestmemory
      - title: Daemonsets
        filters: asset.platform == "k8s-daemonset"
        checks:
          - uid: mondoo-kubernetes-best-practices-daemonset-default-namespace
          - uid: mondoo-kubernetes-best-practices-daemonset-hostalias
          - uid: mondoo-kubernetes-best-practices-daemonset-livenessprobe
          - uid: mondoo-kubernetes-best-practices-daemonset-ports-hostport
          - uid: mondoo-kubernetes-best-practices-daemonset-readinessProbe
          - uid: mondoo-kubernetes-best-practices-daemonset-requestcpu
          - uid: mondoo-kubernetes-best-practices-daemonset-requestmemory
      - title: Pods
        filters: asset.platform == "k8s-pod"
        checks:
          - uid: mondoo-kubernetes-best-practices-pod-default-namespace
          - uid: mondoo-kubernetes-best-practices-pod-hostalias
          - uid: mondoo-kubernetes-best-practices-pod-livenessprobe
          - uid: mondoo-kubernetes-best-practices-pod-no-owner
          - uid: mondoo-kubernetes-best-practices-pod-ports-hostport
          - uid: mondoo-kubernetes-best-practices-pod-readinessProbe
          - uid: mondoo-kubernetes-best-practices-pod-requestcpu
          - uid: mondoo-kubernetes-best-practices-pod-requestmemory
      - title: Ingress Configuration
        filters: asset.platform == "k8s-ingress"
        checks:
          - uid: mondoo-kubernetes-best-practices-ingress-cert-expiration
    scoring_system: highest impact
queries:
  - uid: mondoo-kubernetes-best-practices-pod-no-owner
    title: Pods should have an owner
    impact: 50
    mql: |
      k8s.pod {
        manifest['metadata']['ownerReferences'] != empty && manifest['metadata']['ownerReferences'].length > 0
      }
    docs:
      desc: |
        Pods should be created via a Deployment or other Workload type.
        Pods without an owner (ie ReplicaSet, Job, etc.) will not be automatically restarted in the event of a Pod crash or Node failure.
      audit: |
        Check for Pods without an owner reference. Any line of output starting with '0' will indicate a Pod that has no owner:

        ```kubectl get pods -A -o json | jq -r '.items[] | [(.metadata.ownerReferences | length), .metadata.namespace, .metadata.name] | @tsv'```
      remediation: |
        For each Pod without an owner, ensure the Pod is owned by an appropriate Kubernetes object (eg Deployment, Job, DaemonSet, etc.) that will manage relaunching the Pod in the event of a failure.
  - uid: mondoo-kubernetes-best-practices-pod-requestcpu
    title: Container should request CPU
    impact: 20
    mql: |
      k8s.pod {
        initContainers {
          resources['requests']['cpu'] != empty
        }
        containers {
          resources['requests']['cpu'] != empty
        }
      }
    docs:
      desc: |
        When defining a Pod, you should specify how much CPU a container needs.
        This helps the Kubernetes scheduler to allocate resources accordingly.
        It will also ensure the Pod will get the resources it requires.
      audit: |
        Check for the existence of CPU `requests` resources.

        ```yaml
        ---
        apiVersion: v1
        kind: Pod
        spec:
          containers:
            - name: app
              image: images.my-company.example/app:v1
              resources:
                requests:
                  cpu: "250m" # <-- set CPU requests
        ```
      remediation: |
        Define the required resources for CPU `requests` in the container spec:

        ```yaml
        ---
        apiVersion: v1
        kind: Pod
        spec:
          containers:
            - name: app
              image: images.my-company.example/app:v1
              resources:
                requests:
                  cpu: "250m" # <-- set CPU requests
        ```
    refs:
      - url: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
        title: Resource Management for Pods and Containers
  - uid: mondoo-kubernetes-best-practices-cronjob-requestcpu
    title: Container should request CPU
    impact: 20
    mql: |
      k8s.cronjob {
        initContainers {
          resources['requests']['cpu'] != empty
        }
        containers {
          resources['requests']['cpu'] != empty
        }
      }
    docs:
      desc: |
        When defining a Pod, you should specify how much CPU a container needs.
        This helps the Kubernetes scheduler to allocate resources accordingly.
        It will also ensure the Pod will get the resources it requires.
      audit: |
        Check for the existence of CPU `requests` resources.

        ```yaml
        ---
        apiVersion: v1
        kind: Pod
        spec:
          containers:
            - name: app
              image: images.my-company.example/app:v1
              resources:
                requests:
                  cpu: "250m" # <-- set CPU requests
        ```
      remediation: |
        Define the required resources for CPU `requests` in the container spec:

        ```yaml
        ---
        apiVersion: v1
        kind: Pod
        spec:
          containers:
            - name: app
              image: images.my-company.example/app:v1
              resources:
                requests:
                  cpu: "250m" # <-- set CPU requests
        ```
    refs:
      - url: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
        title: Resource Management for Pods and Containers
  - uid: mondoo-kubernetes-best-practices-statefulset-requestcpu
    title: Container should request CPU
    impact: 20
    mql: |
      k8s.statefulset {
        initContainers {
          resources['requests']['cpu'] != empty
        }
        containers {
          resources['requests']['cpu'] != empty
        }
      }
    docs:
      desc: |
        When defining a Pod, you should specify how much CPU a container needs.
        This helps the Kubernetes scheduler to allocate resources accordingly.
        It will also ensure the Pod will get the resources it requires.
      audit: |
        Check for the existence of CPU `requests` resources.

        ```yaml
        ---
        apiVersion: v1
        kind: Pod
        spec:
          containers:
            - name: app
              image: images.my-company.example/app:v1
              resources:
                requests:
                  cpu: "250m" # <-- set CPU requests
        ```
      remediation: |
        Define the required resources for CPU `requests` in the container spec:

        ```yaml
        ---
        apiVersion: v1
        kind: Pod
        spec:
          containers:
            - name: app
              image: images.my-company.example/app:v1
              resources:
                requests:
                  cpu: "250m" # <-- set CPU requests
        ```
    refs:
      - url: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
        title: Resource Management for Pods and Containers
  - uid: mondoo-kubernetes-best-practices-deployment-requestcpu
    title: Container should request CPU
    impact: 20
    mql: |
      k8s.deployment {
        initContainers {
          resources['requests']['cpu'] != empty
        }
        containers {
          resources['requests']['cpu'] != empty
        }
      }
    docs:
      desc: |
        When defining a Pod, you should specify how much CPU a container needs.
        This helps the Kubernetes scheduler to allocate resources accordingly.
        It will also ensure the Pod will get the resources it requires.
      audit: |
        Check for the existence of CPU `requests` resources.

        ```yaml
        ---
        apiVersion: v1
        kind: Pod
        spec:
          containers:
            - name: app
              image: images.my-company.example/app:v1
              resources:
                requests:
                  cpu: "250m" # <-- set CPU requests
        ```
      remediation: |
        Define the required resources for CPU `requests` in the container spec:

        ```yaml
        ---
        apiVersion: v1
        kind: Pod
        spec:
          containers:
            - name: app
              image: images.my-company.example/app:v1
              resources:
                requests:
                  cpu: "250m" # <-- set CPU requests
        ```
    refs:
      - url: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
        title: Resource Management for Pods and Containers
  - uid: mondoo-kubernetes-best-practices-job-requestcpu
    title: Container should request CPU
    impact: 20
    mql: |
      k8s.job {
        initContainers {
          resources['requests']['cpu'] != empty
        }
        containers {
          resources['requests']['cpu'] != empty
        }
      }
    docs:
      desc: |
        When defining a Pod, you should specify how much CPU a container needs.
        This helps the Kubernetes scheduler to allocate resources accordingly.
        It will also ensure the Pod will get the resources it requires.
      audit: |
        Check for the existence of CPU `requests` resources.

        ```yaml
        ---
        apiVersion: v1
        kind: Pod
        spec:
          containers:
            - name: app
              image: images.my-company.example/app:v1
              resources:
                requests:
                  cpu: "250m" # <-- set CPU requests
        ```
      remediation: |
        Define the required resources for CPU `requests` in the container spec:

        ```yaml
        ---
        apiVersion: v1
        kind: Pod
        spec:
          containers:
            - name: app
              image: images.my-company.example/app:v1
              resources:
                requests:
                  cpu: "250m" # <-- set CPU requests
        ```
    refs:
      - url: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
        title: Resource Management for Pods and Containers
  - uid: mondoo-kubernetes-best-practices-replicaset-requestcpu
    title: Container should request CPU
    impact: 20
    mql: |
      k8s.replicaset {
        initContainers {
          resources['requests']['cpu'] != empty
        }
        containers {
          resources['requests']['cpu'] != empty
        }
      }
    docs:
      desc: |
        When defining a Pod, you should specify how much CPU a container needs.
        This helps the Kubernetes scheduler to allocate resources accordingly.
        It will also ensure the Pod will get the resources it requires.
      audit: |
        Check for the existence of CPU `requests` resources.

        ```yaml
        ---
        apiVersion: v1
        kind: Pod
        spec:
          containers:
            - name: app
              image: images.my-company.example/app:v1
              resources:
                requests:
                  cpu: "250m" # <-- set CPU requests
        ```
      remediation: |
        Define the required resources for CPU `requests` in the container spec:

        ```yaml
        ---
        apiVersion: v1
        kind: Pod
        spec:
          containers:
            - name: app
              image: images.my-company.example/app:v1
              resources:
                requests:
                  cpu: "250m" # <-- set CPU requests
        ```
    refs:
      - url: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
        title: Resource Management for Pods and Containers
  - uid: mondoo-kubernetes-best-practices-daemonset-requestcpu
    title: Container should request CPU
    impact: 20
    mql: |
      k8s.daemonset {
        initContainers {
          resources['requests']['cpu'] != empty
        }
        containers {
          resources['requests']['cpu'] != empty
        }
      }
    docs:
      desc: |
        When defining a Pod, you should specify how much CPU a container needs.
        This helps the Kubernetes scheduler to allocate resources accordingly.
        It will also ensure the Pod will get the resources it requires.
      audit: |
        Check for the existence of CPU `requests` resources.

        ```yaml
        ---
        apiVersion: v1
        kind: Pod
        spec:
          containers:
            - name: app
              image: images.my-company.example/app:v1
              resources:
                requests:
                  cpu: "250m" # <-- set CPU requests
        ```
      remediation: |
        Define the required resources for CPU `requests` in the container spec:

        ```yaml
        ---
        apiVersion: v1
        kind: Pod
        spec:
          containers:
            - name: app
              image: images.my-company.example/app:v1
              resources:
                requests:
                  cpu: "250m" # <-- set CPU requests
        ```
    refs:
      - url: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
        title: Resource Management for Pods and Containers
  - uid: mondoo-kubernetes-best-practices-pod-requestmemory
    title: Container should request memory
    impact: 20
    mql: |
      k8s.pod {
        initContainers {
          resources['requests']['memory'] != empty
        }
        containers {
          resources['requests']['memory'] != empty
        }
      }
    docs:
      desc: |
        When defining a Pod, you should specify how much memory a container needs.
        This helps the Kubernetes scheduler to allocate resources accordingly.
        It will also ensure the Pod will get the resources it requires.
      audit: |
        Check for the existence of memory `requests` resources.

        ```yaml
        ---
        apiVersion: v1
        kind: Pod
        spec:
          containers:
            - name: app
              image: images.my-company.example/app:v1
              resources:
                requests:
                  memory: "1Gi" # <-- set memory requests
        ```
      remediation: |
        Define the required resources for memory `requests` in the container spec:

        ```yaml
        ---
        apiVersion: v1
        kind: Pod
        spec:
          containers:
            - name: app
              image: images.my-company.example/app:v1
              resources:
                requests:
                  memory: "1Gi" # <-- set memory requests
        ```
    refs:
      - url: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
        title: Resource Management for Pods and Containers
  - uid: mondoo-kubernetes-best-practices-cronjob-requestmemory
    title: Container should request memory
    impact: 20
    mql: |
      k8s.cronjob {
        initContainers {
          resources['requests']['memory'] != empty
        }
        containers {
          resources['requests']['memory'] != empty
        }
      }
    docs:
      desc: |
        When defining a Pod, you should specify how much memory a container needs.
        This helps the Kubernetes scheduler to allocate resources accordingly.
        It will also ensure the Pod will get the resources it requires.
      audit: |
        Check for the existence of memory `requests` resources.

        ```yaml
        ---
        apiVersion: v1
        kind: Pod
        spec:
          containers:
            - name: app
              image: images.my-company.example/app:v1
              resources:
                requests:
                  memory: "1Gi" # <-- set memory requests
        ```
      remediation: |
        Define the required resources for memory `requests` in the container spec:

        ```yaml
        ---
        apiVersion: v1
        kind: Pod
        spec:
          containers:
            - name: app
              image: images.my-company.example/app:v1
              resources:
                requests:
                  memory: "1Gi" # <-- set memory requests
        ```
    refs:
      - url: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
        title: Resource Management for Pods and Containers
  - uid: mondoo-kubernetes-best-practices-statefulset-requestmemory
    title: Container should request memory
    impact: 20
    mql: |
      k8s.statefulset {
        initContainers {
          resources['requests']['memory'] != empty
        }
        containers {
          resources['requests']['memory'] != empty
        }
      }
    docs:
      desc: |
        When defining a Pod, you should specify how much memory a container needs.
        This helps the Kubernetes scheduler to allocate resources accordingly.
        It will also ensure the Pod will get the resources it requires.
      audit: |
        Check for the existence of memory `requests` resources.

        ```yaml
        ---
        apiVersion: v1
        kind: Pod
        spec:
          containers:
            - name: app
              image: images.my-company.example/app:v1
              resources:
                requests:
                  memory: "1Gi" # <-- set memory requests
        ```
      remediation: |
        Define the required resources for memory `requests` in the container spec:

        ```yaml
        ---
        apiVersion: v1
        kind: Pod
        spec:
          containers:
            - name: app
              image: images.my-company.example/app:v1
              resources:
                requests:
                  memory: "1Gi" # <-- set memory requests
        ```
    refs:
      - url: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
        title: Resource Management for Pods and Containers
  - uid: mondoo-kubernetes-best-practices-deployment-requestmemory
    title: Container should request memory
    impact: 20
    mql: |
      k8s.deployment {
        initContainers {
          resources['requests']['memory'] != empty
        }
        containers {
          resources['requests']['memory'] != empty
        }
      }
    docs:
      desc: |
        When defining a Pod, you should specify how much memory a container needs.
        This helps the Kubernetes scheduler to allocate resources accordingly.
        It will also ensure the Pod will get the resources it requires.
      audit: |
        Check for the existence of memory `requests` resources.

        ```yaml
        ---
        apiVersion: v1
        kind: Pod
        spec:
          containers:
            - name: app
              image: images.my-company.example/app:v1
              resources:
                requests:
                  memory: "1Gi" # <-- set memory requests
        ```
      remediation: |
        Define the required resources for memory `requests` in the container spec:

        ```yaml
        ---
        apiVersion: v1
        kind: Pod
        spec:
          containers:
            - name: app
              image: images.my-company.example/app:v1
              resources:
                requests:
                  memory: "1Gi" # <-- set memory requests
        ```
    refs:
      - url: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
        title: Resource Management for Pods and Containers
  - uid: mondoo-kubernetes-best-practices-job-requestmemory
    title: Container should request memory
    impact: 20
    mql: |
      k8s.job {
        initContainers {
          resources['requests']['memory'] != empty
        }
        containers {
          resources['requests']['memory'] != empty
        }
      }
    docs:
      desc: |
        When defining a Pod, you should specify how much memory a container needs.
        This helps the Kubernetes scheduler to allocate resources accordingly.
        It will also ensure the Pod will get the resources it requires.
      audit: |
        Check for the existence of memory `requests` resources.

        ```yaml
        ---
        apiVersion: v1
        kind: Pod
        spec:
          containers:
            - name: app
              image: images.my-company.example/app:v1
              resources:
                requests:
                  memory: "1Gi" # <-- set memory requests
        ```
      remediation: |
        Define the required resources for memory `requests` in the container spec:

        ```yaml
        ---
        apiVersion: v1
        kind: Pod
        spec:
          containers:
            - name: app
              image: images.my-company.example/app:v1
              resources:
                requests:
                  memory: "1Gi" # <-- set memory requests
        ```
    refs:
      - url: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
        title: Resource Management for Pods and Containers
  - uid: mondoo-kubernetes-best-practices-replicaset-requestmemory
    title: Container should request memory
    impact: 20
    mql: |
      k8s.replicaset {
        initContainers {
          resources['requests']['memory'] != empty
        }
        containers {
          resources['requests']['memory'] != empty
        }
      }
    docs:
      desc: |
        When defining a Pod, you should specify how much memory a container needs.
        This helps the Kubernetes scheduler to allocate resources accordingly.
        It will also ensure the Pod will get the resources it requires.
      audit: |
        Check for the existence of memory `requests` resources.

        ```yaml
        ---
        apiVersion: v1
        kind: Pod
        spec:
          containers:
            - name: app
              image: images.my-company.example/app:v1
              resources:
                requests:
                  memory: "1Gi" # <-- set memory requests
        ```
      remediation: |
        Define the required resources for memory `requests` in the container spec:

        ```yaml
        ---
        apiVersion: v1
        kind: Pod
        spec:
          containers:
            - name: app
              image: images.my-company.example/app:v1
              resources:
                requests:
                  memory: "1Gi" # <-- set memory requests
        ```
    refs:
      - url: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
        title: Resource Management for Pods and Containers
  - uid: mondoo-kubernetes-best-practices-daemonset-requestmemory
    title: Container should request memory
    impact: 20
    mql: |
      k8s.daemonset {
        initContainers {
          resources['requests']['memory'] != empty
        }
        containers {
          resources['requests']['memory'] != empty
        }
      }
    docs:
      desc: |
        When defining a Pod, you should specify how much memory a container needs.
        This helps the Kubernetes scheduler to allocate resources accordingly.
        It will also ensure the Pod will get the resources it requires.
      audit: |
        Check for the existence of memory `requests` resources.

        ```yaml
        ---
        apiVersion: v1
        kind: Pod
        spec:
          containers:
            - name: app
              image: images.my-company.example/app:v1
              resources:
                requests:
                  memory: "1Gi" # <-- set memory requests
        ```
      remediation: |
        Define the required resources for memory `requests` in the container spec:

        ```yaml
        ---
        apiVersion: v1
        kind: Pod
        spec:
          containers:
            - name: app
              image: images.my-company.example/app:v1
              resources:
                requests:
                  memory: "1Gi" # <-- set memory requests
        ```
    refs:
      - url: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
        title: Resource Management for Pods and Containers
  - uid: mondoo-kubernetes-best-practices-pod-livenessprobe
    title: Container should configure a livenessProbe
    impact: 20
    mql: |
      if (k8s.pod.manifest['metadata']['ownerReferences'].none(_['kind'] == 'Job')) {
        k8s.pod {
          containers {
            probeSpecified = livenessProbe['httpGet'] != empty || livenessProbe['tcpSocket'] != empty || livenessProbe['exec'] != empty

            probeSpecified == true
          }
        }
      }
    docs:
      desc: |
        When defining a container, you should specify a livenessProbe.
        This helps Kubernetes to check whether your container is still healthy and able to serve requests.
      audit: |
        Check for the existence of `livenessProbe`:

        ```yaml
        ---
        apiVersion: v1
        kind: Pod
        spec:
          containers:
            - name: container-name
              image: index.docker.io/yournamespace/repository
              livenessProbe: # <--- Set a livenessProbe like this
                tcpSocket:
                  port: 8080
                initialDelaySeconds: 5
                periodSeconds: 5
        ```
      remediation: ""
    refs:
      - url: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes
        title: Pod Lifecycle - Container probes
  - uid: mondoo-kubernetes-best-practices-statefulset-livenessprobe
    title: Container should configure a livenessProbe
    impact: 20
    mql: |
      k8s.statefulset {
        containers {
          probeSpecified = livenessProbe['httpGet'] != empty || livenessProbe['tcpSocket'] != empty || livenessProbe['exec'] != empty

          probeSpecified == true
        }
      }
    docs:
      desc: |
        When defining a container, you should specify a livenessProbe.
        This helps Kubernetes to check whether your container is still healthy and able to serve requests.
      audit: |
        Check for the existence of `livenessProbe`:

        ```yaml
        ---
        apiVersion: v1
        kind: Pod
        spec:
          containers:
            - name: container-name
              image: index.docker.io/yournamespace/repository
              livenessProbe: # <--- Set a livenessProbe like this
                tcpSocket:
                  port: 8080
                initialDelaySeconds: 5
                periodSeconds: 5
        ```
      remediation: ""
    refs:
      - url: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes
        title: Pod Lifecycle - Container probes
  - uid: mondoo-kubernetes-best-practices-deployment-livenessprobe
    title: Container should configure a livenessProbe
    impact: 20
    mql: |
      k8s.deployment {
        containers {
          probeSpecified = livenessProbe['httpGet'] != empty || livenessProbe['tcpSocket'] != empty || livenessProbe['exec'] != empty
          probeSpecified == true
        }
      }
    docs:
      desc: |
        When defining a container, you should specify a livenessProbe.
        This helps Kubernetes to check whether your container is still healthy and able to serve requests.
      audit: |
        Check for the existence of `livenessProbe`:

        ```yaml
        ---
        apiVersion: v1
        kind: Pod
        spec:
          containers:
            - name: container-name
              image: index.docker.io/yournamespace/repository
              livenessProbe: # <--- Set a livenessProbe like this
                tcpSocket:
                  port: 8080
                initialDelaySeconds: 5
                periodSeconds: 5
        ```
      remediation: ""
    refs:
      - url: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes
        title: Pod Lifecycle - Container probes
  - uid: mondoo-kubernetes-best-practices-replicaset-livenessprobe
    title: Container should configure a livenessProbe
    impact: 20
    mql: |
      k8s.replicaset {
        containers {
          probeSpecified = livenessProbe['httpGet'] != empty || livenessProbe['tcpSocket'] != empty || livenessProbe['exec'] != empty

          probeSpecified == true
        }
      }
    docs:
      desc: |
        When defining a container, you should specify a livenessProbe.
        This helps Kubernetes to check whether your container is still healthy and able to serve requests.
      audit: |
        Check for the existence of `livenessProbe`:

        ```yaml
        ---
        apiVersion: v1
        kind: Pod
        spec:
          containers:
            - name: container-name
              image: index.docker.io/yournamespace/repository
              livenessProbe: # <--- Set a livenessProbe like this
                tcpSocket:
                  port: 8080
                initialDelaySeconds: 5
                periodSeconds: 5
        ```
      remediation: ""
    refs:
      - url: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes
        title: Pod Lifecycle - Container probes
  - uid: mondoo-kubernetes-best-practices-daemonset-livenessprobe
    title: Container should configure a livenessProbe
    impact: 20
    mql: |
      k8s.daemonset {
        containers {
          probeSpecified = livenessProbe['httpGet'] != empty || livenessProbe['tcpSocket'] != empty || livenessProbe['exec'] != empty

          probeSpecified == true
        }
      }
    docs:
      desc: |
        When defining a container, you should specify a livenessProbe.
        This helps Kubernetes to check whether your container is still healthy and able to serve requests.
      audit: |
        Check for the existence of `livenessProbe`:

        ```yaml
        ---
        apiVersion: v1
        kind: Pod
        spec:
          containers:
            - name: container-name
              image: index.docker.io/yournamespace/repository
              livenessProbe: # <--- Set a livenessProbe like this
                tcpSocket:
                  port: 8080
                initialDelaySeconds: 5
                periodSeconds: 5
        ```
      remediation: ""
    refs:
      - url: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes
        title: Pod Lifecycle - Container probes
  - uid: mondoo-kubernetes-best-practices-pod-readinessProbe
    title: Container should configure a readinessProbe
    impact: 20
    mql: |
      if (k8s.pod.manifest['metadata']['ownerReferences'].none(_['kind'] == 'Job')) {
        k8s.pod {
          containers {
            probeSpecified = readinessProbe['httpGet'] != empty || readinessProbe['tcpSocket'] != empty || readinessProbe['exec'] != empty

            probeSpecified == true
          }
        }
      }
    docs:
      desc: |
        When defining a container, you should specify a readinessProbe.
        This helps Kubernetes to check whether your container ready to serve requests.
      audit: |
        Check for the existence of `readinessProbe`:

        ```yaml
        ---
        apiVersion: v1
        kind: Pod
        spec:
          containers:
            - name: container-name
              image: index.docker.io/yournamespace/repository
              readinessProbe: # <--- Set a readinessProbe like this
                tcpSocket:
                  port: 8080
                initialDelaySeconds: 5
                periodSeconds: 5
        ```
      remediation: ""
    refs:
      - url: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes
        title: Pod Lifecycle - Container probes
  - uid: mondoo-kubernetes-best-practices-statefulset-readinessProbe
    title: Container should configure a readinessProbe
    impact: 20
    mql: |
      k8s.statefulset {
        containers {
          probeSpecified = readinessProbe['httpGet'] != empty || readinessProbe['tcpSocket'] != empty || readinessProbe['exec'] != empty

          probeSpecified == true
        }
      }
    docs:
      desc: |
        When defining a container, you should specify a readinessProbe.
        This helps Kubernetes to check whether your container ready to serve requests.
      audit: |
        Check for the existence of `readinessProbe`:

        ```yaml
        ---
        apiVersion: v1
        kind: Pod
        spec:
          containers:
            - name: container-name
              image: index.docker.io/yournamespace/repository
              readinessProbe: # <--- Set a readinessProbe like this
                tcpSocket:
                  port: 8080
                initialDelaySeconds: 5
                periodSeconds: 5
        ```
      remediation: ""
    refs:
      - url: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes
        title: Pod Lifecycle - Container probes
  - uid: mondoo-kubernetes-best-practices-deployment-readinessProbe
    title: Container should configure a readinessProbe
    impact: 20
    mql: |
      k8s.deployment {
        containers {
          probeSpecified = readinessProbe['httpGet'] != empty || readinessProbe['tcpSocket'] != empty || readinessProbe['exec'] != empty
          probeSpecified == true
        }
      }
    docs:
      desc: |
        When defining a container, you should specify a readinessProbe.
        This helps Kubernetes to check whether your container ready to serve requests.
      audit: |
        Check for the existence of `readinessProbe`:

        ```yaml
        ---
        apiVersion: v1
        kind: Pod
        spec:
          containers:
            - name: container-name
              image: index.docker.io/yournamespace/repository
              readinessProbe: # <--- Set a readinessProbe like this
                tcpSocket:
                  port: 8080
                initialDelaySeconds: 5
                periodSeconds: 5
        ```
      remediation: ""
    refs:
      - url: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes
        title: Pod Lifecycle - Container probes
  - uid: mondoo-kubernetes-best-practices-replicaset-readinessProbe
    title: Container should configure a readinessProbe
    impact: 20
    mql: |
      k8s.replicaset {
        containers {
          probeSpecified = readinessProbe['httpGet'] != empty || readinessProbe['tcpSocket'] != empty || readinessProbe['exec'] != empty

          probeSpecified == true
        }
      }
    docs:
      desc: |
        When defining a container, you should specify a readinessProbe.
        This helps Kubernetes to check whether your container ready to serve requests.
      audit: |
        Check for the existence of `readinessProbe`:

        ```yaml
        ---
        apiVersion: v1
        kind: Pod
        spec:
          containers:
            - name: container-name
              image: index.docker.io/yournamespace/repository
              readinessProbe: # <--- Set a readinessProbe like this
                tcpSocket:
                  port: 8080
                initialDelaySeconds: 5
                periodSeconds: 5
        ```
      remediation: ""
    refs:
      - url: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes
        title: Pod Lifecycle - Container probes
  - uid: mondoo-kubernetes-best-practices-daemonset-readinessProbe
    title: Container should configure a readinessProbe
    impact: 20
    mql: |
      k8s.daemonset {
        containers {
          probeSpecified = readinessProbe['httpGet'] != empty || readinessProbe['tcpSocket'] != empty || readinessProbe['exec'] != empty

          probeSpecified == true
        }
      }
    docs:
      desc: |
        When defining a container, you should specify a readinessProbe.
        This helps Kubernetes to check whether your container ready to serve requests.
      audit: |
        Check for the existence of `readinessProbe`:

        ```yaml
        ---
        apiVersion: v1
        kind: Pod
        spec:
          containers:
            - name: container-name
              image: index.docker.io/yournamespace/repository
              readinessProbe: # <--- Set a readinessProbe like this
                tcpSocket:
                  port: 8080
                initialDelaySeconds: 5
                periodSeconds: 5
        ```
      remediation: ""
    refs:
      - url: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes
        title: Pod Lifecycle - Container probes
  - uid: mondoo-kubernetes-best-practices-pod-hostalias
    title: Pod should not define hostAliases
    impact: 60
    mql: |
      k8s.pod {
        podSpec['hostAliases'] == null
      }
    docs:
      desc: |
        DNS entries shouldn't be managed locally via `/etc/hosts` within Pods. This can result in unintended and/or dangerous outcomes.
      audit: |
        Check for the existence of `hostAliases` setting in `spec`:

        ```yaml
        apiVersion: v1
        kind: Pod
        spec:
          hostAliases: # <--- Don't set DNS entries using hostAliases
            - ip: "127.0.0.1"
              hostnames:
                - "foo.local"
                - "bar.local"
          containers:
            - name: example-app
              image: index.docker.io/yournamespace/repository
        ```
      remediation: ""
    refs:
      - url: https://kubernetes.io/docs/tasks/network/customize-hosts-file-for-pods/
        title: Adding entries to Pod /etc/hosts with HostAliases
  - uid: mondoo-kubernetes-best-practices-cronjob-hostalias
    title: Pod should not define hostAliases
    impact: 60
    mql: |
      k8s.cronjob {
        manifest['spec']['jobTemplate']['spec']['template']['spec']['hostAliases'] == null
      }
    docs:
      desc: |
        DNS entries shouldn't be managed locally via `/etc/hosts` within Pods. This can result in unintended and/or dangerous outcomes.
      audit: |
        Check for the existence of `hostAliases` setting in `spec`:

        ```yaml
        apiVersion: v1
        kind: Pod
        spec:
          hostAliases: # <--- Don't set DNS entries using hostAliases
            - ip: "127.0.0.1"
              hostnames:
                - "foo.local"
                - "bar.local"
          containers:
            - name: example-app
              image: index.docker.io/yournamespace/repository
        ```
      remediation: ""
    refs:
      - url: https://kubernetes.io/docs/tasks/network/customize-hosts-file-for-pods/
        title: Adding entries to Pod /etc/hosts with HostAliases
  - uid: mondoo-kubernetes-best-practices-statefulset-hostalias
    title: Pod should not define hostAliases
    impact: 60
    mql: |
      k8s.statefulset {
        manifest['spec']['template']['spec']['hostAliases'] == null
      }
    docs:
      desc: |
        DNS entries shouldn't be managed locally via `/etc/hosts` within Pods. This can result in unintended and/or dangerous outcomes.
      audit: |
        Check for the existence of `hostAliases` setting in `spec`:

        ```yaml
        apiVersion: v1
        kind: Pod
        spec:
          hostAliases: # <--- Don't set DNS entries using hostAliases
            - ip: "127.0.0.1"
              hostnames:
                - "foo.local"
                - "bar.local"
          containers:
            - name: example-app
              image: index.docker.io/yournamespace/repository
        ```
      remediation: ""
    refs:
      - url: https://kubernetes.io/docs/tasks/network/customize-hosts-file-for-pods/
        title: Adding entries to Pod /etc/hosts with HostAliases
  - uid: mondoo-kubernetes-best-practices-deployment-hostalias
    title: Pod should not define hostAliases
    impact: 60
    mql: |
      k8s.deployment {
        manifest['spec']['template']['spec']['hostAliases'] == null
      }
    docs:
      desc: |
        DNS entries shouldn't be managed locally via `/etc/hosts` within Pods. This can result in unintended and/or dangerous outcomes.
      audit: |
        Check for the existence of `hostAliases` setting in `spec`:

        ```yaml
        apiVersion: v1
        kind: Deployment
        spec:
          ...
          spec:
            hostAliases: # <--- Don't set DNS entries using hostAliases
            - ip: "127.0.0.1"
              hostnames:
                - "foo.local"
                - "bar.local"
            containers:
            - name: example-app
              image: index.docker.io/yournamespace/repository
        ```
      remediation: ""
    refs:
      - url: https://kubernetes.io/docs/tasks/network/customize-hosts-file-for-pods/
        title: Adding entries to Pod /etc/hosts with HostAliases
  - uid: mondoo-kubernetes-best-practices-job-hostalias
    title: Pod should not define hostAliases
    impact: 60
    mql: |
      k8s.job {
        manifest['spec']['template']['spec']['hostAliases'] == null
      }
    docs:
      desc: |
        DNS entries shouldn't be managed locally via `/etc/hosts` within Pods. This can result in unintended and/or dangerous outcomes.
      audit: |
        Check for the existence of `hostAliases` setting in `spec`:

        ```yaml
        apiVersion: v1
        kind: Pod
        spec:
          hostAliases: # <--- Don't set DNS entries using hostAliases
            - ip: "127.0.0.1"
              hostnames:
                - "foo.local"
                - "bar.local"
          containers:
            - name: example-app
              image: index.docker.io/yournamespace/repository
        ```
      remediation: ""
    refs:
      - url: https://kubernetes.io/docs/tasks/network/customize-hosts-file-for-pods/
        title: Adding entries to Pod /etc/hosts with HostAliases
  - uid: mondoo-kubernetes-best-practices-replicaset-hostalias
    title: Pod should not define hostAliases
    impact: 60
    mql: |
      k8s.replicaset {
        manifest['spec']['template']['spec']['hostAliases'] == null
      }
    docs:
      desc: |
        DNS entries shouldn't be managed locally via `/etc/hosts` within Pods. This can result in unintended and/or dangerous outcomes.
      audit: |
        Check for the existence of `hostAliases` setting in `spec`:

        ```yaml
        apiVersion: v1
        kind: Pod
        spec:
          hostAliases: # <--- Don't set DNS entries using hostAliases
            - ip: "127.0.0.1"
              hostnames:
                - "foo.local"
                - "bar.local"
          containers:
            - name: example-app
              image: index.docker.io/yournamespace/repository
        ```
      remediation: ""
    refs:
      - url: https://kubernetes.io/docs/tasks/network/customize-hosts-file-for-pods/
        title: Adding entries to Pod /etc/hosts with HostAliases
  - uid: mondoo-kubernetes-best-practices-daemonset-hostalias
    title: Pod should not define hostAliases
    impact: 60
    mql: |
      k8s.daemonset {
        manifest['spec']['template']['spec']['hostAliases'] == null
      }
    docs:
      desc: |
        DNS entries shouldn't be managed locally via `/etc/hosts` within Pods. This can result in unintended and/or dangerous outcomes.
      audit: |
        Check for the existence of `hostAliases` setting in `spec`:

        ```yaml
        apiVersion: v1
        kind: Pod
        spec:
          hostAliases: # <--- Don't set DNS entries using hostAliases
            - ip: "127.0.0.1"
              hostnames:
                - "foo.local"
                - "bar.local"
          containers:
            - name: example-app
              image: index.docker.io/yournamespace/repository
        ```
      remediation: ""
    refs:
      - url: https://kubernetes.io/docs/tasks/network/customize-hosts-file-for-pods/
        title: Adding entries to Pod /etc/hosts with HostAliases
  - uid: mondoo-kubernetes-best-practices-pod-default-namespace
    title: Workloads should not run in default namespace
    impact: 20
    mql: |
      k8s.pod {
        namespace != "default"
      }
    docs:
      desc: |
        Workloads should be organized by Namespace, and the default Namespace shouldn't be used.
        With separate Namespaces, you can apply fine-grained RBAC permissions, Resource Quotas, and default limits, depending on the workload.
        Spreading workloads across namespaces also allows you to limit the network communication between them with Network Policies.
      audit: |
        Check to ensure no workloads are running in the default Namespace. this command should return no Pods:

        ```yaml
        kubectl get pods -n default
        ```
      remediation: |
        For any Pods running in the default Namespace, update/redeploy the Pods (or the parent Deployment, CronJob, etc) to a non-default Namespace:

        ```yaml
        apiVersion:v1
        kind: Pod
        metadata:
          name: examplePod
          namespace: pod-namespace # <--- Define a namespace for workloads
        ```
    refs:
      - url: https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-organizing-with-namespaces
        title: 'Kubernetes best practices: Organizing with Namespaces'
      - url: https://kubernetes.io/docs/concepts/services-networking/network-policies/
        title: Kubernetes Network Policies
      - url: https://kubernetes.io/docs/concepts/policy/limit-range/
        title: Kubernetes Limit Ranges
  - uid: mondoo-kubernetes-best-practices-daemonset-default-namespace
    title: DaemonSets should not run in the default namespace
    impact: 20
    mql: |
      k8s.daemonset {
        namespace != "default"
      }
    docs:
      desc: |
        Workloads should be organized by Namespace, and the default Namespace shouldn't be used.
        With separate Namespaces, you can apply fine-grained RBAC permissions, Resource Quotas, and default limits, depending on the workload.
        Spreading workloads across namespaces also allows you to limit the network communication between them with Network Policies.
      audit: |
        Check to ensure no workloads are running in the default Namespace. this command should return no DaemonSets:

        ```yaml
        kubectl get daemonsets -n default
        ```
      remediation: |
        For any Daemonsets running in the default Namespace, update/redeploy the DaemonSets to a non-default Namespace:

        ```yaml
        apiVersion:apps/v1
        kind: DaemonSet
        metadata:
          name: exampleDaemonSet
          namespace: daemonset-namespace # <--- Define a namespace for workloads
        ```
    refs:
      - url: https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-organizing-with-namespaces
        title: 'Kubernetes best practices: Organizing with Namespaces'
      - url: https://kubernetes.io/docs/concepts/services-networking/network-policies/
        title: Kubernetes Network Policies
      - url: https://kubernetes.io/docs/concepts/policy/limit-range/
        title: Kubernetes Limit Ranges
  - uid: mondoo-kubernetes-best-practices-replicaset-default-namespace
    title: ReplicaSets should not run in the default namespace
    impact: 20
    mql: |
      k8s.replicaset {
        namespace != "default"
      }
    docs:
      desc: |
        Workloads should be organized by Namespace, and the default Namespace shouldn't be used.
        With separate Namespaces, you can apply fine-grained RBAC permissions, Resource Quotas, and default limits, depending on the workload.
        Spreading workloads across namespaces also allows you to limit the network communication between them with Network Policies.
      audit: |
        Check to ensure no workloads are running in the default Namespace. this command should return no ReplicaSets:

        ```yaml
        kubectl get replicasets -n default
        ```
      remediation: |
        For any ReplicaSets running in the default Namespace, update/redeploy the ReplicaSets (or the parent Deployment) to a non-default Namespace:

        ```yaml
        apiVersion:apps/v1
        kind: ReplicaSet
        metadata:
          name: exampleReplicaSet
          namespace: replicaset-namespace # <--- Define a namespace for workloads
        ```
    refs:
      - url: https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-organizing-with-namespaces
        title: 'Kubernetes best practices: Organizing with Namespaces'
      - url: https://kubernetes.io/docs/concepts/services-networking/network-policies/
        title: Kubernetes Network Policies
      - url: https://kubernetes.io/docs/concepts/policy/limit-range/
        title: Kubernetes Limit Ranges
  - uid: mondoo-kubernetes-best-practices-job-default-namespace
    title: Jobs should not run in the default namespace
    impact: 20
    mql: |
      k8s.job {
        namespace != "default"
      }
    docs:
      desc: |
        Workloads should be organized by Namespace, and the default Namespace shouldn't be used.
        With separate Namespaces, you can apply fine-grained RBAC permissions, Resource Quotas, and default limits, depending on the workload.
        Spreading workloads across namespaces also allows you to limit the network communication between them with Network Policies.
      audit: |
        Check to ensure no workloads are running in the default Namespace. this command should return no Jobs:

        ```yaml
        kubectl get jobs -n default
        ```
      remediation: |
        For any Jobs running in the default Namespace, update/redeploy the Jobs (or the parent CronJobs) to a non-default Namespace:

        ```yaml
        apiVersion:batch/v1
        kind: Job
        metadata:
          name: exampleJob
          namespace: job-namespace # <--- Define a namespace for workloads
        ```
    refs:
      - url: https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-organizing-with-namespaces
        title: 'Kubernetes best practices: Organizing with Namespaces'
      - url: https://kubernetes.io/docs/concepts/services-networking/network-policies/
        title: Kubernetes Network Policies
      - url: https://kubernetes.io/docs/concepts/policy/limit-range/
        title: Kubernetes Limit Ranges
  - uid: mondoo-kubernetes-best-practices-deployment-default-namespace
    title: Deployments should not run in the default namespace
    impact: 20
    mql: |
      k8s.deployment {
        namespace != "default"
      }
    docs:
      desc: |
        Workloads should be organized by Namespace, and the default Namespace shouldn't be used.
        With separate Namespaces, you can apply fine-grained RBAC permissions, Resource Quotas, and default limits, depending on the workload.
        Spreading workloads across namespaces also allows you to limit the network communication between them with Network Policies.
      audit: |
        Check to ensure no workloads are running in the default Namespace. this command should return no Deployments:

        ```yaml
        kubectl get deployments -n default
        ```
      remediation: |
        For any Deployments running in the default Namespace, update/redeploy the Deployments to a non-default Namespace:

        ```yaml
        apiVersion:apps/v1
        kind: Deployment
        metadata:
          name: exampleDeployment
          namespace: deployment-namespace # <--- Define a namespace for workloads
        ```
    refs:
      - url: https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-organizing-with-namespaces
        title: 'Kubernetes best practices: Organizing with Namespaces'
      - url: https://kubernetes.io/docs/concepts/services-networking/network-policies/
        title: Kubernetes Network Policies
      - url: https://kubernetes.io/docs/concepts/policy/limit-range/
        title: Kubernetes Limit Ranges
  - uid: mondoo-kubernetes-best-practices-statefulset-default-namespace
    title: StatefulSets should not run in the default namespace
    impact: 20
    mql: |
      k8s.statefulset {
        namespace != "default"
      }
    docs:
      desc: |
        Workloads should be organized by Namespace, and the default Namespace shouldn't be used.
        With separate Namespaces, you can apply fine-grained RBAC permissions, Resource Quotas, and default limits, depending on the workload.
        Spreading workloads across namespaces also allows you to limit the network communication between them with Network Policies.
      audit: |
        Check to ensure no workloads are running in the default Namespace. this command should return no StatefulSets:

        ```yaml
        kubectl get statefulsets -n default
        ```
      remediation: |
        For any StatefulSets running in the default Namespace, update/redeploy the StatefulSets to a non-default Namespace:

        ```yaml
        apiVersion:apps/v1
        kind: StatefulSet
        metadata:
          name: exampleStatefulset
          namespace: statefulset-namespace # <--- Define a namespace for workloads
        ```
    refs:
      - url: https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-organizing-with-namespaces
        title: 'Kubernetes best practices: Organizing with Namespaces'
      - url: https://kubernetes.io/docs/concepts/services-networking/network-policies/
        title: Kubernetes Network Policies
      - url: https://kubernetes.io/docs/concepts/policy/limit-range/
        title: Kubernetes Limit Ranges
  - uid: mondoo-kubernetes-best-practices-cronjob-default-namespace
    title: CronJobs should not run in the default namespace
    impact: 20
    mql: |
      k8s.cronjob {
        namespace != "default"
      }
    docs:
      desc: |
        Workloads should be organized by Namespace, and the default Namespace shouldn't be used.
        With separate Namespaces, you can apply fine-grained RBAC permissions, Resource Quotas, and default limits, depending on the workload.
        Spreading workloads across namespaces also allows you to limit the network communication between them with Network Policies.
      audit: |
        Check to ensure no workloads are running in the default Namespace. this command should return no CronJobs:

        ```yaml
        kubectl get cronjob -n default
        ```
      remediation: |
        For any CronJobs running in the default Namespace, update/redeploy the CronJobs to a non-default Namespace:

        ```yaml
        apiVersion:batch/v1
        kind: CronJob
        metadata:
          name: exampleCronJob
          namespace: cronjob-namespace # <--- Define a namespace for workloads
        ```
    refs:
      - url: https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-organizing-with-namespaces
        title: 'Kubernetes best practices: Organizing with Namespaces'
      - url: https://kubernetes.io/docs/concepts/services-networking/network-policies/
        title: Kubernetes Network Policies
      - url: https://kubernetes.io/docs/concepts/policy/limit-range/
        title: Kubernetes Limit Ranges
  - uid: mondoo-kubernetes-best-practices-pod-ports-hostport
    title: Pods should not bind to a host port
    impact: 40
    mql: |
      k8s.pod.podSpec {
        _['containers'] {
          _['name']
          _['ports'] == null || _['ports'].all(_['hostPort'] == null)
        }
      }
    docs:
      desc: |
        Pods should not bind to the underlying host port. Containers that bind to the underlying host's port(s) can be limited regarding where they are scheduled as two containers cannot both bind to the same host port on the same node.
        Host ports also expose the Container outside the Kubernetes cluster, which might not be intended.
      audit: |
        Check to ensure no Pods are binding any of their containers to a host port:

        ```kubectl get pods -A -o json | jq -r '.items[] | select( (.spec.containers[].ports | . != empty and any(.[].hostPort; . != empty)  ) ) | .metadata.namespace + "/" + .metadata.name'  | uniq```
      remediation: |
        For any Pods that bind to a host port, update the Pods (or the Deployments/DaemonSets/CronJobs/etc that produced the Pods) to ensure they do not bind to a host port:

        ```yaml
        apiVersion: v1
        kind: Pod
        metadata:
          name: example
          namespace: example-namespace
        spec:
          containers:
            - ports:
              - containerPort: 80 # <-- ensure no 'hostPort' is defined in any entries of the port configurations
                name: http
                protocol: TCP
              - containerPort: 443
                name: https
                protocol: TCP
        ```
    refs:
      - url: https://kubernetes.io/docs/concepts/configuration/overview/#services
        title: 'Kubernetes Configuration Best Practices: hostPort'
  - uid: mondoo-kubernetes-best-practices-daemonset-ports-hostport
    title: DaemonSets should not bind to a host port
    impact: 40
    mql: |
      k8s.daemonset.podSpec {
        _['containers'] {
          _['name']
          _['ports'] == null || _['ports'].all(_['hostPort'] == null)
        }
      }
    docs:
      desc: |
        DaemonSets should not bind to the underlying host port. Containers that bind to the underlying host's port(s) can be limited regarding where they are scheduled as two containers cannot both bind to the same host port on the same node.
        Host ports also expose the Container outside the Kubernetes cluster, which might not be intended.
      audit: |
        Check to ensure no DaemonSets are binding any of their containers to a host port:

        ```kubectl get daemonsets -A -o json | jq -r '.items[] | select( (.spec.template.spec.containers[].ports | . != empty and any(.[].hostPort; . != empty)  ) ) | .metadata.namespace + "/" + .metadata.name'  | uniq```
      remediation: |
        For any DaemonSets that bind to a host port, update the DaemonSets to ensure they do not bind to a host port:

        ```yaml
        apiVersion: apps/v1
        kind: DaemonSet
        metadata:
          name: example
          namespace: example-namespace
        spec:
          template:
            spec:
              containers:
                - ports:
                  - containerPort: 80 # <-- ensure no 'hostPort' is defined in any entries of the port configurations
                    name: http
                    protocol: TCP
                  - containerPort: 443
                    name: https
                    protocol: TCP
        ```
    refs:
      - url: https://kubernetes.io/docs/concepts/configuration/overview/#services
        title: 'Kubernetes Configuration Best Practices: hostPort'
  - uid: mondoo-kubernetes-best-practices-replicaset-ports-hostport
    title: ReplicaSets should not bind to a host port
    impact: 40
    mql: |
      k8s.replicaset.podSpec {
        _['containers'] {
          _['name']
          _['ports'] == null || _['ports'].all(_['hostPort'] == null)
        }
      }
    docs:
      desc: |
        ReplicaSets should not bind to the underlying host port. Containers that bind to the underlying host's port(s) can be limited regarding where they are scheduled as two containers cannot both bind to the same host port on the same node.
        Host ports also expose the Container outside the Kubernetes cluster, which might not be intended.
      audit: |
        Check to ensure no ReplicaSets are binding any of their containers to a host port:

        ```kubectl get replicasets -A -o json | jq -r '.items[] | select( (.spec.template.spec.containers[].ports | . != empty and any(.[].hostPort; . != empty)  ) ) | .metadata.namespace + "/" + .metadata.name'  | uniq```
      remediation: |
        For any ReplicaSets that bind to a host port, update the ReplicaSets to ensure they do not bind to a host port:

        ```yaml
        apiVersion: apps/v1
        kind: ReplicaSet
        metadata:
          name: example
          namespace: example-namespace
        spec:
          template:
            spec:
              containers:
                - ports:
                  - containerPort: 80 # <-- ensure no 'hostPort' is defined in any entries of the port configurations
                    name: http
                    protocol: TCP
                  - containerPort: 443
                    name: https
                    protocol: TCP
        ```
    refs:
      - url: https://kubernetes.io/docs/concepts/configuration/overview/#services
        title: 'Kubernetes Configuration Best Practices: hostPort'
  - uid: mondoo-kubernetes-best-practices-job-ports-hostport
    title: Jobs should not bind to a host port
    impact: 40
    mql: |
      k8s.job.podSpec {
        _['containers'] {
          _['name']
          _['ports'] == null || _['ports'].all(_['hostPort'] == null)
        }
      }
    docs:
      desc: |
        Jobs should not bind to the underlying host port. Containers that bind to the underlying host's port(s) can be limited regarding where they are scheduled as two containers cannot both bind to the same host port on the same node.
        Host ports also expose the Container outside the Kubernetes cluster, which might not be intended.
      audit: |
        Check to ensure no Jobs are binding any of their containers to a host port:

        ```kubectl get jobs -A -o json | jq -r '.items[] | select( (.spec.template.spec.containers[].ports | . != empty and any(.[].hostPort; . != empty)  ) ) | .metadata.namespace + "/" + .metadata.name'  | uniq```
      remediation: |
        For any ReplicaSets that bind to a host port, update the Jobs to ensure they do not bind to a host port:

        ```yaml
        apiVersion: batch/v1
        kind: Job
        metadata:
          name: example
          namespace: example-namespace
        spec:
          template:
            spec:
              containers:
                - ports:
                  - containerPort: 80 # <-- ensure no 'hostPort' is defined in any entries of the port configurations
                    name: http
                    protocol: TCP
                  - containerPort: 443
                    name: https
                    protocol: TCP
        ```
    refs:
      - url: https://kubernetes.io/docs/concepts/configuration/overview/#services
        title: 'Kubernetes Configuration Best Practices: hostPort'
  - uid: mondoo-kubernetes-best-practices-deployment-ports-hostport
    title: Deployments should not bind to a host port
    impact: 40
    mql: |
      k8s.deployment.podSpec {
        _['containers'] {
          _['name']
          _['ports'] == null || _['ports'].all(_['hostPort'] == null)
        }
      }
    docs:
      desc: |
        Deployments should not bind to the underlying host port. Containers that bind to the underlying host's port(s) can be limited regarding where they are scheduled as two containers cannot both bind to the same host port on the same node.
        Host ports also expose the Container outside the Kubernetes cluster, which might not be intended.
      audit: |
        Check to ensure no Deployments are binding any of their containers to a host port:

        ```kubectl get deployments -A -o json | jq -r '.items[] | select( (.spec.template.spec.containers[].ports | . != empty and any(.[].hostPort; . != empty)  ) ) | .metadata.namespace + "/" + .metadata.name'  | uniq```
      remediation: |
        For any Deployments that bind to a host port, update the Deployments to ensure they do not bind to a host port:

        ```yaml
        apiVersion: apps/v1
        kind: Deployment
        metadata:
          name: example
          namespace: example-namespace
        spec:
          template:
            spec:
              containers:
                - ports:
                  - containerPort: 80 # <-- ensure no 'hostPort' is defined in any entries of the port configurations
                    name: http
                    protocol: TCP
                  - containerPort: 443
                    name: https
                    protocol: TCP
        ```
    refs:
      - url: https://kubernetes.io/docs/concepts/configuration/overview/#services
        title: 'Kubernetes Configuration Best Practices: hostPort'
  - uid: mondoo-kubernetes-best-practices-statefulset-ports-hostport
    title: StatefulSets should not bind to a host port
    impact: 40
    mql: |
      k8s.statefulset.podSpec {
        _['containers'] {
          _['name']
          _['ports'] == null || _['ports'].all(_['hostPort'] == null)
        }
      }
    docs:
      desc: |
        StatefulSets should not bind to the underlying host port. Containers that bind to the underlying host's port(s) can be limited regarding where they are scheduled as two containers cannot both bind to the same host port on the same node.
        Host ports also expose the Container outside the Kubernetes cluster, which might not be intended.
      audit: |
        Check to ensure no StatefulSets are binding any of their containers to a host port:

        ```kubectl get statefulsets -A -o json | jq -r '.items[] | select( (.spec.template.spec.containers[].ports | . != empty and any(.[].hostPort; . != empty)  ) ) | .metadata.namespace + "/" + .metadata.name'  | uniq```
      remediation: |
        For any StatefulSets that bind to a host port, update the StatefulSets to ensure they do not bind to a host port:

        ```yaml
        apiVersion: apps/v1
        kind: StatefulSet
        metadata:
          name: example
          namespace: example-namespace
        spec:
          template:
            spec:
              containers:
                - ports:
                  - containerPort: 80 # <-- ensure no 'hostPort' is defined in any entries of the port configurations
                    name: http
                    protocol: TCP
                  - containerPort: 443
                    name: https
                    protocol: TCP
        ```
    refs:
      - url: https://kubernetes.io/docs/concepts/configuration/overview/#services
        title: 'Kubernetes Configuration Best Practices: hostPort'
  - uid: mondoo-kubernetes-best-practices-cronjob-ports-hostport
    title: CronJobs should not bind to a host port
    impact: 40
    mql: |
      k8s.cronjob.podSpec {
        _['containers'] {
          _['name']
          _['ports'] == null || _['ports'].all(_['hostPort'] == null)
        }
      }
    docs:
      desc: |
        CronJobs should not bind to the underlying host port. Containers that bind to the underlying host's port(s) can be limited regarding where they are scheduled as two containers cannot both bind to the same host port on the same node.
        Host ports also expose the Container outside the Kubernetes cluster, which might not be intended.
      audit: |
        Check to ensure no CronJobs are binding any of their containers to a host port:

        ```kubectl get cronjobs -A -o json | jq -r '.items[] | select( (.spec.jobTemplate.spec.template.spec.containers[].ports | . != empty and any(.[].hostPort; . != empty)  ) ) | .metadata.namespace + "/" + .metadata.name'  | uniq```
      remediation: |
        For any CronJobs that bind to a host port, update the CronJobs to ensure they do not bind to a host port:

        ```yaml
        apiVersion: batch/v1
        kind: CronJob
        metadata:
          name: example
          namespace: example-namespace
        spec:
          jobTemplate:
            spec:
              template:
                spec:
                  containers:
                    - ports:
                      - containerPort: 80 # <-- ensure no 'hostPort' is defined in any entries of the port configurations
                        name: http
                        protocol: TCP
                      - containerPort: 443
                        name: https
                        protocol: TCP
        ```
    refs:
      - url: https://kubernetes.io/docs/concepts/configuration/overview/#services
        title: 'Kubernetes Configuration Best Practices: hostPort'
  - uid: mondoo-kubernetes-best-practices-ingress-cert-expiration
    title: Ingress certificates less than 15 days from expiration
    impact: 40
    mql: |
      k8s.ingress.tls.all(
        certificates.all(
          expiresIn.days > 15
        )
      )
    docs:
      desc: |
        If Ingress resources have TLS certificate Secrets, update the certificates updated before they expire.
      audit: |
        Check to ensure no Ingress Secrets contain TLS certificates near expiration:

        Display all Ingress resources with TLS Secret data:
        ```kubectl get ingress -A -o json | jq -r '.items[] | select(.spec.tls != empty) | .metadata.namespace + "/" + .metadata.name'```

        For each Ingress resource, check the certificate expiration dates in the Secrets (under `.spec.tls[].secretName`). Ensure that the expiration dates don't expire soon:
        ```kubectl get secret --namespace NAMESPACE_OF_INGRESS NAME_OF_SECRET -o json | jq -r '.data["tls.crt"]' | base64 -d | openssl x509 -noout -text | grep "Not After"```
      remediation: |
        For all Secrets with expired or soon-to-expire certificates, update the Secret data with refreshed certificates.