ubuntu-overview.json

{
  "name": "ubuntu",
  "title": "InSpec Profile",
  "maintainer": "The Authors",
  "copyright": "The Authors",
  "copyright_email": "you@example.com",
  "license": "Apache-2.0",
  "summary": "An InSpec Compliance Profile",
  "version": "0.1.0",
  "supports": [],
  "controls": [
    {
      "title": "1.1 Ensure a separate partition for containers has been created\n(Scored)",
      "desc": "All Docker containers and their data and metadata is stored under\n/var/lib/docker\n    directory. By default, /var/lib/docker would be mounted under / or /var\npartitions based\n    on availability.\n    Docker depends on /var/lib/docker as the default directory where all Docker\nrelated files,\n    including the images, are stored. This directory might fill up fast and\nsoon Docker and the\n    host could become unusable. So, it is advisable to create a separate\npartition (logical\n    volume) for storing Docker files.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://www.projectatomic.io/docs/docker-storage-recommendation/\n",
        "severity": "medium",
        "cis_id": "1.1",
        "cis_control": "14 Controlled Access Based on the Need to Know\n",
        "cis_level": "Level 1 - Linux Host OS",
        "nist": [
          "AC-6"
        ],
        "audit": "At the Docker host execute the below command:\ngrep\n/var/lib/docker /etc/fstab\nThis should return the partition details for\n/var/lib/docker mount point.\n",
        "fix": "For new installations, create a separate partition for\n/var/lib/docker mount point. For\nsystems that were previously installed, use\nthe Logical Volume Manager (LVM) to create\npartitions.\n",
        "Default Value": "By default, /var/lib/docker would be mounted under / or\n/var partitions based on\navailability.\n"
      },
      "code": "control \"M-1.1\" do\n  title \"1.1 Ensure a separate partition for containers has been created\n(Scored)\"\n  desc  \"\n    All Docker containers and their data and metadata is stored under\n/var/lib/docker\n    directory. By default, /var/lib/docker would be mounted under / or /var\npartitions based\n    on availability.\n    Docker depends on /var/lib/docker as the default directory where all Docker\nrelated files,\n    including the images, are stored. This directory might fill up fast and\nsoon Docker and the\n    host could become unusable. So, it is advisable to create a separate\npartition (logical\n    volume) for storing Docker files.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://www.projectatomic.io/docs/docker-storage-recommendation/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"1.1\"\n  tag \"cis_control\": \"14 Controlled Access Based on the Need to Know\\n\"\n  tag \"cis_level\": \"Level 1 - Linux Host OS\"\n  tag \"nist\": [\"AC-6\"]\n  tag \"audit\": \"At the Docker host execute the below command:\\ngrep\n/var/lib/docker /etc/fstab\\nThis should return the partition details for\n/var/lib/docker mount point.\\n\"\n  tag \"fix\": \"For new installations, create a separate partition for\n/var/lib/docker mount point. For\\nsystems that were previously installed, use\nthe Logical Volume Manager (LVM) to create\\npartitions.\\n\"\n  tag \"Default Value\": \"By default, /var/lib/docker would be mounted under / or\n/var partitions based on\\navailability.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-1.1.rb",
        "line": 1
      },
      "id": "M-1.1"
    },
    {
      "title": "1.10 Ensure auditing is configured for Docker files and directories\n/etc/default/docker (Scored)",
      "desc": "Audit /etc/default/docker, if applicable.\n    Apart from auditing your regular Linux file system and system calls, audit\nall Docker\n    related files and directories. Docker daemon runs with root privileges. Its\nbehavior\n    depends on some key files and directories. /etc/default/docker is one such\nfile. It holds\n    various parameters for Docker daemon. It must be audited, if applicable.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://access.redhat.com/documentation/enUS/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-system_auditing.html\n",
        "severity": "medium",
        "cis_id": "1.10",
        "cis_control": "14.6 Enforce Detailed Audit Logging For Sensitive\nInformation\n",
        "cis_level": "Level 1 - Linux Host OS",
        "nist": [
          "AU-2"
        ],
        "audit": "Verify that there is an audit rule corresponding to\n/etc/default/docker file.\nFor example, execute below command:\nauditctl -l |\ngrep /etc/default/docker\nThis should list a rule for /etc/default/docker\nfile.\n",
        "fix": "Add a rule for /etc/default/docker file.\nFor example,\nAdd the\nline as below in /etc/audit/audit.rules file:\n-w /etc/default/docker -k\ndocker\nThen, restart the audit daemon. For example,\nservice auditd restart\n",
        "Default Value": "By default, Docker related files and directories are\nnot audited. The file\n/etc/default/docker may not be available on the system.\nIn that case, this\nrecommendation is not applicable.\n"
      },
      "code": "control \"M-1.10\" do\n  title \"1.10 Ensure auditing is configured for Docker files and directories\n/etc/default/docker (Scored)\"\n  desc  \"\n    Audit /etc/default/docker, if applicable.\n    Apart from auditing your regular Linux file system and system calls, audit\nall Docker\n    related files and directories. Docker daemon runs with root privileges. Its\nbehavior\n    depends on some key files and directories. /etc/default/docker is one such\nfile. It holds\n    various parameters for Docker daemon. It must be audited, if applicable.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://access.redhat.com/documentation/enUS/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-system_auditing.html\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"1.10\"\n  tag \"cis_control\": \"14.6 Enforce Detailed Audit Logging For Sensitive\nInformation\\n\"\n  tag \"cis_level\": \"Level 1 - Linux Host OS\"\n  tag \"nist\": [\"AU-2\"]\n  tag \"audit\": \"Verify that there is an audit rule corresponding to\n/etc/default/docker file.\\nFor example, execute below command:\\nauditctl -l |\ngrep /etc/default/docker\\nThis should list a rule for /etc/default/docker\nfile.\\n\"\n  tag \"fix\": \"Add a rule for /etc/default/docker file.\\nFor example,\\nAdd the\nline as below in /etc/audit/audit.rules file:\\n-w /etc/default/docker -k\ndocker\\nThen, restart the audit daemon. For example,\\nservice auditd restart\\n\"\n  tag \"Default Value\": \"By default, Docker related files and directories are\nnot audited. The file\\n/etc/default/docker may not be available on the system.\nIn that case, this\\nrecommendation is not applicable.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-1.10.rb",
        "line": 1
      },
      "id": "M-1.10"
    },
    {
      "title": "1.11 Ensure auditing is configured for Docker files and directories\n/etc/docker/daemon.json (Scored)",
      "desc": "Audit /etc/docker/daemon.json, if applicable.\n    Apart from auditing your regular Linux file system and system calls, audit\nall Docker\n    related files and directories. Docker daemon runs with root privileges. Its\nbehavior\n    depends on some key files and directories. /etc/docker/daemon.json is one\nsuch file. It\n    holds various parameters for Docker daemon. It must be audited, if\napplicable.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://access.redhat.com/documentation/enUS/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-system_auditing.html\n2.\nhttps://docs.docker.com/engine/reference/commandline/dockerd/#daemonconfiguration-file\n",
        "severity": "medium",
        "cis_id": "1.11",
        "cis_control": "14.6 Enforce Detailed Audit Logging For Sensitive\nInformation\n",
        "cis_level": "Level 1 - Linux Host OS",
        "nist": [
          "AU-2"
        ],
        "audit": "Verify that there is an audit rule corresponding to\n/etc/docker/daemon.json file.\nFor example, execute below command:\nauditctl -l\n| grep /etc/docker/daemon.json\nThis should list a rule for\n/etc/docker/daemon.json file.\n",
        "fix": "Add a rule for /etc/docker/daemon.json file.\nFor example,\nAdd\nthe line as below in /etc/audit/audit.rules file:\n-w /etc/docker/daemon.json\n-k docker\nThen, restart the audit daemon. For example,\nservice auditd\nrestart\n",
        "Default Value": "By default, Docker related files and directories are\nnot audited. The file\n/etc/docker/daemon.json may not be available on the\nsystem. In that case, this\nrecommendation is not applicable.\n"
      },
      "code": "control \"M-1.11\" do\n  title \"1.11 Ensure auditing is configured for Docker files and directories\n/etc/docker/daemon.json (Scored)\"\n  desc  \"\n    Audit /etc/docker/daemon.json, if applicable.\n    Apart from auditing your regular Linux file system and system calls, audit\nall Docker\n    related files and directories. Docker daemon runs with root privileges. Its\nbehavior\n    depends on some key files and directories. /etc/docker/daemon.json is one\nsuch file. It\n    holds various parameters for Docker daemon. It must be audited, if\napplicable.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://access.redhat.com/documentation/enUS/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-system_auditing.html\\n2.\nhttps://docs.docker.com/engine/reference/commandline/dockerd/#daemonconfiguration-file\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"1.11\"\n  tag \"cis_control\": \"14.6 Enforce Detailed Audit Logging For Sensitive\nInformation\\n\"\n  tag \"cis_level\": \"Level 1 - Linux Host OS\"\n  tag \"nist\": [\"AU-2\"]\n  tag \"audit\": \"Verify that there is an audit rule corresponding to\n/etc/docker/daemon.json file.\\nFor example, execute below command:\\nauditctl -l\n| grep /etc/docker/daemon.json\\nThis should list a rule for\n/etc/docker/daemon.json file.\\n\"\n  tag \"fix\": \"Add a rule for /etc/docker/daemon.json file.\\nFor example,\\nAdd\nthe line as below in /etc/audit/audit.rules file:\\n-w /etc/docker/daemon.json\n-k docker\\nThen, restart the audit daemon. For example,\\nservice auditd\nrestart\\n\"\n  tag \"Default Value\": \"By default, Docker related files and directories are\nnot audited. The file\\n/etc/docker/daemon.json may not be available on the\nsystem. In that case, this\\nrecommendation is not applicable.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-1.11.rb",
        "line": 1
      },
      "id": "M-1.11"
    },
    {
      "title": "1.12 Ensure auditing is configured for Docker files and directories\n/usr/bin/docker-containerd (Scored)",
      "desc": "Audit /usr/bin/docker-containerd, if applicable.\n    Apart from auditing your regular Linux file system and system calls, audit\nall Docker\n    related files and directories. Docker daemon runs with root privileges. Its\nbehavior\n    depends on some key files and directories. /usr/bin/docker-containerd is\none such file.\n    Docker now relies on containerdand runC to spawn containers. It must be\naudited, if\n    applicable.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://access.redhat.com/documentation/enUS/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-system_auditing.html\n2.\nhttps://github.com/docker/docker/pull/20662\n3. https://containerd.tools/\n",
        "severity": "medium",
        "cis_id": "1.12",
        "cis_control": "14.6 Enforce Detailed Audit Logging For Sensitive\nInformation\n",
        "cis_level": "Level 1 - Linux Host OS",
        "nist": [
          "AU-2"
        ],
        "audit": "Verify that there is an audit rule corresponding to\n/usr/bin/docker-containerd file.\nFor example, execute below command:\nauditctl\n-l | grep /usr/bin/docker-containerd\nThis should list a rule for\n/usr/bin/docker-containerd file.\n",
        "fix": "Add a rule for /usr/bin/docker-containerd file.\nFor\nexample,\nAdd the line as below in /etc/audit/audit.rules file:\n-w\n/usr/bin/docker-containerd -k docker\nThen, restart the audit daemon. For\nexample,\nservice auditd restart\n",
        "Default Value": "By default, Docker related files and directories are\nnot audited. The file /usr/bin/dockercontainerd may not be available on the\nsystem. In that case, this recommendation is not\napplicable.\n"
      },
      "code": "control \"M-1.12\" do\n  title \"1.12 Ensure auditing is configured for Docker files and directories\n/usr/bin/docker-containerd (Scored)\"\n  desc  \"\n    Audit /usr/bin/docker-containerd, if applicable.\n    Apart from auditing your regular Linux file system and system calls, audit\nall Docker\n    related files and directories. Docker daemon runs with root privileges. Its\nbehavior\n    depends on some key files and directories. /usr/bin/docker-containerd is\none such file.\n    Docker now relies on containerdand runC to spawn containers. It must be\naudited, if\n    applicable.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://access.redhat.com/documentation/enUS/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-system_auditing.html\\n2.\nhttps://github.com/docker/docker/pull/20662\\n3. https://containerd.tools/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"1.12\"\n  tag \"cis_control\": \"14.6 Enforce Detailed Audit Logging For Sensitive\nInformation\\n\"\n  tag \"cis_level\": \"Level 1 - Linux Host OS\"\n  tag \"nist\": [\"AU-2\"]\n  tag \"audit\": \"Verify that there is an audit rule corresponding to\n/usr/bin/docker-containerd file.\\nFor example, execute below command:\\nauditctl\n-l | grep /usr/bin/docker-containerd\\nThis should list a rule for\n/usr/bin/docker-containerd file.\\n\"\n  tag \"fix\": \"Add a rule for /usr/bin/docker-containerd file.\\nFor\nexample,\\nAdd the line as below in /etc/audit/audit.rules file:\\n-w\n/usr/bin/docker-containerd -k docker\\nThen, restart the audit daemon. For\nexample,\\nservice auditd restart\\n\"\n  tag \"Default Value\": \"By default, Docker related files and directories are\nnot audited. The file /usr/bin/dockercontainerd may not be available on the\nsystem. In that case, this recommendation is not\\napplicable.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-1.12.rb",
        "line": 1
      },
      "id": "M-1.12"
    },
    {
      "title": "1.13 Ensure auditing is configured for Docker files and directories\n/usr/bin/docker-runc (Scored)",
      "desc": "Audit /usr/bin/docker-runc, if applicable.\n    Apart from auditing your regular Linux file system and system calls, audit\nall Docker\n    related files and directories. Docker daemon runs with root privileges. Its\nbehavior\n    depends on some key files and directories. /usr/bin/docker-runc is one such\nfile. Docker\n    now relies on containerd and runC to spawn containers. It must be audited,\nif applicable.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://access.redhat.com/documentation/enUS/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-system_auditing.html\n2.\nhttps://github.com/docker/docker/pull/20662\n3. https://containerd.tools/\n4.\nhttps://github.com/opencontainers/runc\n",
        "severity": "medium",
        "cis_id": "1.13",
        "cis_control": "14.6 Enforce Detailed Audit Logging For Sensitive\nInformation\n",
        "cis_level": "Level 1 - Linux Host OS",
        "nist": [
          "AU-2"
        ],
        "audit": "Verify that there is an audit rule corresponding to\n/usr/bin/docker-runc file.\nFor example, execute below command:\nauditctl -l |\ngrep /usr/bin/docker-runc\nThis should list a rule for /usr/bin/docker-runc\nfile.\n",
        "fix": "Add a rule for /usr/bin/docker-runc file.\nFor example,\nAdd the\nline as below in /etc/audit/audit.rules file:\n-w /usr/bin/docker-runc -k\ndocker\nThen, restart the audit daemon. For example,\nservice auditd restart\n",
        "Default Value": "By default, Docker related files and directories are\nnot audited. The file/usr/bin/dockerrunc may not be available on the system. In\nthat case, this recommendation is not\napplicable.\n"
      },
      "code": "control \"M-1.13\" do\n  title \"1.13 Ensure auditing is configured for Docker files and directories\n/usr/bin/docker-runc (Scored)\"\n  desc  \"\n    Audit /usr/bin/docker-runc, if applicable.\n    Apart from auditing your regular Linux file system and system calls, audit\nall Docker\n    related files and directories. Docker daemon runs with root privileges. Its\nbehavior\n    depends on some key files and directories. /usr/bin/docker-runc is one such\nfile. Docker\n    now relies on containerd and runC to spawn containers. It must be audited,\nif applicable.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://access.redhat.com/documentation/enUS/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-system_auditing.html\\n2.\nhttps://github.com/docker/docker/pull/20662\\n3. https://containerd.tools/\\n4.\nhttps://github.com/opencontainers/runc\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"1.13\"\n  tag \"cis_control\": \"14.6 Enforce Detailed Audit Logging For Sensitive\nInformation\\n\"\n  tag \"cis_level\": \"Level 1 - Linux Host OS\"\n  tag \"nist\": [\"AU-2\"]\n  tag \"audit\": \"Verify that there is an audit rule corresponding to\n/usr/bin/docker-runc file.\\nFor example, execute below command:\\nauditctl -l |\ngrep /usr/bin/docker-runc\\nThis should list a rule for /usr/bin/docker-runc\nfile.\\n\"\n  tag \"fix\": \"Add a rule for /usr/bin/docker-runc file.\\nFor example,\\nAdd the\nline as below in /etc/audit/audit.rules file:\\n-w /usr/bin/docker-runc -k\ndocker\\nThen, restart the audit daemon. For example,\\nservice auditd restart\\n\"\n  tag \"Default Value\": \"By default, Docker related files and directories are\nnot audited. The file/usr/bin/dockerrunc may not be available on the system. In\nthat case, this recommendation is not\\napplicable.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-1.13.rb",
        "line": 1
      },
      "id": "M-1.13"
    },
    {
      "title": "1.2 Ensure the container host has been Hardened (Not Scored)",
      "desc": "Containers run on a Linux host. A container host can run one or more\ncontainers. It is of\n    utmost importance to harden the host to mitigate host security\nmisconfiguration.\n    You should follow infrastructure security best practices and harden your\nhost OS. Keeping\n    the host system hardened would ensure that the host vulnerabilities are\nmitigated. Not\n    hardening the host system could lead to security exposures and breaches.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://docs.docker.com/engine/security/security/\n2.\n3.\n4.\n5.\n6.\n7.\nhttps://learn.cisecurity.org/benchmarks\nhttps://docs.docker.com/engine/security/security/#other-kernel-security-features\nhttps://grsecurity.net/\nhttps://en.wikibooks.org/wiki/Grsecurity\nhttps://pax.grsecurity.net/\nhttp://en.wikipedia.org/wiki/PaX\n",
        "severity": "medium",
        "cis_id": "1.2",
        "cis_control": "3 Secure Configurations for Hardware and Software on\nMobile Devices, Laptops,\n",
        "cis_level": "Level 1 - Linux Host OS",
        "nist": [
          "CM-6"
        ],
        "audit": "Ensure that the host specific security guidelines are followed.\nAsk the system\nadministrators which security benchmark does current host\nsystem comply with. Ensure\nthat the host systems actually comply with that\nhost specific security benchmark.\n",
        "fix": "You may consider various CIS Security Benchmarks for your\ncontainer host. If you have\nother security guidelines or regulatory\nrequirements to adhere to, please follow them as\nsuitable in your\nenvironment.\nAdditionally, you can run a kernel with grsecurity and PaX. This\nwould add many safety\nchecks, both at compile-time and run-time. It is also\ndesigned to defeat many exploits and\nhas powerful security features. These\nfeatures do not require Docker-specific\nconfiguration, since those security\nfeatures apply system-wide, independent of containers.\n",
        "Default Value": "By default, host has factory settings. It is not\nhardened.\n"
      },
      "code": "control \"M-1.2\" do\n  title \"1.2 Ensure the container host has been Hardened (Not Scored)\"\n  desc  \"\n    Containers run on a Linux host. A container host can run one or more\ncontainers. It is of\n    utmost importance to harden the host to mitigate host security\nmisconfiguration.\n    You should follow infrastructure security best practices and harden your\nhost OS. Keeping\n    the host system hardened would ensure that the host vulnerabilities are\nmitigated. Not\n    hardening the host system could lead to security exposures and breaches.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://docs.docker.com/engine/security/security/\\n2.\\n3.\\n4.\\n5.\\n6.\\n7.\\nhttps://learn.cisecurity.org/benchmarks\\nhttps://docs.docker.com/engine/security/security/#other-kernel-security-features\\nhttps://grsecurity.net/\\nhttps://en.wikibooks.org/wiki/Grsecurity\\nhttps://pax.grsecurity.net/\\nhttp://en.wikipedia.org/wiki/PaX\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"1.2\"\n  tag \"cis_control\": \"3 Secure Configurations for Hardware and Software on\nMobile Devices, Laptops,\\n\"\n  tag \"cis_level\": \"Level 1 - Linux Host OS\"\n  tag \"nist\": [\"CM-6\"]\n  tag \"audit\": \"Ensure that the host specific security guidelines are followed.\nAsk the system\\nadministrators which security benchmark does current host\nsystem comply with. Ensure\\nthat the host systems actually comply with that\nhost specific security benchmark.\\n\"\n  tag \"fix\": \"You may consider various CIS Security Benchmarks for your\ncontainer host. If you have\\nother security guidelines or regulatory\nrequirements to adhere to, please follow them as\\nsuitable in your\nenvironment.\\nAdditionally, you can run a kernel with grsecurity and PaX. This\nwould add many safety\\nchecks, both at compile-time and run-time. It is also\ndesigned to defeat many exploits and\\nhas powerful security features. These\nfeatures do not require Docker-specific\\nconfiguration, since those security\nfeatures apply system-wide, independent of containers.\\n\"\n  tag \"Default Value\": \"By default, host has factory settings. It is not\nhardened.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-1.2.rb",
        "line": 1
      },
      "id": "M-1.2"
    },
    {
      "title": "1.3 Ensure Docker is up to date (Not Scored)",
      "desc": "There are frequent releases for Docker software that address security\nvulnerabilities,\n    product bugs and bring in new functionality. Keep a tab on these product\nupdates and\n    upgrade as frequently as when new security vulnerabilities are fixed or\ndeemed correct for\n    your organization.\n    By staying up to date on Docker updates, vulnerabilities in the Docker\nsoftware can be\n    mitigated. An educated attacker may exploit known vulnerabilities when\nattempting to\n    attain access or elevate privileges. Not installing regular Docker updates\nmay leave you\n    with running vulnerable Docker software. It might lead to elevation\nprivileges,\n    unauthorized access or other security breaches. Keep a track of new\nreleases and update as\n    necessary.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://docs.docker.com/engine/installation/\n2.\nhttps://github.com/moby/moby/releases/latest\n3.\nhttps://github.com/docker/docker-ce/releases/latest\n",
        "severity": "medium",
        "cis_id": "1.3",
        "cis_control": "4 Continuous Vulnerability Assessment and Remediation\n",
        "cis_level": "Level 1 - Linux Host OS",
        "nist": [
          "RA-5"
        ],
        "audit": "Execute the below command and verify that the Docker version is\nup to date as deemed\nnecessary. It is not a mandate to be on the latest one,\nthough.\ndocker version\n",
        "fix": "Keep a track of Docker releases and update as necessary.\n",
        "Default Value": "Not Applicable\n"
      },
      "code": "control \"M-1.3\" do\n  title \"1.3 Ensure Docker is up to date (Not Scored)\"\n  desc  \"\n    There are frequent releases for Docker software that address security\nvulnerabilities,\n    product bugs and bring in new functionality. Keep a tab on these product\nupdates and\n    upgrade as frequently as when new security vulnerabilities are fixed or\ndeemed correct for\n    your organization.\n    By staying up to date on Docker updates, vulnerabilities in the Docker\nsoftware can be\n    mitigated. An educated attacker may exploit known vulnerabilities when\nattempting to\n    attain access or elevate privileges. Not installing regular Docker updates\nmay leave you\n    with running vulnerable Docker software. It might lead to elevation\nprivileges,\n    unauthorized access or other security breaches. Keep a track of new\nreleases and update as\n    necessary.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://docs.docker.com/engine/installation/\\n2.\nhttps://github.com/moby/moby/releases/latest\\n3.\nhttps://github.com/docker/docker-ce/releases/latest\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"1.3\"\n  tag \"cis_control\": \"4 Continuous Vulnerability Assessment and Remediation\\n\"\n  tag \"cis_level\": \"Level 1 - Linux Host OS\"\n  tag \"nist\": [\"RA-5\"]\n  tag \"audit\": \"Execute the below command and verify that the Docker version is\nup to date as deemed\\nnecessary. It is not a mandate to be on the latest one,\nthough.\\ndocker version\\n\"\n  tag \"fix\": \"Keep a track of Docker releases and update as necessary.\\n\"\n  tag \"Default Value\": \"Not Applicable\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-1.3.rb",
        "line": 1
      },
      "id": "M-1.3"
    },
    {
      "title": "1.4 Ensure only trusted users are allowed to control Docker\ndaemon(Scored)",
      "desc": "The Docker daemon currently requires root privileges. A user added to the\ndocker group\n    gives him full root access rights.\n    Docker allows you to share a directory between the Docker host and a guest\ncontainer\n    without limiting the access rights of the container. This means that you\ncan start a\n    container and map the / directory on your host to the container. The\ncontainer will then be\n    able to alter your host file system without any restrictions. In simple\nterms, it means that\n    you can attain elevated privileges with just being a member of the docker\ngroup and then\n    starting a container with mapped / directory on the host.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://docs.docker.com/engine/security/security/#docker-daemon-attacksurface\n2.\nhttps://www.andreas-jung.com/contents/on-docker-security-docker-groupconsidered-harmful\n3.\nhttp://www.projectatomic.io/blog/2015/08/why-we-dont-let-non-root-users-rundocker-in-centos-fedora-or-rhel/\n",
        "severity": "medium",
        "cis_id": "1.4",
        "cis_control": "5.1 Minimize And Sparingly Use Administrative\nPrivileges\n",
        "cis_level": "Level 1 - Linux Host OS",
        "nist": [
          "AC-6 (9)"
        ],
        "audit": "Execute the below command on the docker host and ensure that\nonly trusted users are\nmembers of the docker group.\ngetent group docker\n",
        "fix": "Remove any users from the docker group that are not trusted.\nAdditionally, do not create a\nmapping of sensitive directories on host to\ncontainer volumes.\n",
        "Default Value": "Not Applicable\n"
      },
      "code": "control \"M-1.4\" do\n  title \"1.4 Ensure only trusted users are allowed to control Docker\ndaemon(Scored)\"\n  desc  \"\n    The Docker daemon currently requires root privileges. A user added to the\ndocker group\n    gives him full root access rights.\n    Docker allows you to share a directory between the Docker host and a guest\ncontainer\n    without limiting the access rights of the container. This means that you\ncan start a\n    container and map the / directory on your host to the container. The\ncontainer will then be\n    able to alter your host file system without any restrictions. In simple\nterms, it means that\n    you can attain elevated privileges with just being a member of the docker\ngroup and then\n    starting a container with mapped / directory on the host.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://docs.docker.com/engine/security/security/#docker-daemon-attacksurface\\n2.\nhttps://www.andreas-jung.com/contents/on-docker-security-docker-groupconsidered-harmful\\n3.\nhttp://www.projectatomic.io/blog/2015/08/why-we-dont-let-non-root-users-rundocker-in-centos-fedora-or-rhel/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"1.4\"\n  tag \"cis_control\": \"5.1 Minimize And Sparingly Use Administrative\nPrivileges\\n\"\n  tag \"cis_level\": \"Level 1 - Linux Host OS\"\n  tag \"nist\": [\"AC-6 (9)\"]\n  tag \"audit\": \"Execute the below command on the docker host and ensure that\nonly trusted users are\\nmembers of the docker group.\\ngetent group docker\\n\"\n  tag \"fix\": \"Remove any users from the docker group that are not trusted.\nAdditionally, do not create a\\nmapping of sensitive directories on host to\ncontainer volumes.\\n\"\n  tag \"Default Value\": \"Not Applicable\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-1.4.rb",
        "line": 1
      },
      "id": "M-1.4"
    },
    {
      "title": "1.5 Ensure auditing is configured for the docker daemon (Scored)",
      "desc": "Audit all Docker daemon activities.\n    Apart from auditing your regular Linux file system and system calls, audit\nDocker daemon\n    as well. Docker daemon runs with root privileges. It is thus necessary to\naudit its activities\n    and usage.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://access.redhat.com/documentation/enUS/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-system_auditing.html\n",
        "severity": "medium",
        "cis_id": "1.5",
        "cis_control": "6.2 Ensure Audit Log Settings Support Appropriate Log\nEntry Formatting\n",
        "cis_level": "Level 1 - Linux Host OS",
        "nist": [
          "AU-3"
        ],
        "audit": "Verify that there is an audit rule for Docker daemon. For\nexample, execute below\ncommand:\nauditctl -l | grep /usr/bin/docker\nThis\nshould list a rule for Docker daemon.\n",
        "fix": "Add a rule for Docker daemon.\nFor example,\nAdd the line as\nbelow line in /etc/audit/audit.rules file:\n-w /usr/bin/docker -k docker\nThen,\nrestart the audit daemon. For example,\nservice auditd restart\n",
        "Default Value": "By default, Docker daemon is not audited.\n"
      },
      "code": "control \"M-1.5\" do\n  title \"1.5 Ensure auditing is configured for the docker daemon (Scored)\"\n  desc  \"\n    Audit all Docker daemon activities.\n    Apart from auditing your regular Linux file system and system calls, audit\nDocker daemon\n    as well. Docker daemon runs with root privileges. It is thus necessary to\naudit its activities\n    and usage.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://access.redhat.com/documentation/enUS/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-system_auditing.html\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"1.5\"\n  tag \"cis_control\": \"6.2 Ensure Audit Log Settings Support Appropriate Log\nEntry Formatting\\n\"\n  tag \"cis_level\": \"Level 1 - Linux Host OS\"\n  tag \"nist\": [\"AU-3\"]\n  tag \"audit\": \"Verify that there is an audit rule for Docker daemon. For\nexample, execute below\\ncommand:\\nauditctl -l | grep /usr/bin/docker\\nThis\nshould list a rule for Docker daemon.\\n\"\n  tag \"fix\": \"Add a rule for Docker daemon.\\nFor example,\\nAdd the line as\nbelow line in /etc/audit/audit.rules file:\\n-w /usr/bin/docker -k docker\\nThen,\nrestart the audit daemon. For example,\\nservice auditd restart\\n\"\n  tag \"Default Value\": \"By default, Docker daemon is not audited.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-1.5.rb",
        "line": 1
      },
      "id": "M-1.5"
    },
    {
      "title": "1.6 Ensure auditing is configured for Docker files and directories\n/var/lib/docker (Scored)",
      "desc": "Audit /var/lib/docker.\n    Apart from auditing your regular Linux file system and system calls, audit\nall Docker\n    related files and directories. Docker daemon runs with root privileges. Its\nbehavior\n    depends on some key files and directories. /var/lib/docker is one such\ndirectory. It holds\n    all the information about containers. It must be audited.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://access.redhat.com/documentation/enUS/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-system_auditing.html\n",
        "severity": "medium",
        "cis_id": "1.6",
        "cis_control": "14.6 Enforce Detailed Audit Logging For Sensitive\nInformation\n",
        "cis_level": "Level 1 - Linux Host OS",
        "nist": [
          "AU-2"
        ],
        "audit": "Verify that there is an audit rule corresponding to\n/var/lib/docker directory.\nFor example, execute below command:\nauditctl -l |\ngrep /var/lib/docker\nThis should list a rule for /var/lib/docker directory.\n",
        "fix": "Add a rule for /var/lib/docker directory.\nFor example,\nAdd the\nline as below in /etc/audit/audit.rules file:\n-w /var/lib/docker -k\ndocker\nThen, restart the audit daemon. For example,\nservice auditd restart\n",
        "Default Value": "By default, Docker related files and directories are\nnot audited.\n"
      },
      "code": "control \"M-1.6\" do\n  title \"1.6 Ensure auditing is configured for Docker files and directories\n/var/lib/docker (Scored)\"\n  desc  \"\n    Audit /var/lib/docker.\n    Apart from auditing your regular Linux file system and system calls, audit\nall Docker\n    related files and directories. Docker daemon runs with root privileges. Its\nbehavior\n    depends on some key files and directories. /var/lib/docker is one such\ndirectory. It holds\n    all the information about containers. It must be audited.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://access.redhat.com/documentation/enUS/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-system_auditing.html\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"1.6\"\n  tag \"cis_control\": \"14.6 Enforce Detailed Audit Logging For Sensitive\nInformation\\n\"\n  tag \"cis_level\": \"Level 1 - Linux Host OS\"\n  tag \"nist\": [\"AU-2\"]\n  tag \"audit\": \"Verify that there is an audit rule corresponding to\n/var/lib/docker directory.\\nFor example, execute below command:\\nauditctl -l |\ngrep /var/lib/docker\\nThis should list a rule for /var/lib/docker directory.\\n\"\n  tag \"fix\": \"Add a rule for /var/lib/docker directory.\\nFor example,\\nAdd the\nline as below in /etc/audit/audit.rules file:\\n-w /var/lib/docker -k\ndocker\\nThen, restart the audit daemon. For example,\\nservice auditd restart\\n\"\n  tag \"Default Value\": \"By default, Docker related files and directories are\nnot audited.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-1.6.rb",
        "line": 1
      },
      "id": "M-1.6"
    },
    {
      "title": "1.7 Ensure auditing is configured for Docker files and directories\n/etc/docker (Scored)",
      "desc": "Audit /etc/docker.\n    Apart from auditing your regular Linux file system and system calls, audit\nall Docker\n    related files and directories. Docker daemon runs with root privileges. Its\nbehavior\n    depends on some key files and directories. /etc/docker is one such\ndirectory. It holds\n    various certificates and keys used for TLS communication between Docker\ndaemon and\n    Docker client. It must be audited.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://access.redhat.com/documentation/enUS/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-system_auditing.html\n",
        "severity": "medium",
        "cis_id": "1.7",
        "cis_control": "14.6 Enforce Detailed Audit Logging For Sensitive\nInformation\n",
        "cis_level": "Level 1 - Linux Host OS",
        "nist": [
          "AU-2"
        ],
        "audit": "Verify that there is an audit rule corresponding to /etc/docker\ndirectory.\nFor example, execute below command:\nauditctl -l | grep\n/etc/docker\nThis should list a rule for /etc/docker directory.\n",
        "fix": "Add a rule for /etc/docker directory.\nFor example,\nAdd the line\nas below in /etc/audit/audit.rules file:\n-w /etc/docker -k docker\nThen,\nrestart the audit daemon. For example,\nservice auditd restart\n",
        "Default Value": "By default, Docker related files and directories are\nnot audited.\n"
      },
      "code": "control \"M-1.7\" do\n  title \"1.7 Ensure auditing is configured for Docker files and directories\n/etc/docker (Scored)\"\n  desc  \"\n    Audit /etc/docker.\n    Apart from auditing your regular Linux file system and system calls, audit\nall Docker\n    related files and directories. Docker daemon runs with root privileges. Its\nbehavior\n    depends on some key files and directories. /etc/docker is one such\ndirectory. It holds\n    various certificates and keys used for TLS communication between Docker\ndaemon and\n    Docker client. It must be audited.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://access.redhat.com/documentation/enUS/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-system_auditing.html\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"1.7\"\n  tag \"cis_control\": \"14.6 Enforce Detailed Audit Logging For Sensitive\nInformation\\n\"\n  tag \"cis_level\": \"Level 1 - Linux Host OS\"\n  tag \"nist\": [\"AU-2\"]\n  tag \"audit\": \"Verify that there is an audit rule corresponding to /etc/docker\ndirectory.\\nFor example, execute below command:\\nauditctl -l | grep\n/etc/docker\\nThis should list a rule for /etc/docker directory.\\n\"\n  tag \"fix\": \"Add a rule for /etc/docker directory.\\nFor example,\\nAdd the line\nas below in /etc/audit/audit.rules file:\\n-w /etc/docker -k docker\\nThen,\nrestart the audit daemon. For example,\\nservice auditd restart\\n\"\n  tag \"Default Value\": \"By default, Docker related files and directories are\nnot audited.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-1.7.rb",
        "line": 1
      },
      "id": "M-1.7"
    },
    {
      "title": "1.8 Ensure auditing is configured for Docker files and directories\ndocker.service (Scored)",
      "desc": "Audit docker.service, if applicable.\n    Apart from auditing your regular Linux file system and system calls, audit\nall Docker\n    related files and directories. Docker daemon runs with root privileges. Its\nbehavior\n    depends on some key files and directories. docker.service is one such file.\nThe\n    docker.service file might be present if the daemon parameters have been\nchanged by an\n    administrator. It holds various parameters for Docker daemon. It must be\naudited, if\n    applicable.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://access.redhat.com/documentation/enUS/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-system_auditing.html\n",
        "severity": "medium",
        "cis_id": "1.8",
        "cis_control": "14.6 Enforce Detailed Audit Logging For Sensitive\nInformation\n",
        "cis_level": "Level 1 - Linux Host OS",
        "nist": [
          "AU-2"
        ],
        "audit": "Step 1: Find out the file location:\nsystemctl show -p\nFragmentPath docker.service\nStep 2: If the file does not exist, this\nrecommendation is not applicable. If the file exists,\nverify that there is an\naudit rule corresponding to the file:\nFor example, execute the below\ncommand:\nauditctl -l | grep docker.service\nThis should list a rule for\ndocker.service as per its location.\n",
        "fix": "If the file exists, add a rule for it.\nFor example,\nAdd the\nline as below in /etc/audit/audit.rules file:\n-w\n/usr/lib/systemd/system/docker.service -k docker\nThen, restart the audit\ndaemon. For example,\nservice auditd restart\n",
        "Default Value": "By default, Docker related files and directories are\nnot audited. The file docker.service\nmay not be available on the system.\n"
      },
      "code": "control \"M-1.8\" do\n  title \"1.8 Ensure auditing is configured for Docker files and directories\ndocker.service (Scored)\"\n  desc  \"\n    Audit docker.service, if applicable.\n    Apart from auditing your regular Linux file system and system calls, audit\nall Docker\n    related files and directories. Docker daemon runs with root privileges. Its\nbehavior\n    depends on some key files and directories. docker.service is one such file.\nThe\n    docker.service file might be present if the daemon parameters have been\nchanged by an\n    administrator. It holds various parameters for Docker daemon. It must be\naudited, if\n    applicable.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://access.redhat.com/documentation/enUS/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-system_auditing.html\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"1.8\"\n  tag \"cis_control\": \"14.6 Enforce Detailed Audit Logging For Sensitive\nInformation\\n\"\n  tag \"cis_level\": \"Level 1 - Linux Host OS\"\n  tag \"nist\": [\"AU-2\"]\n  tag \"audit\": \"Step 1: Find out the file location:\\nsystemctl show -p\nFragmentPath docker.service\\nStep 2: If the file does not exist, this\nrecommendation is not applicable. If the file exists,\\nverify that there is an\naudit rule corresponding to the file:\\nFor example, execute the below\ncommand:\\nauditctl -l | grep docker.service\\nThis should list a rule for\ndocker.service as per its location.\\n\"\n  tag \"fix\": \"If the file exists, add a rule for it.\\nFor example,\\nAdd the\nline as below in /etc/audit/audit.rules file:\\n-w\n/usr/lib/systemd/system/docker.service -k docker\\nThen, restart the audit\ndaemon. For example,\\nservice auditd restart\\n\"\n  tag \"Default Value\": \"By default, Docker related files and directories are\nnot audited. The file docker.service\\nmay not be available on the system.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-1.8.rb",
        "line": 1
      },
      "id": "M-1.8"
    },
    {
      "title": "1.9 Ensure auditing is configured for Docker files and directories\ndocker.socket (Scored)",
      "desc": "Audit docker.socket, if applicable.\n    Apart from auditing your regular Linux file system and system calls, audit\nall Docker\n    related files and directories. Docker daemon runs with root privileges. Its\nbehavior\n    depends on some key files and directories. docker.socket is one such file.\nIt holds various\n    parameters for Docker daemon socket. It must be audited, if applicable.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://access.redhat.com/documentation/enUS/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-system_auditing.html\n",
        "severity": "medium",
        "cis_id": "1.9",
        "cis_control": "14.6 Enforce Detailed Audit Logging For Sensitive\nInformation\n",
        "cis_level": "Level 1 - Linux Host OS",
        "nist": [
          "AU-2"
        ],
        "audit": "Step 1: Find out the file location:\nsystemctl show -p\nFragmentPath docker.socket\nStep 2: If the file does not exist, this\nrecommendation is not applicable. If the file exists,\nverify that there is an\naudit rule corresponding to the file:\nFor example, execute the below\ncommand:\nauditctl -l | grep docker.socket\nThis should list a rule for\ndocker.socket as per its location.\n",
        "fix": "If the file exists, add a rule for it.\nFor example,\nAdd the\nline as below in /etc/audit/audit.rules file:\n-w\n/usr/lib/systemd/system/docker.socket -k docker\nThen, restart the audit\ndaemon. For example,\nservice auditd restart\n",
        "Default Value": "By default, Docker related files and directories are\nnot audited. The file docker.socket may\nnot be available on the system.\n"
      },
      "code": "control \"M-1.9\" do\n  title \"1.9 Ensure auditing is configured for Docker files and directories\ndocker.socket (Scored)\"\n  desc  \"\n    Audit docker.socket, if applicable.\n    Apart from auditing your regular Linux file system and system calls, audit\nall Docker\n    related files and directories. Docker daemon runs with root privileges. Its\nbehavior\n    depends on some key files and directories. docker.socket is one such file.\nIt holds various\n    parameters for Docker daemon socket. It must be audited, if applicable.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://access.redhat.com/documentation/enUS/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-system_auditing.html\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"1.9\"\n  tag \"cis_control\": \"14.6 Enforce Detailed Audit Logging For Sensitive\nInformation\\n\"\n  tag \"cis_level\": \"Level 1 - Linux Host OS\"\n  tag \"nist\": [\"AU-2\"]\n  tag \"audit\": \"Step 1: Find out the file location:\\nsystemctl show -p\nFragmentPath docker.socket\\nStep 2: If the file does not exist, this\nrecommendation is not applicable. If the file exists,\\nverify that there is an\naudit rule corresponding to the file:\\nFor example, execute the below\ncommand:\\nauditctl -l | grep docker.socket\\nThis should list a rule for\ndocker.socket as per its location.\\n\"\n  tag \"fix\": \"If the file exists, add a rule for it.\\nFor example,\\nAdd the\nline as below in /etc/audit/audit.rules file:\\n-w\n/usr/lib/systemd/system/docker.socket -k docker\\nThen, restart the audit\ndaemon. For example,\\nservice auditd restart\\n\"\n  tag \"Default Value\": \"By default, Docker related files and directories are\nnot audited. The file docker.socket may\\nnot be available on the system.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-1.9.rb",
        "line": 1
      },
      "id": "M-1.9"
    },
    {
      "title": "2.1 Ensure network traffic is restricted between containers on\nthe\ndefault bridge (Scored)",
      "desc": "By default, all network traffic is allowed between containers on the same\nhost on the\n    default network bridge. If not desired, restrict all the inter-container\ncommunication. Link\n    specific containers together that require communication. Alternatively, you\ncan create\n    custom network and only join containers that need to communicate to that\ncustom\n    network.\n    By default, unrestricted network traffic is enabled between all containers\non the same host\n    on the default network bridge. Thus, each container has the potential of\nreading all packets\n    across the container network on the same host. This might lead to an\nunintended and\n    unwanted disclosure of information to other containers. Hence, restrict the\ninter-container\n    communication on the default network bridge.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://docs.docker.com/engine/userguide/networking/\n2.\nhttps://docs.docker.com/engine/userguide/networking/default_network/containe\nr-communication/#communication-between-containers\n\n2.2\nEnsure the logging level is set to 'info' (Scored)\nProfile Applicability:\n\nLevel 1 - Docker\nDescription:\nSet Docker daemon log level to\ninfo.\nRationale:\nSetting up an appropriate log level, configures the Docker\ndaemon to log events that you\nwould want to review later. A base log level of\ninfo and above would capture all logs\nexcept debug logs. Until and unless\nrequired, you should not run Docker daemon at debug\nlog level.\nAudit:\nps -ef\n| grep docker\nEnsure that either the --log-level parameter is not present or\nif present, then it is set to\ninfo.\nRemediation:\nRun the Docker daemon as\nbelow:\ndockerd --log-level=\"info\"\nImpact:\nNone.\nDefault Value:\nBy\ndefault, Docker daemon is set to log level of info.\nReferences:\n1.\nhttps://docs.docker.com/edge/engine/reference/commandline/dockerd/\n",
        "severity": "medium",
        "cis_id": "2.1",
        "cis_control": "6.2 Ensure Audit Log Settings Support Appropriate Log\nEntry Formatting\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "AU-3"
        ],
        "audit": "Run the below command and verify that the default network\nbridge has been configured to\nrestrict inter-container communication.\ndocker\nnetwork ls --quiet | xargs docker network inspect --format '{{ .Name\n}}: {{\n.Options }}'\nIt should return com.docker.network.bridge.enable_icc:false for\nthe default network\nbridge.\n",
        "fix": "Run the docker in daemon mode and pass --icc=false as an\nargument.\nFor Example,\ndockerd --icc=false\nAlternatively, you can follow the\nDocker documentation and create a custom network and\nonly join containers that\nneed to communicate to that custom network. The --icc\nparameter only applies\nto the default docker bridge, if custom networks are used then the\napproach of\nsegmenting networks should be adopted instead.\n",
        "Default Value": "By default, all inter-container communication is\nallowed on the default network bridge.\n"
      },
      "code": "control \"M-2.1\" do\n  title \"2.1 Ensure network traffic is restricted between containers on\nthe\\ndefault bridge (Scored)\"\n  desc  \"\n    By default, all network traffic is allowed between containers on the same\nhost on the\n    default network bridge. If not desired, restrict all the inter-container\ncommunication. Link\n    specific containers together that require communication. Alternatively, you\ncan create\n    custom network and only join containers that need to communicate to that\ncustom\n    network.\n    By default, unrestricted network traffic is enabled between all containers\non the same host\n    on the default network bridge. Thus, each container has the potential of\nreading all packets\n    across the container network on the same host. This might lead to an\nunintended and\n    unwanted disclosure of information to other containers. Hence, restrict the\ninter-container\n    communication on the default network bridge.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://docs.docker.com/engine/userguide/networking/\\n2.\nhttps://docs.docker.com/engine/userguide/networking/default_network/containe\\nr-communication/#communication-between-containers\\n\\n2.2\nEnsure the logging level is set to 'info' (Scored)\\nProfile Applicability:\\n\nLevel 1 - Docker\\nDescription:\\nSet Docker daemon log level to\ninfo.\\nRationale:\\nSetting up an appropriate log level, configures the Docker\ndaemon to log events that you\\nwould want to review later. A base log level of\ninfo and above would capture all logs\\nexcept debug logs. Until and unless\nrequired, you should not run Docker daemon at debug\\nlog level.\\nAudit:\\nps -ef\n| grep docker\\nEnsure that either the --log-level parameter is not present or\nif present, then it is set to\\ninfo.\\nRemediation:\\nRun the Docker daemon as\nbelow:\\ndockerd --log-level=\\\"info\\\"\\nImpact:\\nNone.\\nDefault Value:\\nBy\ndefault, Docker daemon is set to log level of info.\\nReferences:\\n1.\nhttps://docs.docker.com/edge/engine/reference/commandline/dockerd/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"2.1\"\n  tag \"cis_control\": \"6.2 Ensure Audit Log Settings Support Appropriate Log\nEntry Formatting\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"AU-3\"]\n  tag \"audit\": \"Run the below command and verify that the default network\nbridge has been configured to\\nrestrict inter-container communication.\\ndocker\nnetwork ls --quiet | xargs docker network inspect --format '{{ .Name\\n}}: {{\n.Options }}'\\nIt should return com.docker.network.bridge.enable_icc:false for\nthe default network\\nbridge.\\n\"\n  tag \"fix\": \"Run the docker in daemon mode and pass --icc=false as an\nargument.\\nFor Example,\\ndockerd --icc=false\\nAlternatively, you can follow the\nDocker documentation and create a custom network and\\nonly join containers that\nneed to communicate to that custom network. The --icc\\nparameter only applies\nto the default docker bridge, if custom networks are used then the\\napproach of\nsegmenting networks should be adopted instead.\\n\"\n  tag \"Default Value\": \"By default, all inter-container communication is\nallowed on the default network bridge.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-2.1.rb",
        "line": 1
      },
      "id": "M-2.1"
    },
    {
      "title": "2.10 Ensure base device size is not changed until needed (Scored)",
      "desc": "In certain circumstances, you might need containers bigger than 10G in\nsize. In these cases,\n    carefully choose the base device size.\n    The base device size can be increased at daemon restart. Increasing the\nbase device size\n    allows all future images and containers to be of the new base device size.\nA user can use\n    this option to expand the base device size however shrinking is not\npermitted. This value\n    affects the system-wide “base” empty filesystem that may already be\ninitialized and\n    inherited by pulled images.\n    Though the file system does not allot the increased size if it is empty, it\nwill use more space\n    for the empty case depending upon the device size. This may cause a denial\nof service by\n    ending up in file system being over-allocated or full.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://docs.docker.com/engine/reference/commandline/dockerd/#storagedriver-options\n",
        "severity": "medium",
        "cis_id": "2.10",
        "cis_control": "18 Application Software Security\n",
        "cis_level": "Level 2 - Docker",
        "nist": [
          "SI-1"
        ],
        "audit": "ps -ef | grep dockerd\nExecute the above command and it should\nnot show any --storage-opt dm.basesize\nparameters.\n",
        "fix": "Do not set --storage-opt dm.basesize until needed.\n",
        "Default Value": "The default base device size is 10G.\n"
      },
      "code": "control \"M-2.10\" do\n  title \"2.10 Ensure base device size is not changed until needed (Scored)\"\n  desc  \"\n    In certain circumstances, you might need containers bigger than 10G in\nsize. In these cases,\n    carefully choose the base device size.\n    The base device size can be increased at daemon restart. Increasing the\nbase device size\n    allows all future images and containers to be of the new base device size.\nA user can use\n    this option to expand the base device size however shrinking is not\npermitted. This value\n    affects the system-wide “base” empty filesystem that may already be\ninitialized and\n    inherited by pulled images.\n    Though the file system does not allot the increased size if it is empty, it\nwill use more space\n    for the empty case depending upon the device size. This may cause a denial\nof service by\n    ending up in file system being over-allocated or full.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://docs.docker.com/engine/reference/commandline/dockerd/#storagedriver-options\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"2.10\"\n  tag \"cis_control\": \"18 Application Software Security\\n\"\n  tag \"cis_level\": \"Level 2 - Docker\"\n  tag \"nist\": [\"SI-1\"]\n  tag \"audit\": \"ps -ef | grep dockerd\\nExecute the above command and it should\nnot show any --storage-opt dm.basesize\\nparameters.\\n\"\n  tag \"fix\": \"Do not set --storage-opt dm.basesize until needed.\\n\"\n  tag \"Default Value\": \"The default base device size is 10G.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-2.10.rb",
        "line": 1
      },
      "id": "M-2.10"
    },
    {
      "title": "2.11 Ensure that authorization for Docker client commands is\nenabled(Scored)",
      "desc": "Use native Docker authorization plugins or a third party authorization\nmechanism with\n    Docker daemon to manage access to Docker client commands.\n    Docker’s out-of-the-box authorization model is all or nothing. Any user\nwith permission to\n    access the Docker daemon can run any Docker client command. The same is\ntrue for callers\n    using Docker’s remote API to contact the daemon. If you require greater\naccess control, you\n    can create authorization plugins and add them to your Docker daemon\nconfiguration. Using\n    an authorization plugin, a Docker administrator can configure granular\naccess policies for\n    managing access to Docker daemon.\n    Third party integrations of Docker may implement their own authorization\nmodels to\n    require authorization with the Docker daemon outside of docker's native\nauthorization\n    plugin (i.e. Kubernetes, Cloud Foundry, Openshift).",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://docs.docker.com/engine/reference/commandline/dockerd/#accessauthorization\n2.\nhttps://docs.docker.com/engine/extend/plugins_authorization/\n3.\nhttps://github.com/twistlock/authz\nNotes:\nAs a scored control, focus should\nbe on a PASS/FAIL if the authentication occurs when a\ndocker client command is\nexecuted against docker daemon to enforce authentication. The\nnative docker\nauthentication plugin is just one method to enforce this control.\n",
        "severity": "medium",
        "cis_id": "2.11",
        "cis_control": "16 Account Monitoring and Control\n",
        "cis_level": "Level 2 - Docker",
        "nist": [
          "AC-2"
        ],
        "audit": "ps -ef | grep dockerd\nEnsure that the --authorization-plugin\nparameter is set as appropriate if using docker\nnative authorization.\ndocker\nsearch hello-world\nEnsure that docker daemon requires authorization to perform\nthe above command.\n",
        "fix": "Step 1: Install/Create an authorization plugin.\nStep 2:\nConfigure the authorization policy as desired.\nStep 3: Start the docker daemon\nas below:\ndockerd --authorization-plugin=<PLUGIN_ID>\n",
        "Default Value": "By default, authorization plugins are not set up.\n"
      },
      "code": "control \"M-2.11\" do\n  title \"2.11 Ensure that authorization for Docker client commands is\nenabled(Scored)\"\n  desc  \"\n    Use native Docker authorization plugins or a third party authorization\nmechanism with\n    Docker daemon to manage access to Docker client commands.\n    Docker’s out-of-the-box authorization model is all or nothing. Any user\nwith permission to\n    access the Docker daemon can run any Docker client command. The same is\ntrue for callers\n    using Docker’s remote API to contact the daemon. If you require greater\naccess control, you\n    can create authorization plugins and add them to your Docker daemon\nconfiguration. Using\n    an authorization plugin, a Docker administrator can configure granular\naccess policies for\n    managing access to Docker daemon.\n    Third party integrations of Docker may implement their own authorization\nmodels to\n    require authorization with the Docker daemon outside of docker's native\nauthorization\n    plugin (i.e. Kubernetes, Cloud Foundry, Openshift).\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://docs.docker.com/engine/reference/commandline/dockerd/#accessauthorization\\n2.\nhttps://docs.docker.com/engine/extend/plugins_authorization/\\n3.\nhttps://github.com/twistlock/authz\\nNotes:\\nAs a scored control, focus should\nbe on a PASS/FAIL if the authentication occurs when a\\ndocker client command is\nexecuted against docker daemon to enforce authentication. The\\nnative docker\nauthentication plugin is just one method to enforce this control.\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"2.11\"\n  tag \"cis_control\": \"16 Account Monitoring and Control\\n\"\n  tag \"cis_level\": \"Level 2 - Docker\"\n  tag \"nist\": [\"AC-2\"]\n  tag \"audit\": \"ps -ef | grep dockerd\\nEnsure that the --authorization-plugin\nparameter is set as appropriate if using docker\\nnative authorization.\\ndocker\nsearch hello-world\\nEnsure that docker daemon requires authorization to perform\nthe above command.\\n\"\n  tag \"fix\": \"Step 1: Install/Create an authorization plugin.\\nStep 2:\nConfigure the authorization policy as desired.\\nStep 3: Start the docker daemon\nas below:\\ndockerd --authorization-plugin=<PLUGIN_ID>\\n\"\n  tag \"Default Value\": \"By default, authorization plugins are not set up.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-2.11.rb",
        "line": 1
      },
      "id": "M-2.11"
    },
    {
      "title": "2.12 Ensure centralized and remote logging is configured (Scored)",
      "desc": "Docker now supports various log drivers. A preferable way to store logs is\nthe one that\n    supports centralized and remote logging.\n    Centralized and remote logging ensures that all important log records are\nsafe despite\n    catastrophic events. Docker now supports various such logging drivers. Use\nthe one that\n    suits your environment the best.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://docs.docker.com/engine/admin/logging/overview/\n",
        "severity": "medium",
        "cis_id": "2.12",
        "cis_control": "6.6 Deploy A SIEM OR Log Analysis Tools For Aggregation\nAnd Correlation/Analysis\n",
        "cis_level": "Level 2 - Docker",
        "nist": [
          "SI-4 (2)"
        ],
        "audit": "Run docker info and ensure that the Logging Driverproperty set\nas appropriate.\ndocker info --format '{{ .LoggingDriver }}'\nAlternatively,\nthe below command would give you the --log-driver setting, if\nconfigured.\nEnsure that it is set as appropriate.\nps -ef | grep dockerd\n",
        "fix": "Step 1: Setup the desired log driver by following its\ndocumentation.\nStep 2: Start the docker daemon with that logging driver.\nFor\nexample,\ndockerd --log-driver=syslog --log-opt\nsyslog-address=tcp://192.xxx.xxx.xxx\n",
        "Default Value": "By default, container logs are maintained as json\nfiles\n"
      },
      "code": "control \"M-2.12\" do\n  title \"2.12 Ensure centralized and remote logging is configured (Scored)\"\n  desc  \"\n    Docker now supports various log drivers. A preferable way to store logs is\nthe one that\n    supports centralized and remote logging.\n    Centralized and remote logging ensures that all important log records are\nsafe despite\n    catastrophic events. Docker now supports various such logging drivers. Use\nthe one that\n    suits your environment the best.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://docs.docker.com/engine/admin/logging/overview/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"2.12\"\n  tag \"cis_control\": \"6.6 Deploy A SIEM OR Log Analysis Tools For Aggregation\nAnd Correlation/Analysis\\n\"\n  tag \"cis_level\": \"Level 2 - Docker\"\n  tag \"nist\": [\"SI-4 (2)\"]\n  tag \"audit\": \"Run docker info and ensure that the Logging Driverproperty set\nas appropriate.\\ndocker info --format '{{ .LoggingDriver }}'\\nAlternatively,\nthe below command would give you the --log-driver setting, if\nconfigured.\\nEnsure that it is set as appropriate.\\nps -ef | grep dockerd\\n\"\n  tag \"fix\": \"Step 1: Setup the desired log driver by following its\ndocumentation.\\nStep 2: Start the docker daemon with that logging driver.\\nFor\nexample,\\ndockerd --log-driver=syslog --log-opt\nsyslog-address=tcp://192.xxx.xxx.xxx\\n\"\n  tag \"Default Value\": \"By default, container logs are maintained as json\nfiles\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-2.12.rb",
        "line": 1
      },
      "id": "M-2.12"
    },
    {
      "title": "2.13 Ensure operations on legacy registry (v1) are Disabled (Scored)",
      "desc": "The latest Docker registry is v2. All operations on the legacy registry\nversion (v1) should be\n    restricted.\n    Docker registry v2 brings in many performance and security improvements\nover v1. It\n    supports container image provenance and other security features such as\nimage signing\n    and verification. Hence, operations on Docker legacy registry should be\nrestricted.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://docs.docker.com/edge/engine/reference/commandline/dockerd/#legacyregistries\n2.\nhttps://docs.docker.com/registry/spec/api/\n3.\nhttps://the.binbashtheory.com/creating-private-docker-registry-2-0-with-tokenauthentication-service/\n4.\nhttps://blog.docker.com/2015/07/new-tool-v1-registry-docker-trusted-registryv2-open-source/\n5.\nhttp://www.slideshare.net/Docker/docker-registry-v2\n",
        "severity": "medium",
        "cis_id": "2.13",
        "cis_control": "18 Application Software Security\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "SI-1"
        ],
        "audit": "ps -ef | grep dockerd\nThe above command should list\n--disable-legacy-registry as an option passed to the\ndocker daemon.\n",
        "fix": "Start the docker daemon as below:\ndockerd\n--disable-legacy-registry\n",
        "Default Value": "By default, legacy registry operations are allowed.\n"
      },
      "code": "control \"M-2.13\" do\n  title \"2.13 Ensure operations on legacy registry (v1) are Disabled (Scored)\"\n  desc  \"\n    The latest Docker registry is v2. All operations on the legacy registry\nversion (v1) should be\n    restricted.\n    Docker registry v2 brings in many performance and security improvements\nover v1. It\n    supports container image provenance and other security features such as\nimage signing\n    and verification. Hence, operations on Docker legacy registry should be\nrestricted.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://docs.docker.com/edge/engine/reference/commandline/dockerd/#legacyregistries\\n2.\nhttps://docs.docker.com/registry/spec/api/\\n3.\nhttps://the.binbashtheory.com/creating-private-docker-registry-2-0-with-tokenauthentication-service/\\n4.\nhttps://blog.docker.com/2015/07/new-tool-v1-registry-docker-trusted-registryv2-open-source/\\n5.\nhttp://www.slideshare.net/Docker/docker-registry-v2\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"2.13\"\n  tag \"cis_control\": \"18 Application Software Security\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"SI-1\"]\n  tag \"audit\": \"ps -ef | grep dockerd\\nThe above command should list\n--disable-legacy-registry as an option passed to the\\ndocker daemon.\\n\"\n  tag \"fix\": \"Start the docker daemon as below:\\ndockerd\n--disable-legacy-registry\\n\"\n  tag \"Default Value\": \"By default, legacy registry operations are allowed.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-2.13.rb",
        "line": 1
      },
      "id": "M-2.13"
    },
    {
      "title": "2.14 Ensure live restore is Enabled (Scored)",
      "desc": "The --live-restore enables full support of daemon-less containers in\ndocker. It ensures\n    that docker does not stop containers on shutdown or restore and properly\nreconnects to\n    the container when restarted.\n    One of the important security triads is availability. Setting\n--live-restore flag in the\n    docker daemon ensures that container execution is not interrupted when the\ndocker\n    daemon is not available. This also means that it is now easier to update\nand patch the\n    docker daemon without execution downtime.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://docs.docker.com/engine/admin/live-restore/\n",
        "severity": "medium",
        "cis_id": "2.14",
        "cis_control": "18 Application Software Security\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "SI-1"
        ],
        "audit": "Run docker info and ensure that the Live Restore Enabled\nproperty is set to true.\ndocker info --format '{{ .LiveRestoreEnabled\n}}'\nAlternatively run the below command and ensure that --live-restore is\nused.\nps -ef | grep dockerd\n",
        "fix": "Run the docker in daemon mode and pass --live-restore as an\nargument.\nFor Example,\ndockerd --live-restore\n",
        "Default Value": "By default, --live-restore is not enabled.\n"
      },
      "code": "control \"M-2.14\" do\n  title \"2.14 Ensure live restore is Enabled (Scored)\"\n  desc  \"\n    The --live-restore enables full support of daemon-less containers in\ndocker. It ensures\n    that docker does not stop containers on shutdown or restore and properly\nreconnects to\n    the container when restarted.\n    One of the important security triads is availability. Setting\n--live-restore flag in the\n    docker daemon ensures that container execution is not interrupted when the\ndocker\n    daemon is not available. This also means that it is now easier to update\nand patch the\n    docker daemon without execution downtime.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://docs.docker.com/engine/admin/live-restore/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"2.14\"\n  tag \"cis_control\": \"18 Application Software Security\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"SI-1\"]\n  tag \"audit\": \"Run docker info and ensure that the Live Restore Enabled\nproperty is set to true.\\ndocker info --format '{{ .LiveRestoreEnabled\n}}'\\nAlternatively run the below command and ensure that --live-restore is\nused.\\nps -ef | grep dockerd\\n\"\n  tag \"fix\": \"Run the docker in daemon mode and pass --live-restore as an\nargument.\\nFor Example,\\ndockerd --live-restore\\n\"\n  tag \"Default Value\": \"By default, --live-restore is not enabled.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-2.14.rb",
        "line": 1
      },
      "id": "M-2.14"
    },
    {
      "title": "2.15 Ensure Userland Proxy is Disabled (Scored)",
      "desc": "The docker daemon starts a userland proxy service for port forwarding\nwhenever a port is\n    exposed. Where hairpin NAT is available, this service is generally\nsuperfluous to\n    requirements and can be disabled.\n    Docker engine provides two mechanisms for forwarding ports from the host to\ncontainers,\n    hairpin NAT, and a userland proxy. In most circumstances, the hairpin NAT\nmode is\n    preferred as it improves performance and makes use of native Linux iptables\nfunctionality\n    instead of an additional component.\n    Where hairpin NAT is available, the userland proxy should be disabled on\nstartup to reduce\n    the attack surface of the installation.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\n2.\n3.\n4.\nhttp://windsock.io/the-docker-proxy/\nhttps://github.com/docker/docker/issues/14856\nhttps://github.com/docker/docker/issues/22741\nhttps://docs.docker.com/engine/userguide/networking/default_network/binding/\n",
        "severity": "medium",
        "cis_id": "2.15",
        "cis_control": "9.1 Limit Open Ports, Protocols, and Services\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "CM-7 (1)"
        ],
        "audit": "ps -ef | grep dockerd\nEnsure that the --userland-proxy\nparameter is set to false.\n",
        "fix": "Run the Docker daemon as below:\ndockerd --userland-proxy=false\n",
        "Default Value": "By default, the userland proxy is enabled.\n"
      },
      "code": "control \"M-2.15\" do\n  title \"2.15 Ensure Userland Proxy is Disabled (Scored)\"\n  desc  \"\n    The docker daemon starts a userland proxy service for port forwarding\nwhenever a port is\n    exposed. Where hairpin NAT is available, this service is generally\nsuperfluous to\n    requirements and can be disabled.\n    Docker engine provides two mechanisms for forwarding ports from the host to\ncontainers,\n    hairpin NAT, and a userland proxy. In most circumstances, the hairpin NAT\nmode is\n    preferred as it improves performance and makes use of native Linux iptables\nfunctionality\n    instead of an additional component.\n    Where hairpin NAT is available, the userland proxy should be disabled on\nstartup to reduce\n    the attack surface of the installation.\n\n  \"\n  impact 0.5\n  tag \"ref\":\n\"1.\\n2.\\n3.\\n4.\\nhttp://windsock.io/the-docker-proxy/\\nhttps://github.com/docker/docker/issues/14856\\nhttps://github.com/docker/docker/issues/22741\\nhttps://docs.docker.com/engine/userguide/networking/default_network/binding/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"2.15\"\n  tag \"cis_control\": \"9.1 Limit Open Ports, Protocols, and Services\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"CM-7 (1)\"]\n  tag \"audit\": \"ps -ef | grep dockerd\\nEnsure that the --userland-proxy\nparameter is set to false.\\n\"\n  tag \"fix\": \"Run the Docker daemon as below:\\ndockerd --userland-proxy=false\\n\"\n  tag \"Default Value\": \"By default, the userland proxy is enabled.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-2.15.rb",
        "line": 1
      },
      "id": "M-2.15"
    },
    {
      "title": "2.16 Ensure daemon-wide custom seccomp profile is applied, if\nneeded(Not Scored)",
      "desc": "You can choose to apply your custom seccomp profile at the daemon-wide\nlevel if needed\n    and override Docker's default seccomp profile.\n    A large number of system calls are exposed to every userland process with\nmany of them\n    going unused for the entire lifetime of the process. Most of the\napplications do not need all\n    the system calls and thus benefit by having a reduced set of available\nsystem calls. The\n    reduced set of system calls reduces the total kernel surface exposed to the\napplication and\n    thus improvises application security.\n    You could apply your own custom seccomp profile instead of Docker's default\nseccomp\n    profile. Alternatively, if Docker's default profile is good for your\nenvironment, you can\n    choose to ignore this recommendation.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://docs.docker.com/engine/security/seccomp/\n2.\nhttps://github.com/docker/docker/pull/26276\n",
        "severity": "medium",
        "cis_id": "2.16",
        "cis_control": "18 Application Software Security\n",
        "cis_level": "Level 2 - Docker",
        "nist": [
          "SI-1"
        ],
        "audit": "Run the below command and review the seccomp profile listed in\nthe Security Options\nsection. If it is default, that means, Docker's default\nseccomp profile is applied.\ndocker info --format '{{ .SecurityOptions }}'\n",
        "fix": "By default, Docker's default seccomp profile is applied. If this\nis good for your environment,\nno action is necessary. Alternatively, if you\nchoose to apply your own seccomp profile, use\nthe --seccomp-profile flag at\ndaemon start or put it in the daemon runtime parameters\nfile.\ndockerd\n--seccomp-profile </path/to/seccomp/profile>\n",
        "Default Value": "By default, Docker applies a seccomp profile.\n"
      },
      "code": "control \"M-2.16\" do\n  title \"2.16 Ensure daemon-wide custom seccomp profile is applied, if\nneeded(Not Scored)\"\n  desc  \"\n    You can choose to apply your custom seccomp profile at the daemon-wide\nlevel if needed\n    and override Docker's default seccomp profile.\n    A large number of system calls are exposed to every userland process with\nmany of them\n    going unused for the entire lifetime of the process. Most of the\napplications do not need all\n    the system calls and thus benefit by having a reduced set of available\nsystem calls. The\n    reduced set of system calls reduces the total kernel surface exposed to the\napplication and\n    thus improvises application security.\n    You could apply your own custom seccomp profile instead of Docker's default\nseccomp\n    profile. Alternatively, if Docker's default profile is good for your\nenvironment, you can\n    choose to ignore this recommendation.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://docs.docker.com/engine/security/seccomp/\\n2.\nhttps://github.com/docker/docker/pull/26276\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"2.16\"\n  tag \"cis_control\": \"18 Application Software Security\\n\"\n  tag \"cis_level\": \"Level 2 - Docker\"\n  tag \"nist\": [\"SI-1\"]\n  tag \"audit\": \"Run the below command and review the seccomp profile listed in\nthe Security Options\\nsection. If it is default, that means, Docker's default\nseccomp profile is applied.\\ndocker info --format '{{ .SecurityOptions }}'\\n\"\n  tag \"fix\": \"By default, Docker's default seccomp profile is applied. If this\nis good for your environment,\\nno action is necessary. Alternatively, if you\nchoose to apply your own seccomp profile, use\\nthe --seccomp-profile flag at\ndaemon start or put it in the daemon runtime parameters\\nfile.\\ndockerd\n--seccomp-profile </path/to/seccomp/profile>\\n\"\n  tag \"Default Value\": \"By default, Docker applies a seccomp profile.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-2.16.rb",
        "line": 1
      },
      "id": "M-2.16"
    },
    {
      "title": "2.17 Ensure experimental features are avoided in production (Scored)",
      "desc": "Avoid experimental features in production.\n    Experimental is now a runtime docker daemon flag instead of a separate\nbuild. Passing -experimental as a runtime flag to the docker daemon, activates\nexperimental features.\n    Experimental is now considered a stable release, but with a couple of\nfeatures which might\n    not have tested and guaranteed API stability.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://docs.docker.com/edge/engine/reference/commandline/dockerd/#options\n",
        "severity": "medium",
        "cis_id": "2.17",
        "cis_control": "18 Application Software Security\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "SI-1"
        ],
        "audit": "Run the below command and ensure that the Experimental property\nis set to false in the\nServer section.\ndocker version --format '{{\n.Server.Experimental }}'\n",
        "fix": "Do not pass --experimental as a runtime parameter to the docker\ndaemon.\n",
        "Default Value": "By default, experimental features are not activated on\nthe docker daemon.\n"
      },
      "code": "control \"M-2.17\" do\n  title \"2.17 Ensure experimental features are avoided in production (Scored)\"\n  desc  \"\n    Avoid experimental features in production.\n    Experimental is now a runtime docker daemon flag instead of a separate\nbuild. Passing -experimental as a runtime flag to the docker daemon, activates\nexperimental features.\n    Experimental is now considered a stable release, but with a couple of\nfeatures which might\n    not have tested and guaranteed API stability.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://docs.docker.com/edge/engine/reference/commandline/dockerd/#options\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"2.17\"\n  tag \"cis_control\": \"18 Application Software Security\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"SI-1\"]\n  tag \"audit\": \"Run the below command and ensure that the Experimental property\nis set to false in the\\nServer section.\\ndocker version --format '{{\n.Server.Experimental }}'\\n\"\n  tag \"fix\": \"Do not pass --experimental as a runtime parameter to the docker\ndaemon.\\n\"\n  tag \"Default Value\": \"By default, experimental features are not activated on\nthe docker daemon.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-2.17.rb",
        "line": 1
      },
      "id": "M-2.17"
    },
    {
      "title": "2.18 Ensure containers are restricted from acquiring new\nprivileges(Scored)",
      "desc": "Restrict containers from acquiring additional privileges via suid or sgid\nbits, by default.\n    A process can set the no_new_priv bit in the kernel. It persists across\nfork, clone and\n    execve. The no_new_priv bit ensures that the process or its children\nprocesses do not gain\n    any additional privileges via suid or sgid bits. This way a lot of\ndangerous operations\n    become a lot less dangerous because there is no possibility of subverting\nprivileged\n    binaries.\n    Setting this at the daemon level ensures that by default all new containers\nare restricted\n    from acquiring new privileges.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://github.com/moby/moby/pull/29984\n2.\nhttps://github.com/moby/moby/pull/20727\n",
        "severity": "medium",
        "cis_id": "2.18",
        "cis_control": "5 Controlled Use of Administration Privileges\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "AC-6"
        ],
        "audit": "ps -ef | grep dockerd\nEnsure that the --no-new-privileges\nparameter is present and is not set to false.\n",
        "fix": "Run the Docker daemon as below:\ndockerd --no-new-privileges\n",
        "Default Value": "By default, containers are not restricted from\nacquiring new privileges.\n"
      },
      "code": "control \"M-2.18\" do\n  title \"2.18 Ensure containers are restricted from acquiring new\nprivileges(Scored)\"\n  desc  \"\n    Restrict containers from acquiring additional privileges via suid or sgid\nbits, by default.\n    A process can set the no_new_priv bit in the kernel. It persists across\nfork, clone and\n    execve. The no_new_priv bit ensures that the process or its children\nprocesses do not gain\n    any additional privileges via suid or sgid bits. This way a lot of\ndangerous operations\n    become a lot less dangerous because there is no possibility of subverting\nprivileged\n    binaries.\n    Setting this at the daemon level ensures that by default all new containers\nare restricted\n    from acquiring new privileges.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://github.com/moby/moby/pull/29984\\n2.\nhttps://github.com/moby/moby/pull/20727\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"2.18\"\n  tag \"cis_control\": \"5 Controlled Use of Administration Privileges\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"AC-6\"]\n  tag \"audit\": \"ps -ef | grep dockerd\\nEnsure that the --no-new-privileges\nparameter is present and is not set to false.\\n\"\n  tag \"fix\": \"Run the Docker daemon as below:\\ndockerd --no-new-privileges\\n\"\n  tag \"Default Value\": \"By default, containers are not restricted from\nacquiring new privileges.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-2.18.rb",
        "line": 1
      },
      "id": "M-2.18"
    },
    {
      "title": "2.3 Ensure Docker is allowed to make changes to iptables (Scored)",
      "desc": "Iptables are used to set up, maintain, and inspect the tables of IP packet\nfilter rules in the\n    Linux kernel. Allow the Docker daemon to make changes to the iptables.\n    Docker will never make changes to your system iptables rules if you choose\nto do so.\n    Docker server would automatically make the needed changes to iptables based\non how you\n    choose your networking options for the containers if it is allowed to do\nso. It is\n    recommended to let Docker server make changes to iptablesautomatically to\navoid\n    networking misconfiguration that might hamper the communication between\ncontainers\n    and to the outside world. Additionally, it would save you hassles of\nupdating\n    iptablesevery time you choose to run the containers or modify networking\noptions.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://docs.docker.com/engine/userguide/networking/default_network/containe\nr-communication/\n2.\nhttps://fralef.me/docker-and-iptables.html\n",
        "severity": "medium",
        "cis_id": "2.3",
        "cis_control": "5 Controlled Use of Administration Privileges\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "AC-6"
        ],
        "audit": "ps -ef | grep dockerd\nEnsure that the --iptables parameter is\neither not present or not set to false.\n",
        "fix": "Do not run the Docker daemon with --iptables=false parameter. For\nexample, do not\nstart the Docker daemon as below:\ndockerd --iptables=false\n",
        "Default Value": "By default, iptables is set to true.\n"
      },
      "code": "control \"M-2.3\" do\n  title \"2.3 Ensure Docker is allowed to make changes to iptables (Scored)\"\n  desc  \"\n    Iptables are used to set up, maintain, and inspect the tables of IP packet\nfilter rules in the\n    Linux kernel. Allow the Docker daemon to make changes to the iptables.\n    Docker will never make changes to your system iptables rules if you choose\nto do so.\n    Docker server would automatically make the needed changes to iptables based\non how you\n    choose your networking options for the containers if it is allowed to do\nso. It is\n    recommended to let Docker server make changes to iptablesautomatically to\navoid\n    networking misconfiguration that might hamper the communication between\ncontainers\n    and to the outside world. Additionally, it would save you hassles of\nupdating\n    iptablesevery time you choose to run the containers or modify networking\noptions.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://docs.docker.com/engine/userguide/networking/default_network/containe\\nr-communication/\\n2.\nhttps://fralef.me/docker-and-iptables.html\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"2.3\"\n  tag \"cis_control\": \"5 Controlled Use of Administration Privileges\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"AC-6\"]\n  tag \"audit\": \"ps -ef | grep dockerd\\nEnsure that the --iptables parameter is\neither not present or not set to false.\\n\"\n  tag \"fix\": \"Do not run the Docker daemon with --iptables=false parameter. For\nexample, do not\\nstart the Docker daemon as below:\\ndockerd --iptables=false\\n\"\n  tag \"Default Value\": \"By default, iptables is set to true.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-2.3.rb",
        "line": 1
      },
      "id": "M-2.3"
    },
    {
      "title": "2.4 Ensure insecure registries are not used (Scored)",
      "desc": "Docker considers a private registry either secure or insecure. By default,\nregistries are\n    considered secure.\n    A secure registry uses TLS. A copy of registry's CA certificate is placed\non the Docker host at\n    /etc/docker/certs.d/<registry-name>/ directory. An insecure registry is the\none not\n    having either valid registry certificate or is not using TLS. You should\nnot be using any\n    insecure registries in the production environment. Insecure registries can\nbe tampered\n    with leading to possible compromise to your production system.\n    Additionally, If a registry is marked as insecure then docker pull, docker\npush, and\n    docker search commands will not result in an error message and the user\nmight be\n    indefinitely working with insecure registries without ever being notified\nof potential\n    danger.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://docs.docker.com/registry/insecure/\n",
        "severity": "medium",
        "cis_id": "2.4",
        "cis_control": "14.2 Encrypt All Sensitive Information Over Less-trusted\nNetworks\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "SC-8"
        ],
        "audit": "Run docker info or execute the below command to find out if any\ninsecure registries are\nused:\nps -ef | grep dockerd\nEnsure that the\n--insecure-registry parameter is not present.\n",
        "fix": "Do not use any insecure registries.\nFor example, do not start\nthe Docker daemon as below:\ndockerd --insecure-registry 10.1.0.0/16\n",
        "Default Value": "By default, Docker assumes all, but local, registries\nare secure.\n"
      },
      "code": "control \"M-2.4\" do\n  title \"2.4 Ensure insecure registries are not used (Scored)\"\n  desc  \"\n    Docker considers a private registry either secure or insecure. By default,\nregistries are\n    considered secure.\n    A secure registry uses TLS. A copy of registry's CA certificate is placed\non the Docker host at\n    /etc/docker/certs.d/<registry-name>/ directory. An insecure registry is the\none not\n    having either valid registry certificate or is not using TLS. You should\nnot be using any\n    insecure registries in the production environment. Insecure registries can\nbe tampered\n    with leading to possible compromise to your production system.\n    Additionally, If a registry is marked as insecure then docker pull, docker\npush, and\n    docker search commands will not result in an error message and the user\nmight be\n    indefinitely working with insecure registries without ever being notified\nof potential\n    danger.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://docs.docker.com/registry/insecure/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"2.4\"\n  tag \"cis_control\": \"14.2 Encrypt All Sensitive Information Over Less-trusted\nNetworks\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"SC-8\"]\n  tag \"audit\": \"Run docker info or execute the below command to find out if any\ninsecure registries are\\nused:\\nps -ef | grep dockerd\\nEnsure that the\n--insecure-registry parameter is not present.\\n\"\n  tag \"fix\": \"Do not use any insecure registries.\\nFor example, do not start\nthe Docker daemon as below:\\ndockerd --insecure-registry 10.1.0.0/16\\n\"\n  tag \"Default Value\": \"By default, Docker assumes all, but local, registries\nare secure.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-2.4.rb",
        "line": 1
      },
      "id": "M-2.4"
    },
    {
      "title": "2.5 Ensure aufs storage driver is not used (Scored)",
      "desc": "Do not use aufs as storage driver for your Docker instance.\n    The aufs storage driver is the oldest storage driver. It is based on a\nLinux kernel patch-set\n    that is unlikely to be merged into the main Linux kernel. aufs driver is\nalso known to cause\n    some serious kernel crashes. aufs just has legacy support from Docker. Most\nimportantly,\n    aufs is not a supported driver in many Linux distributions using latest\nLinux kernels.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://docs.docker.com/engine/userguide/storagedriver/selectadriver/#support\ned-backing-filesystems\n2.\nhttp://muehe.org/posts/switching-docker-from-aufs-to-devicemapper/\n3.\nhttp://jpetazzo.github.io/assets/2015-03-05-deep-dive-into-docker-storagedrivers.html#1\n4.\nhttps://docs.docker.com/engine/userguide/storagedriver/\n",
        "severity": "medium",
        "cis_id": "2.5",
        "cis_control": "18 Application Software Security\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "SI-1"
        ],
        "audit": "Execute the below command and verify that aufs is not used as\nstorage driver:\ndocker info | grep -e \"^Storage Driver:\\s*aufs\\s*$\"\nThe\nabove command should not return anything.\n",
        "fix": "Do not explicitly use aufs as storage driver.\nFor example, do\nnot start Docker daemon as below:\ndockerd --storage-driver aufs\n",
        "Default Value": "By default, Docker uses devicemapper as the storage\ndriver on most of the platforms.\nDefault storage driver can vary based on your\nOS vendor. You should use the storage driver\nthat is best supported by your\npreferred vendor.\n"
      },
      "code": "control \"M-2.5\" do\n  title \"2.5 Ensure aufs storage driver is not used (Scored)\"\n  desc  \"\n    Do not use aufs as storage driver for your Docker instance.\n    The aufs storage driver is the oldest storage driver. It is based on a\nLinux kernel patch-set\n    that is unlikely to be merged into the main Linux kernel. aufs driver is\nalso known to cause\n    some serious kernel crashes. aufs just has legacy support from Docker. Most\nimportantly,\n    aufs is not a supported driver in many Linux distributions using latest\nLinux kernels.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://docs.docker.com/engine/userguide/storagedriver/selectadriver/#support\\ned-backing-filesystems\\n2.\nhttp://muehe.org/posts/switching-docker-from-aufs-to-devicemapper/\\n3.\nhttp://jpetazzo.github.io/assets/2015-03-05-deep-dive-into-docker-storagedrivers.html#1\\n4.\nhttps://docs.docker.com/engine/userguide/storagedriver/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"2.5\"\n  tag \"cis_control\": \"18 Application Software Security\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"SI-1\"]\n  tag \"audit\": \"Execute the below command and verify that aufs is not used as\nstorage driver:\\ndocker info | grep -e \\\"^Storage Driver:\\\\s*aufs\\\\s*$\\\"\\nThe\nabove command should not return anything.\\n\"\n  tag \"fix\": \"Do not explicitly use aufs as storage driver.\\nFor example, do\nnot start Docker daemon as below:\\ndockerd --storage-driver aufs\\n\"\n  tag \"Default Value\": \"By default, Docker uses devicemapper as the storage\ndriver on most of the platforms.\\nDefault storage driver can vary based on your\nOS vendor. You should use the storage driver\\nthat is best supported by your\npreferred vendor.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-2.5.rb",
        "line": 1
      },
      "id": "M-2.5"
    },
    {
      "title": "2.6 Ensure TLS authentication for Docker daemon is configured (Scored)",
      "desc": "It is possible to make the Docker daemon to listen on a specific IP and\nport and any other\n    Unix socket other than default Unix socket. Configure TLS authentication to\nrestrict access\n    to Docker daemon via IP and port.\n    By default, Docker daemon binds to a non-networked Unix socket and runs\nwith root\n    privileges. If you change the default docker daemon binding to a TCP port\nor any other Unix\n    socket, anyone with access to that port or socket can have full access to\nDocker daemon\n    and in turn to the host system. Hence, you should not bind the Docker\ndaemon to another\n    IP/port or a Unix socket.\n    If you must expose the Docker daemon via a network socket, configure TLS\nauthentication\n    for the daemon and Docker Swarm APIs (if using). This would restrict the\nconnections to\n    your Docker daemon over the network to a limited number of clients who could\n    successfully authenticate over TLS.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://docs.docker.com/engine/security/https/\n",
        "severity": "medium",
        "cis_id": "2.6",
        "cis_control": "9.1 Limit Open Ports, Protocols, and Services\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "CM-7 (1)"
        ],
        "audit": "ps -ef | grep dockerd\nEnsure that the below parameters are\npresent:\n--tlsverify\n--tlscacert\n--tlscert\n--tlskey\n",
        "fix": "Follow the steps mentioned in the Docker documentation or other\nreferences.\n",
        "Default Value": "By default, TLS authentication is not configured.\n"
      },
      "code": "control \"M-2.6\" do\n  title \"2.6 Ensure TLS authentication for Docker daemon is configured (Scored)\"\n  desc  \"\n    It is possible to make the Docker daemon to listen on a specific IP and\nport and any other\n    Unix socket other than default Unix socket. Configure TLS authentication to\nrestrict access\n    to Docker daemon via IP and port.\n    By default, Docker daemon binds to a non-networked Unix socket and runs\nwith root\n    privileges. If you change the default docker daemon binding to a TCP port\nor any other Unix\n    socket, anyone with access to that port or socket can have full access to\nDocker daemon\n    and in turn to the host system. Hence, you should not bind the Docker\ndaemon to another\n    IP/port or a Unix socket.\n    If you must expose the Docker daemon via a network socket, configure TLS\nauthentication\n    for the daemon and Docker Swarm APIs (if using). This would restrict the\nconnections to\n    your Docker daemon over the network to a limited number of clients who could\n    successfully authenticate over TLS.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://docs.docker.com/engine/security/https/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"2.6\"\n  tag \"cis_control\": \"9.1 Limit Open Ports, Protocols, and Services\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"CM-7 (1)\"]\n  tag \"audit\": \"ps -ef | grep dockerd\\nEnsure that the below parameters are\npresent:\\n--tlsverify\\n--tlscacert\\n--tlscert\\n--tlskey\\n\"\n  tag \"fix\": \"Follow the steps mentioned in the Docker documentation or other\nreferences.\\n\"\n  tag \"Default Value\": \"By default, TLS authentication is not configured.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-2.6.rb",
        "line": 1
      },
      "id": "M-2.6"
    },
    {
      "title": "2.7 Ensure the default ulimit is configured appropriately (Not Scored)",
      "desc": "Set the default ulimit options as appropriate in your environment.\n    ulimit provides control over the resources available to the shell and to\nprocesses started\n    by it. Setting system resource limits judiciously saves you from many\ndisasters such as a\n    fork bomb. Sometimes, even friendly users and legitimate processes can\noveruse system\n    resources and in-turn can make the system unusable.\n    Setting default ulimit for the Docker daemon would enforce the ulimit for\nall container\n    instances. You would not need to setup ulimit for each container instance.\nHowever, the\n    default ulimit can be overridden during container runtime, if needed.\nHence, to control the\n    system resources, define a default ulimit as needed in your environment.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://docs.docker.com/edge/engine/reference/commandline/dockerd/#defaultulimits\n",
        "severity": "medium",
        "cis_id": "2.7",
        "cis_control": "18 Application Software Security\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "SI-1"
        ],
        "audit": "ps -ef | grep dockerd\nEnsure that the --default-ulimit\nparameter is set as appropriate.\n",
        "fix": "Run the docker in daemon mode and pass --default-ulimit as\nargument with respective\nulimits as appropriate in your environment.\nFor\nExample,\ndockerd --default-ulimit nproc=1024:2048 --default-ulimit\nnofile=100:200\n",
        "Default Value": "By default, no ulimit is set.\n"
      },
      "code": "control \"M-2.7\" do\n  title \"2.7 Ensure the default ulimit is configured appropriately (Not Scored)\"\n  desc  \"\n    Set the default ulimit options as appropriate in your environment.\n    ulimit provides control over the resources available to the shell and to\nprocesses started\n    by it. Setting system resource limits judiciously saves you from many\ndisasters such as a\n    fork bomb. Sometimes, even friendly users and legitimate processes can\noveruse system\n    resources and in-turn can make the system unusable.\n    Setting default ulimit for the Docker daemon would enforce the ulimit for\nall container\n    instances. You would not need to setup ulimit for each container instance.\nHowever, the\n    default ulimit can be overridden during container runtime, if needed.\nHence, to control the\n    system resources, define a default ulimit as needed in your environment.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://docs.docker.com/edge/engine/reference/commandline/dockerd/#defaultulimits\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"2.7\"\n  tag \"cis_control\": \"18 Application Software Security\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"SI-1\"]\n  tag \"audit\": \"ps -ef | grep dockerd\\nEnsure that the --default-ulimit\nparameter is set as appropriate.\\n\"\n  tag \"fix\": \"Run the docker in daemon mode and pass --default-ulimit as\nargument with respective\\nulimits as appropriate in your environment.\\nFor\nExample,\\ndockerd --default-ulimit nproc=1024:2048 --default-ulimit\nnofile=100:200\\n\"\n  tag \"Default Value\": \"By default, no ulimit is set.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-2.7.rb",
        "line": 1
      },
      "id": "M-2.7"
    },
    {
      "title": "2.8 Enable user namespace support (Scored)",
      "desc": "Enable user namespace support in Docker daemon to utilize container user to\nhost user remapping. This recommendation is beneficial where containers you are\nusing do not have an\n    explicit container user defined in the container image. If container images\nthat you are\n    using have a pre-defined non-root user, this recommendation may be skipped\nsince this\n    feature is still in its infancy and might give you unpredictable issues and\ncomplexities.\n    The Linux kernel user namespace support in Docker daemon provides\nadditional security\n    for the Docker host system. It allows a container to have a unique range of\nuser and group\n    IDs which are outside the traditional user and group range utilized by the\nhost system.\n    For example, the root user will have expected administrative privilege\ninside the container\n    but can effectively be mapped to an unprivileged UID on the host system.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttp://man7.org/linux/man-pages/man7/user_namespaces.7.html\n2.\nhttps://docs.docker.com/engine/reference/commandline/dockerd/#daemon-usernamespace-options\n3.\nhttp://events.linuxfoundation.org/sites/events/files/slides/User%20Namespaces\n%20-%20ContainerCon%202015%20-%2016-9-final_0.pdf\n",
        "severity": "medium",
        "cis_id": "2.8",
        "cis_control": "18 Application Software Security\n",
        "cis_level": "Level 2 - Docker",
        "nist": [
          "SI-1"
        ],
        "audit": "ps -p $(docker inspect --format='{{ .State.Pid }}' <CONTAINER\nID>) -o\npid,user\nThe above command would find the PID of the container and\nthen would list the host user\nassociated with the container process. If the\ncontainer process is running as root, then this\nrecommendation is\nnon-compliant.\nAlternatively, you can run docker info to ensure that the\nuserns is listed under Security\nOptions:\ndocker info --format '{{\n.SecurityOptions }}'\n",
        "fix": "Please consult Docker documentation for various ways in which\nthis can be configured\ndepending upon your requirements. Your steps might also\nvary based on platform - For\nexample, on Red Hat, sub-UIDs and sub-GIDs\nmapping creation does not work\nautomatically. You might have to create your\nown mapping.\nHowever, the high-level steps are as below:\nStep 1: Ensure that\nthe files /etc/subuid and /etc/subgid exist.\ntouch /etc/subuid\n/etc/subgid\nStep 2: Start the docker daemon with --userns-remap flag\ndockerd\n--userns-remap=default\n",
        "Default Value": "By default, user namespace is not remapped.\n"
      },
      "code": "control \"M-2.8\" do\n  title \"2.8 Enable user namespace support (Scored)\"\n  desc  \"\n    Enable user namespace support in Docker daemon to utilize container user to\nhost user remapping. This recommendation is beneficial where containers you are\nusing do not have an\n    explicit container user defined in the container image. If container images\nthat you are\n    using have a pre-defined non-root user, this recommendation may be skipped\nsince this\n    feature is still in its infancy and might give you unpredictable issues and\ncomplexities.\n    The Linux kernel user namespace support in Docker daemon provides\nadditional security\n    for the Docker host system. It allows a container to have a unique range of\nuser and group\n    IDs which are outside the traditional user and group range utilized by the\nhost system.\n    For example, the root user will have expected administrative privilege\ninside the container\n    but can effectively be mapped to an unprivileged UID on the host system.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttp://man7.org/linux/man-pages/man7/user_namespaces.7.html\\n2.\nhttps://docs.docker.com/engine/reference/commandline/dockerd/#daemon-usernamespace-options\\n3.\nhttp://events.linuxfoundation.org/sites/events/files/slides/User%20Namespaces\\n%20-%20ContainerCon%202015%20-%2016-9-final_0.pdf\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"2.8\"\n  tag \"cis_control\": \"18 Application Software Security\\n\"\n  tag \"cis_level\": \"Level 2 - Docker\"\n  tag \"nist\": [\"SI-1\"]\n  tag \"audit\": \"ps -p $(docker inspect --format='{{ .State.Pid }}' <CONTAINER\nID>) -o\\npid,user\\nThe above command would find the PID of the container and\nthen would list the host user\\nassociated with the container process. If the\ncontainer process is running as root, then this\\nrecommendation is\nnon-compliant.\\nAlternatively, you can run docker info to ensure that the\nuserns is listed under Security\\nOptions:\\ndocker info --format '{{\n.SecurityOptions }}'\\n\"\n  tag \"fix\": \"Please consult Docker documentation for various ways in which\nthis can be configured\\ndepending upon your requirements. Your steps might also\nvary based on platform - For\\nexample, on Red Hat, sub-UIDs and sub-GIDs\nmapping creation does not work\\nautomatically. You might have to create your\nown mapping.\\nHowever, the high-level steps are as below:\\nStep 1: Ensure that\nthe files /etc/subuid and /etc/subgid exist.\\ntouch /etc/subuid\n/etc/subgid\\nStep 2: Start the docker daemon with --userns-remap flag\\ndockerd\n--userns-remap=default\\n\"\n  tag \"Default Value\": \"By default, user namespace is not remapped.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-2.8.rb",
        "line": 1
      },
      "id": "M-2.8"
    },
    {
      "title": "2.9 Ensure the default cgroup usage has been confirmed (Scored)",
      "desc": "The --cgroup-parent option allows you to set the default cgroup parent to\nuse for all the\n    containers. If there is no specific use case, this setting should be left\nat its default.\n    System administrators typically define cgroups under which containers are\nsupposed to\n    run. Even if cgroups are not explicitly defined by the system\nadministrators, containers run\n    under docker cgroup by default.\n    It is possible to attach to a different cgroup other than that is the\ndefault. This usage should\n    be monitored and confirmed. By attaching to a different cgroup than the one\nthat is a\n    default, it is possible to share resources unevenly and thus might starve\nthe host for\n    resources.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://docs.docker.com/engine/reference/commandline/dockerd/#defaultcgroup-parent\n",
        "severity": "medium",
        "cis_id": "2.9",
        "cis_control": "18 Application Software Security\n",
        "cis_level": "Level 2 - Docker",
        "nist": [
          "SI-1"
        ],
        "audit": "ps -ef | grep dockerd\nEnsure that the --cgroup-parent\nparameter is either not set or is set as appropriate nondefault cgroup.\n",
        "fix": "The default setting is good enough and can be left as-is. If you\nwant to specifically set a nondefault cgroup, pass --cgroup-parent parameter to\nthe docker daemon when starting it.\nFor Example,\ndockerd\n--cgroup-parent=/foobar\n",
        "Default Value": "By default, docker daemon uses /docker for fs cgroup\ndriver and system.slice for\nsystemd cgroup driver.\n"
      },
      "code": "control \"M-2.9\" do\n  title \"2.9 Ensure the default cgroup usage has been confirmed (Scored)\"\n  desc  \"\n    The --cgroup-parent option allows you to set the default cgroup parent to\nuse for all the\n    containers. If there is no specific use case, this setting should be left\nat its default.\n    System administrators typically define cgroups under which containers are\nsupposed to\n    run. Even if cgroups are not explicitly defined by the system\nadministrators, containers run\n    under docker cgroup by default.\n    It is possible to attach to a different cgroup other than that is the\ndefault. This usage should\n    be monitored and confirmed. By attaching to a different cgroup than the one\nthat is a\n    default, it is possible to share resources unevenly and thus might starve\nthe host for\n    resources.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://docs.docker.com/engine/reference/commandline/dockerd/#defaultcgroup-parent\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"2.9\"\n  tag \"cis_control\": \"18 Application Software Security\\n\"\n  tag \"cis_level\": \"Level 2 - Docker\"\n  tag \"nist\": [\"SI-1\"]\n  tag \"audit\": \"ps -ef | grep dockerd\\nEnsure that the --cgroup-parent\nparameter is either not set or is set as appropriate nondefault cgroup.\\n\"\n  tag \"fix\": \"The default setting is good enough and can be left as-is. If you\nwant to specifically set a nondefault cgroup, pass --cgroup-parent parameter to\nthe docker daemon when starting it.\\nFor Example,\\ndockerd\n--cgroup-parent=/foobar\\n\"\n  tag \"Default Value\": \"By default, docker daemon uses /docker for fs cgroup\ndriver and system.slice for\\nsystemd cgroup driver.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-2.9.rb",
        "line": 1
      },
      "id": "M-2.9"
    },
    {
      "title": "3.1 Ensure that docker.service file ownership is set to root:root\n(Scored)",
      "desc": "Verify that the docker.service file ownership and group-ownership are\ncorrectly set to\n    root.\n    docker.service file contains sensitive parameters that may alter the\nbehavior of Docker\n    daemon. Hence, it should be owned and group-owned by root to maintain the\nintegrity of\n    the file.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://docs.docker.com/engine/admin/systemd/\n",
        "severity": "medium",
        "cis_id": "3.1",
        "cis_control": "5.1 Minimize And Sparingly Use Administrative\nPrivileges\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "AC-6 (9)"
        ],
        "audit": "Step 1: Find out the file location:\nsystemctl show -p\nFragmentPath docker.service\nStep 2: If the file does not exist, this\nrecommendation is not applicable. If the file exists,\nexecute the below\ncommand with the correct file path to verify that the file is owned\nand\ngroup-owned by root.\nFor example,\nstat -c %U:%G\n/usr/lib/systemd/system/docker.service | grep -v root:root\nThe above command\nshould not return anything.\n",
        "fix": "Step 1: Find out the file location:\nsystemctl show -p\nFragmentPath docker.service\nStep 2: If the file does not exist, this\nrecommendation is not applicable. If the file exists,\nexecute the below\ncommand with the correct file path to set the ownership and group\nownership\nfor the file to root.\nFor example,\nchown root:root\n/usr/lib/systemd/system/docker.service\n",
        "Default Value": "This file may not be present on the system. In that\ncase, this recommendation is not\napplicable. By default, if the file is\npresent, the ownership and group-ownership for this file\nis correctly set to\nroot.\n"
      },
      "code": "control \"M-3.1\" do\n  title \"3.1 Ensure that docker.service file ownership is set to root:root\n(Scored)\"\n  desc  \"\n    Verify that the docker.service file ownership and group-ownership are\ncorrectly set to\n    root.\n    docker.service file contains sensitive parameters that may alter the\nbehavior of Docker\n    daemon. Hence, it should be owned and group-owned by root to maintain the\nintegrity of\n    the file.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://docs.docker.com/engine/admin/systemd/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"3.1\"\n  tag \"cis_control\": \"5.1 Minimize And Sparingly Use Administrative\nPrivileges\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"AC-6 (9)\"]\n  tag \"audit\": \"Step 1: Find out the file location:\\nsystemctl show -p\nFragmentPath docker.service\\nStep 2: If the file does not exist, this\nrecommendation is not applicable. If the file exists,\\nexecute the below\ncommand with the correct file path to verify that the file is owned\nand\\ngroup-owned by root.\\nFor example,\\nstat -c %U:%G\n/usr/lib/systemd/system/docker.service | grep -v root:root\\nThe above command\nshould not return anything.\\n\"\n  tag \"fix\": \"Step 1: Find out the file location:\\nsystemctl show -p\nFragmentPath docker.service\\nStep 2: If the file does not exist, this\nrecommendation is not applicable. If the file exists,\\nexecute the below\ncommand with the correct file path to set the ownership and group\\nownership\nfor the file to root.\\nFor example,\\nchown root:root\n/usr/lib/systemd/system/docker.service\\n\"\n  tag \"Default Value\": \"This file may not be present on the system. In that\ncase, this recommendation is not\\napplicable. By default, if the file is\npresent, the ownership and group-ownership for this file\\nis correctly set to\nroot.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-3.1.rb",
        "line": 1
      },
      "id": "M-3.1"
    },
    {
      "title": "3.10 Ensure that TLS CA certificate file permissions are set to 444\nor\nmore restrictive (Scored)",
      "desc": "Verify that the TLS CA certificate file (the file that is passed alongwith\n--tlscacert\n    parameter) has permissions of 444 or more restrictive.\n    The TLS CA certificate file should be protected from any tampering. It is\nused to\n    authenticate Docker server based on given CA certificate. Hence, it must\nhave permissions\n    of 444 to maintain the integrity of the CA certificate.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://docs.docker.com/registry/insecure/\n2.\nhttps://docs.docker.com/engine/security/https/\n",
        "severity": "medium",
        "cis_id": "3.10",
        "cis_control": "14.4 Protect Information With Access Control Lists\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "AC-3 (3)"
        ],
        "audit": "Execute the below command to verify that the TLS CA certificate\nfile has permissions of 444\nor more restrictive:\nstat -c %a <path to TLS CA\ncertificate file>\n",
        "fix": "chmod 444 <path to TLS CA certificate file>\nThis would set the\nfile permissions of the TLS CA file to 444.\n",
        "Default Value": "By default, the permissions for TLS CA certificate file\nmight not be 444. The default file\npermissions are governed by the system or\nuser specific umask values.\n"
      },
      "code": "control \"M-3.10\" do\n  title \"3.10 Ensure that TLS CA certificate file permissions are set to 444\nor\\nmore restrictive (Scored)\"\n  desc  \"\n    Verify that the TLS CA certificate file (the file that is passed alongwith\n--tlscacert\n    parameter) has permissions of 444 or more restrictive.\n    The TLS CA certificate file should be protected from any tampering. It is\nused to\n    authenticate Docker server based on given CA certificate. Hence, it must\nhave permissions\n    of 444 to maintain the integrity of the CA certificate.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://docs.docker.com/registry/insecure/\\n2.\nhttps://docs.docker.com/engine/security/https/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"3.10\"\n  tag \"cis_control\": \"14.4 Protect Information With Access Control Lists\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"AC-3 (3)\"]\n  tag \"audit\": \"Execute the below command to verify that the TLS CA certificate\nfile has permissions of 444\\nor more restrictive:\\nstat -c %a <path to TLS CA\ncertificate file>\\n\"\n  tag \"fix\": \"chmod 444 <path to TLS CA certificate file>\\nThis would set the\nfile permissions of the TLS CA file to 444.\\n\"\n  tag \"Default Value\": \"By default, the permissions for TLS CA certificate file\nmight not be 444. The default file\\npermissions are governed by the system or\nuser specific umask values.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-3.10.rb",
        "line": 1
      },
      "id": "M-3.10"
    },
    {
      "title": "3.11 Ensure that Docker server certificate file ownership is set\nto\nroot:root (Scored)",
      "desc": "Verify that the Docker server certificate file (the file that is passed\nalongwith --tlscert\n    parameter) is owned and group-owned by root.\n    The Docker server certificate file should be protected from any tampering.\nIt is used to\n    authenticate Docker server based on the given server certificate. Hence, it\nmust be owned\n    and group-owned by root to maintain the integrity of the certificate.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://docs.docker.com/registry/insecure/\n2.\nhttps://docs.docker.com/engine/security/https/\n",
        "severity": "medium",
        "cis_id": "3.11",
        "cis_control": "5.1 Minimize And Sparingly Use Administrative\nPrivileges\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "AC-6 (9)"
        ],
        "audit": "Execute the below command to verify that the Docker server\ncertificate file is owned and\ngroup-owned by root:\nstat -c %U:%G <path to\nDocker server certificate file> | grep -v root:root\nThe above command should\nnot return anything.\n",
        "fix": "chown root:root <path to Docker server certificate file>\nThis\nwould set the ownership and group-ownership for the Docker server certificate\nfile to\nroot.\n",
        "Default Value": "By default, the ownership and group-ownership for\nDocker server certificate file is\ncorrectly set to root.\n"
      },
      "code": "control \"M-3.11\" do\n  title \"3.11 Ensure that Docker server certificate file ownership is set\nto\\nroot:root (Scored)\"\n  desc  \"\n    Verify that the Docker server certificate file (the file that is passed\nalongwith --tlscert\n    parameter) is owned and group-owned by root.\n    The Docker server certificate file should be protected from any tampering.\nIt is used to\n    authenticate Docker server based on the given server certificate. Hence, it\nmust be owned\n    and group-owned by root to maintain the integrity of the certificate.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://docs.docker.com/registry/insecure/\\n2.\nhttps://docs.docker.com/engine/security/https/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"3.11\"\n  tag \"cis_control\": \"5.1 Minimize And Sparingly Use Administrative\nPrivileges\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"AC-6 (9)\"]\n  tag \"audit\": \"Execute the below command to verify that the Docker server\ncertificate file is owned and\\ngroup-owned by root:\\nstat -c %U:%G <path to\nDocker server certificate file> | grep -v root:root\\nThe above command should\nnot return anything.\\n\"\n  tag \"fix\": \"chown root:root <path to Docker server certificate file>\\nThis\nwould set the ownership and group-ownership for the Docker server certificate\nfile to\\nroot.\\n\"\n  tag \"Default Value\": \"By default, the ownership and group-ownership for\nDocker server certificate file is\\ncorrectly set to root.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-3.11.rb",
        "line": 1
      },
      "id": "M-3.11"
    },
    {
      "title": "3.12 Ensure that Docker server certificate file permissions are set to\n444\nor more restrictive (Scored)",
      "desc": "Verify that the Docker server certificate file (the file that is passed\nalongwith --tlscert\n    parameter) has permissions of 444 or more restrictive.\n    The Docker server certificate file should be protected from any tampering.\nIt is used to\n    authenticate Docker server based on the given server certificate. Hence, it\nmust have\n    permissions of 444 to maintain the integrity of the certificate.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://docs.docker.com/registry/insecure/\n2.\nhttps://docs.docker.com/engine/security/https/\n",
        "severity": "medium",
        "cis_id": "3.12",
        "cis_control": "14.4 Protect Information With Access Control Lists\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "AC-3 (3)"
        ],
        "audit": "Execute the below command to verify that the Docker server\ncertificate file has\npermissions of 444 or more restrictive:\nstat -c %a <path\nto Docker server certificate file>\n",
        "fix": "chmod 444 <path to Docker server certificate file>\nThis would\nset the file permissions of the Docker server file to 444.\n",
        "Default Value": "By default, the permissions for Docker server\ncertificate file might not be 444. The default\nfile permissions are governed\nby the system or user specific umask values.\n"
      },
      "code": "control \"M-3.12\" do\n  title \"3.12 Ensure that Docker server certificate file permissions are set to\n444\\nor more restrictive (Scored)\"\n  desc  \"\n    Verify that the Docker server certificate file (the file that is passed\nalongwith --tlscert\n    parameter) has permissions of 444 or more restrictive.\n    The Docker server certificate file should be protected from any tampering.\nIt is used to\n    authenticate Docker server based on the given server certificate. Hence, it\nmust have\n    permissions of 444 to maintain the integrity of the certificate.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://docs.docker.com/registry/insecure/\\n2.\nhttps://docs.docker.com/engine/security/https/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"3.12\"\n  tag \"cis_control\": \"14.4 Protect Information With Access Control Lists\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"AC-3 (3)\"]\n  tag \"audit\": \"Execute the below command to verify that the Docker server\ncertificate file has\\npermissions of 444 or more restrictive:\\nstat -c %a <path\nto Docker server certificate file>\\n\"\n  tag \"fix\": \"chmod 444 <path to Docker server certificate file>\\nThis would\nset the file permissions of the Docker server file to 444.\\n\"\n  tag \"Default Value\": \"By default, the permissions for Docker server\ncertificate file might not be 444. The default\\nfile permissions are governed\nby the system or user specific umask values.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-3.12.rb",
        "line": 1
      },
      "id": "M-3.12"
    },
    {
      "title": "3.13 Ensure that Docker server certificate key file ownership is set\nto\nroot:root (Scored)",
      "desc": "Verify that the Docker server certificate key file (the file that is passed\nalongwith --tlskey\n    parameter) is owned and group-owned by root.\n    The Docker server certificate key file should be protected from any\ntampering or unneeded\n    reads. It holds the private key for the Docker server certificate. Hence,\nit must be owned\n    and group-owned by root to maintain the integrity of the Docker server\ncertificate.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://docs.docker.com/registry/insecure/\n2.\nhttps://docs.docker.com/engine/security/https/\n",
        "severity": "medium",
        "cis_id": "3.13",
        "cis_control": "5.1 Minimize And Sparingly Use Administrative\nPrivileges\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "AC-6 (9)"
        ],
        "audit": "Execute the below command to verify that the Docker server\ncertificate key file is owned\nand group-owned by root:\nstat -c %U:%G <path to\nDocker server certificate key file> | grep -v\nroot:root\nThe above command\nshould not return anything.\n",
        "fix": "chown root:root <path to Docker server certificate key\nfile>\nThis would set the ownership and group-ownership for the Docker server\ncertificate key\nfile to root.\n",
        "Default Value": "By default, the ownership and group-ownership for\nDocker server certificate key file is\ncorrectly set to root.\n"
      },
      "code": "control \"M-3.13\" do\n  title \"3.13 Ensure that Docker server certificate key file ownership is set\nto\\nroot:root (Scored)\"\n  desc  \"\n    Verify that the Docker server certificate key file (the file that is passed\nalongwith --tlskey\n    parameter) is owned and group-owned by root.\n    The Docker server certificate key file should be protected from any\ntampering or unneeded\n    reads. It holds the private key for the Docker server certificate. Hence,\nit must be owned\n    and group-owned by root to maintain the integrity of the Docker server\ncertificate.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://docs.docker.com/registry/insecure/\\n2.\nhttps://docs.docker.com/engine/security/https/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"3.13\"\n  tag \"cis_control\": \"5.1 Minimize And Sparingly Use Administrative\nPrivileges\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"AC-6 (9)\"]\n  tag \"audit\": \"Execute the below command to verify that the Docker server\ncertificate key file is owned\\nand group-owned by root:\\nstat -c %U:%G <path to\nDocker server certificate key file> | grep -v\\nroot:root\\nThe above command\nshould not return anything.\\n\"\n  tag \"fix\": \"chown root:root <path to Docker server certificate key\nfile>\\nThis would set the ownership and group-ownership for the Docker server\ncertificate key\\nfile to root.\\n\"\n  tag \"Default Value\": \"By default, the ownership and group-ownership for\nDocker server certificate key file is\\ncorrectly set to root.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-3.13.rb",
        "line": 1
      },
      "id": "M-3.13"
    },
    {
      "title": "3.14 Ensure that Docker server certificate key file permissions are\nset to\n400 (Scored)",
      "desc": "Verify that the Docker server certificate key file (the file that is passed\nalongwith --tlskey\n    parameter) has permissions of 400.\n    The Docker server certificate key file should be protected from any\ntampering or unneeded\n    reads. It holds the private key for the Docker server certificate. Hence,\nit must have\n    permissions of 400 to maintain the integrity of the Docker server\ncertificate.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://docs.docker.com/registry/insecure/\n2.\nhttps://docs.docker.com/engine/security/https/\n",
        "severity": "medium",
        "cis_id": "3.14",
        "cis_control": "14.4 Protect Information With Access Control Lists\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "AC-3 (3)"
        ],
        "audit": "Execute the below command to verify that the Docker server\ncertificate key file has\npermissions of 400:\nstat -c %a <path to Docker\nserver certificate key file>\n",
        "fix": "chmod 400 <path to Docker server certificate key file>\nThis\nwould set the Docker server certificate key file permissions to 400.\n",
        "Default Value": "By default, the permissions for Docker server\ncertificate key file might not be 400. The\ndefault file permissions are\ngoverned by the system or user specific umask values.\n"
      },
      "code": "control \"M-3.14\" do\n  title \"3.14 Ensure that Docker server certificate key file permissions are\nset to\\n400 (Scored)\"\n  desc  \"\n    Verify that the Docker server certificate key file (the file that is passed\nalongwith --tlskey\n    parameter) has permissions of 400.\n    The Docker server certificate key file should be protected from any\ntampering or unneeded\n    reads. It holds the private key for the Docker server certificate. Hence,\nit must have\n    permissions of 400 to maintain the integrity of the Docker server\ncertificate.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://docs.docker.com/registry/insecure/\\n2.\nhttps://docs.docker.com/engine/security/https/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"3.14\"\n  tag \"cis_control\": \"14.4 Protect Information With Access Control Lists\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"AC-3 (3)\"]\n  tag \"audit\": \"Execute the below command to verify that the Docker server\ncertificate key file has\\npermissions of 400:\\nstat -c %a <path to Docker\nserver certificate key file>\\n\"\n  tag \"fix\": \"chmod 400 <path to Docker server certificate key file>\\nThis\nwould set the Docker server certificate key file permissions to 400.\\n\"\n  tag \"Default Value\": \"By default, the permissions for Docker server\ncertificate key file might not be 400. The\\ndefault file permissions are\ngoverned by the system or user specific umask values.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-3.14.rb",
        "line": 1
      },
      "id": "M-3.14"
    },
    {
      "title": "3.15 Ensure that Docker socket file ownership is set to\nroot:docker(Scored)",
      "desc": "Verify that the Docker socket file is owned by root and group-owned by\ndocker.\n    Docker daemon runs as root. The default Unix socket hence must be owned by\nroot. If any\n    other user or process owns this socket, then it might be possible for that\nnon-privileged\n    user or process to interact with Docker daemon. Also, such a non-privileged\nuser or\n    process might interact with containers. This is neither secure nor desired\nbehavior.\n    Additionally, the Docker installer creates a Unix group called docker. You\ncan add users to\n    this group, and then those users would be able to read and write to default\nDocker Unix\n    socket. The membership to the docker group is tightly controlled by the\nsystem\n    administrator. If any other group owns this socket, then it might be\npossible for members\n    of that group to interact with Docker daemon. Also, such a group might not\nbe as tightly\n    controlled as the docker group. This is neither secure nor desired behavior.\n    Hence, the default Docker Unix socket file must be owned by root and\ngroup-owned by\n    docker to maintain the integrity of the socket file.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://docs.docker.com/engine/reference/commandline/dockerd/#daemonsocket-option\n2.\nhttps://docs.docker.com/engine/reference/commandline/dockerd/#bind-dockerto-another-hostport-or-a-unix-socket\n",
        "severity": "medium",
        "cis_id": "3.15",
        "cis_control": "5.1 Minimize And Sparingly Use Administrative\nPrivileges\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "AC-6 (9)"
        ],
        "audit": "Execute the below command to verify that the Docker socket file\nis owned by root and\ngroup-owned by docker:\nstat -c %U:%G\n/var/run/docker.sock | grep -v root:docker\nThe above command should not return\nanything.\n",
        "fix": "chown root:docker /var/run/docker.sock\nThis would set the\nownership to root and group-ownership to docker for default Docker\nsocket\nfile.\n",
        "Default Value": "By default, the ownership and group-ownership for\nDocker socket file is correctly set to\nroot:docker.\n"
      },
      "code": "control \"M-3.15\" do\n  title \"3.15 Ensure that Docker socket file ownership is set to\nroot:docker(Scored)\"\n  desc  \"\n    Verify that the Docker socket file is owned by root and group-owned by\ndocker.\n    Docker daemon runs as root. The default Unix socket hence must be owned by\nroot. If any\n    other user or process owns this socket, then it might be possible for that\nnon-privileged\n    user or process to interact with Docker daemon. Also, such a non-privileged\nuser or\n    process might interact with containers. This is neither secure nor desired\nbehavior.\n    Additionally, the Docker installer creates a Unix group called docker. You\ncan add users to\n    this group, and then those users would be able to read and write to default\nDocker Unix\n    socket. The membership to the docker group is tightly controlled by the\nsystem\n    administrator. If any other group owns this socket, then it might be\npossible for members\n    of that group to interact with Docker daemon. Also, such a group might not\nbe as tightly\n    controlled as the docker group. This is neither secure nor desired behavior.\n    Hence, the default Docker Unix socket file must be owned by root and\ngroup-owned by\n    docker to maintain the integrity of the socket file.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://docs.docker.com/engine/reference/commandline/dockerd/#daemonsocket-option\\n2.\nhttps://docs.docker.com/engine/reference/commandline/dockerd/#bind-dockerto-another-hostport-or-a-unix-socket\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"3.15\"\n  tag \"cis_control\": \"5.1 Minimize And Sparingly Use Administrative\nPrivileges\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"AC-6 (9)\"]\n  tag \"audit\": \"Execute the below command to verify that the Docker socket file\nis owned by root and\\ngroup-owned by docker:\\nstat -c %U:%G\n/var/run/docker.sock | grep -v root:docker\\nThe above command should not return\nanything.\\n\"\n  tag \"fix\": \"chown root:docker /var/run/docker.sock\\nThis would set the\nownership to root and group-ownership to docker for default Docker\\nsocket\nfile.\\n\"\n  tag \"Default Value\": \"By default, the ownership and group-ownership for\nDocker socket file is correctly set to\\nroot:docker.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-3.15.rb",
        "line": 1
      },
      "id": "M-3.15"
    },
    {
      "title": "3.16 Ensure that Docker socket file permissions are set to 660 or\nmore\nrestrictive (Scored)",
      "desc": "Verify that the Docker socket file has permissions of 660 or more\nrestrictive.\n    Only root and members of docker group should be allowed to read and write\nto default\n    Docker Unix socket. Hence, the Docket socket file must have permissions of\n660 or more\n    restrictive.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://docs.docker.com/engine/reference/commandline/dockerd/#daemonsocket-option\n2.\nhttps://docs.docker.com/engine/reference/commandline/dockerd/#bind-dockerto-another-hostport-or-a-unix-socket\n",
        "severity": "medium",
        "cis_id": "3.16",
        "cis_control": "14.4 Protect Information With Access Control Lists\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "AC-3 (3)"
        ],
        "audit": "Execute the below command to verify that the Docker socket file\nhas permissions of 660 or\nmore restrictive:\nstat -c %a /var/run/docker.sock\n",
        "fix": "chmod 660 /var/run/docker.sock\nThis would set the file\npermissions of the Docker socket file to 660.\n",
        "Default Value": "By default, the permissions for Docker socket file is\ncorrectly set to 660.\n"
      },
      "code": "control \"M-3.16\" do\n  title \"3.16 Ensure that Docker socket file permissions are set to 660 or\nmore\\nrestrictive (Scored)\"\n  desc  \"\n    Verify that the Docker socket file has permissions of 660 or more\nrestrictive.\n    Only root and members of docker group should be allowed to read and write\nto default\n    Docker Unix socket. Hence, the Docket socket file must have permissions of\n660 or more\n    restrictive.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://docs.docker.com/engine/reference/commandline/dockerd/#daemonsocket-option\\n2.\nhttps://docs.docker.com/engine/reference/commandline/dockerd/#bind-dockerto-another-hostport-or-a-unix-socket\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"3.16\"\n  tag \"cis_control\": \"14.4 Protect Information With Access Control Lists\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"AC-3 (3)\"]\n  tag \"audit\": \"Execute the below command to verify that the Docker socket file\nhas permissions of 660 or\\nmore restrictive:\\nstat -c %a /var/run/docker.sock\\n\"\n  tag \"fix\": \"chmod 660 /var/run/docker.sock\\nThis would set the file\npermissions of the Docker socket file to 660.\\n\"\n  tag \"Default Value\": \"By default, the permissions for Docker socket file is\ncorrectly set to 660.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-3.16.rb",
        "line": 1
      },
      "id": "M-3.16"
    },
    {
      "title": "3.17 Ensure that daemon.json file ownership is set to root:root\n(Scored)",
      "desc": "Verify that the daemon.json file ownership and group-ownership is correctly\nset to root.\n    daemon.json file contains sensitive parameters that may alter the behavior\nof docker\n    daemon. Hence, it should be owned and group-owned by root to maintain the\nintegrity of\n    the file.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://docs.docker.com/engine/reference/commandline/dockerd/#daemonconfiguration-file\n",
        "severity": "medium",
        "cis_id": "3.17",
        "cis_control": "5.1 Minimize And Sparingly Use Administrative\nPrivileges\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "AC-6 (9)"
        ],
        "audit": "Execute the below command to verify that the file is owned and\ngroup-owned by root:\nstat -c %U:%G /etc/docker/daemon.json | grep -v\nroot:root\nThe above command should not return anything.\n",
        "fix": "chown root:root /etc/docker/daemon.json\nThis would set the\nownership and group-ownership for the file to root.\n",
        "Default Value": "This file may not be present on the system. In that\ncase, this recommendation is not\napplicable.\n"
      },
      "code": "control \"M-3.17\" do\n  title \"3.17 Ensure that daemon.json file ownership is set to root:root\n(Scored)\"\n  desc  \"\n    Verify that the daemon.json file ownership and group-ownership is correctly\nset to root.\n    daemon.json file contains sensitive parameters that may alter the behavior\nof docker\n    daemon. Hence, it should be owned and group-owned by root to maintain the\nintegrity of\n    the file.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://docs.docker.com/engine/reference/commandline/dockerd/#daemonconfiguration-file\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"3.17\"\n  tag \"cis_control\": \"5.1 Minimize And Sparingly Use Administrative\nPrivileges\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"AC-6 (9)\"]\n  tag \"audit\": \"Execute the below command to verify that the file is owned and\ngroup-owned by root:\\nstat -c %U:%G /etc/docker/daemon.json | grep -v\nroot:root\\nThe above command should not return anything.\\n\"\n  tag \"fix\": \"chown root:root /etc/docker/daemon.json\\nThis would set the\nownership and group-ownership for the file to root.\\n\"\n  tag \"Default Value\": \"This file may not be present on the system. In that\ncase, this recommendation is not\\napplicable.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-3.17.rb",
        "line": 1
      },
      "id": "M-3.17"
    },
    {
      "title": "3.18 Ensure that daemon.json file permissions are set to 644 or\nmore\nrestrictive (Scored)",
      "desc": "Verify that the daemon.json file permissions are correctly set to 644 or\nmore restrictive.\n    daemon.json file contains sensitive parameters that may alter the behavior\nof docker\n    daemon. Hence, it should be writable only by root to maintain the integrity\nof the file.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://docs.docker.com/engine/reference/commandline/dockerd/#daemonconfiguration-file\n",
        "severity": "medium",
        "cis_id": "3.18",
        "cis_control": "14.4 Protect Information With Access Control Lists\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "AC-3 (3)"
        ],
        "audit": "Execute the below command to verify that the file permissions\nare correctly set to 644 or\nmore restrictive:\nstat -c %a\n/etc/docker/daemon.json\n",
        "fix": "chmod 644 /etc/docker/daemon.json\nThis would set the file\npermissions for this file to 644.\n",
        "Default Value": "This file may not be present on the system. In that\ncase, this recommendation is not\napplicable.\n"
      },
      "code": "control \"M-3.18\" do\n  title \"3.18 Ensure that daemon.json file permissions are set to 644 or\nmore\\nrestrictive (Scored)\"\n  desc  \"\n    Verify that the daemon.json file permissions are correctly set to 644 or\nmore restrictive.\n    daemon.json file contains sensitive parameters that may alter the behavior\nof docker\n    daemon. Hence, it should be writable only by root to maintain the integrity\nof the file.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://docs.docker.com/engine/reference/commandline/dockerd/#daemonconfiguration-file\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"3.18\"\n  tag \"cis_control\": \"14.4 Protect Information With Access Control Lists\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"AC-3 (3)\"]\n  tag \"audit\": \"Execute the below command to verify that the file permissions\nare correctly set to 644 or\\nmore restrictive:\\nstat -c %a\n/etc/docker/daemon.json\\n\"\n  tag \"fix\": \"chmod 644 /etc/docker/daemon.json\\nThis would set the file\npermissions for this file to 644.\\n\"\n  tag \"Default Value\": \"This file may not be present on the system. In that\ncase, this recommendation is not\\napplicable.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-3.18.rb",
        "line": 1
      },
      "id": "M-3.18"
    },
    {
      "title": "3.19 Ensure that /etc/default/docker file ownership is set to\nroot:root(Scored)",
      "desc": "Verify that the /etc/default/docker file ownership and group-ownership is\ncorrectly set\n    to root.\n    /etc/default/docker file contains sensitive parameters that may alter the\nbehavior of\n    docker daemon. Hence, it should be owned and group-owned by root to\nmaintain the\n    integrity of the file.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://docs.docker.com/engine/admin/configuring/\n",
        "severity": "medium",
        "cis_id": "3.19",
        "cis_control": "5.1 Minimize And Sparingly Use Administrative\nPrivileges\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "AC-6 (9)"
        ],
        "audit": "Execute the below command to verify that the file is owned and\ngroup-owned by root:\nstat -c %U:%G /etc/default/docker | grep -v\nroot:root\nThe above command should not return anything.\n",
        "fix": "chown root:root /etc/default/docker\nThis would set the ownership\nand group-ownership for the file to root.\n",
        "Default Value": "This file may not be present on the system. In that\ncase, this recommendation is not\napplicable.\n"
      },
      "code": "control \"M-3.19\" do\n  title \"3.19 Ensure that /etc/default/docker file ownership is set to\nroot:root(Scored)\"\n  desc  \"\n    Verify that the /etc/default/docker file ownership and group-ownership is\ncorrectly set\n    to root.\n    /etc/default/docker file contains sensitive parameters that may alter the\nbehavior of\n    docker daemon. Hence, it should be owned and group-owned by root to\nmaintain the\n    integrity of the file.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://docs.docker.com/engine/admin/configuring/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"3.19\"\n  tag \"cis_control\": \"5.1 Minimize And Sparingly Use Administrative\nPrivileges\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"AC-6 (9)\"]\n  tag \"audit\": \"Execute the below command to verify that the file is owned and\ngroup-owned by root:\\nstat -c %U:%G /etc/default/docker | grep -v\nroot:root\\nThe above command should not return anything.\\n\"\n  tag \"fix\": \"chown root:root /etc/default/docker\\nThis would set the ownership\nand group-ownership for the file to root.\\n\"\n  tag \"Default Value\": \"This file may not be present on the system. In that\ncase, this recommendation is not\\napplicable.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-3.19.rb",
        "line": 1
      },
      "id": "M-3.19"
    },
    {
      "title": "3.2 Ensure that docker.service file permissions are set to 644 or\nmore\nrestrictive (Scored)",
      "desc": "Verify that the docker.service file permissions are correctly set to 644 or\nmore restrictive.\n    docker.service file contains sensitive parameters that may alter the\nbehavior of Docker\n    daemon. Hence, it should not be writable by any other user other than root\nto maintain the\n    integrity of the file.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://docs.docker.com/articles/systemd/\n",
        "severity": "medium",
        "cis_id": "3.2",
        "cis_control": "14.4 Protect Information With Access Control Lists\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "AC-3 (3)"
        ],
        "audit": "Step 1: Find out the file location:\nsystemctl show -p\nFragmentPath docker.service\nStep 2: If the file does not exist, this\nrecommendation is not applicable. If the file exists,\nexecute the below\ncommand with the correct file path to verify that the file permissions are\nset\nto 644 or more restrictive.\nFor example,\nstat -c %a\n/usr/lib/systemd/system/docker.service\n",
        "fix": "Step 1: Find out the file location:\nsystemctl show -p\nFragmentPath docker.service\nStep 2: If the file does not exist, this\nrecommendation is not applicable. If the file exists,\nexecute the below\ncommand with the correct file path to set the file permissions to 644.\nFor\nexample,\nchmod 644 /usr/lib/systemd/system/docker.service\n",
        "Default Value": "This file may not be present on the system. In that\ncase, this recommendation is not\napplicable. By default, if the file is\npresent, the file permissions are correctly set to 644.\n"
      },
      "code": "control \"M-3.2\" do\n  title \"3.2 Ensure that docker.service file permissions are set to 644 or\nmore\\nrestrictive (Scored)\"\n  desc  \"\n    Verify that the docker.service file permissions are correctly set to 644 or\nmore restrictive.\n    docker.service file contains sensitive parameters that may alter the\nbehavior of Docker\n    daemon. Hence, it should not be writable by any other user other than root\nto maintain the\n    integrity of the file.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://docs.docker.com/articles/systemd/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"3.2\"\n  tag \"cis_control\": \"14.4 Protect Information With Access Control Lists\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"AC-3 (3)\"]\n  tag \"audit\": \"Step 1: Find out the file location:\\nsystemctl show -p\nFragmentPath docker.service\\nStep 2: If the file does not exist, this\nrecommendation is not applicable. If the file exists,\\nexecute the below\ncommand with the correct file path to verify that the file permissions are\\nset\nto 644 or more restrictive.\\nFor example,\\nstat -c %a\n/usr/lib/systemd/system/docker.service\\n\"\n  tag \"fix\": \"Step 1: Find out the file location:\\nsystemctl show -p\nFragmentPath docker.service\\nStep 2: If the file does not exist, this\nrecommendation is not applicable. If the file exists,\\nexecute the below\ncommand with the correct file path to set the file permissions to 644.\\nFor\nexample,\\nchmod 644 /usr/lib/systemd/system/docker.service\\n\"\n  tag \"Default Value\": \"This file may not be present on the system. In that\ncase, this recommendation is not\\napplicable. By default, if the file is\npresent, the file permissions are correctly set to 644.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-3.2.rb",
        "line": 1
      },
      "id": "M-3.2"
    },
    {
      "title": "3.20 Ensure that /etc/default/docker file permissions are set to 644\nor\nmore restrictive (Scored)",
      "desc": "Verify that the /etc/default/docker file permissions are correctly set to\n644 or more\n    restrictive.\n    /etc/default/docker file contains sensitive parameters that may alter the\nbehavior of\n    docker daemon. Hence, it should be writable only by root to maintain the\nintegrity of the\n    file.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://docs.docker.com/engine/admin/configuring/\n",
        "severity": "medium",
        "cis_id": "3.20",
        "cis_control": "14.4 Protect Information With Access Control Lists\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "AC-3 (3)"
        ],
        "audit": "Execute the below command to verify that the file permissions\nare correctly set to 644 or\nmore restrictive:\nstat -c %a\n/etc/default/docker\n",
        "fix": "chmod 644 /etc/default/docker\nThis would set the file\npermissions for this file to 644.\n",
        "Default Value": "This file may not be present on the system. In that\ncase, this recommendation is not\napplicable.\n"
      },
      "code": "control \"M-3.20\" do\n  title \"3.20 Ensure that /etc/default/docker file permissions are set to 644\nor\\nmore restrictive (Scored)\"\n  desc  \"\n    Verify that the /etc/default/docker file permissions are correctly set to\n644 or more\n    restrictive.\n    /etc/default/docker file contains sensitive parameters that may alter the\nbehavior of\n    docker daemon. Hence, it should be writable only by root to maintain the\nintegrity of the\n    file.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://docs.docker.com/engine/admin/configuring/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"3.20\"\n  tag \"cis_control\": \"14.4 Protect Information With Access Control Lists\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"AC-3 (3)\"]\n  tag \"audit\": \"Execute the below command to verify that the file permissions\nare correctly set to 644 or\\nmore restrictive:\\nstat -c %a\n/etc/default/docker\\n\"\n  tag \"fix\": \"chmod 644 /etc/default/docker\\nThis would set the file\npermissions for this file to 644.\\n\"\n  tag \"Default Value\": \"This file may not be present on the system. In that\ncase, this recommendation is not\\napplicable.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-3.20.rb",
        "line": 1
      },
      "id": "M-3.20"
    },
    {
      "title": "3.3 Ensure that docker.socket file ownership is set to root:root\n(Scored)",
      "desc": "Verify that the docker.socket file ownership and group ownership is\ncorrectly set to root.\n    docker.socket file contains sensitive parameters that may alter the\nbehavior of Docker\n    remote API. Hence, it should be owned and group-owned by root to maintain\nthe integrity\n    of the file.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://docs.docker.com/engine/reference/commandline/dockerd/#daemonsocket-option\n2.\nhttps://github.com/docker/dockerce/blob/master/components/packaging/deb/systemd/docker.socket\n",
        "severity": "medium",
        "cis_id": "3.3",
        "cis_control": "5.1 Minimize And Sparingly Use Administrative\nPrivileges\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "AC-6 (9)"
        ],
        "audit": "Step 1: Find out the file location:\nsystemctl show -p\nFragmentPath docker.socket\nStep 2: If the file does not exist, this\nrecommendation is not applicable. If the file exists,\nexecute the below\ncommand with the correct file path to verify that the file is owned\nand\ngroup-owned by root.\nFor example,\nstat -c %U:%G\n/usr/lib/systemd/system/docker.socket | grep -v root:root\nThe above command\nshould not return anything.\n",
        "fix": "Step 1: Find out the file location:\nsystemctl show -p\nFragmentPath docker.socket\nStep 2: If the file does not exist, this\nrecommendation is not applicable. If the file exists,\nexecute the below\ncommand with the correct file path to set the ownership and group\nownership\nfor the file to root.\nFor example,\nchown root:root\n/usr/lib/systemd/system/docker.socket\n",
        "Default Value": "This file may not be present on the system. In that\ncase, this recommendation is not\napplicable. By default, if the file is\npresent, the ownership and group-ownership for this file\nis correctly set to\nroot.\n"
      },
      "code": "control \"M-3.3\" do\n  title \"3.3 Ensure that docker.socket file ownership is set to root:root\n(Scored)\"\n  desc  \"\n    Verify that the docker.socket file ownership and group ownership is\ncorrectly set to root.\n    docker.socket file contains sensitive parameters that may alter the\nbehavior of Docker\n    remote API. Hence, it should be owned and group-owned by root to maintain\nthe integrity\n    of the file.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://docs.docker.com/engine/reference/commandline/dockerd/#daemonsocket-option\\n2.\nhttps://github.com/docker/dockerce/blob/master/components/packaging/deb/systemd/docker.socket\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"3.3\"\n  tag \"cis_control\": \"5.1 Minimize And Sparingly Use Administrative\nPrivileges\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"AC-6 (9)\"]\n  tag \"audit\": \"Step 1: Find out the file location:\\nsystemctl show -p\nFragmentPath docker.socket\\nStep 2: If the file does not exist, this\nrecommendation is not applicable. If the file exists,\\nexecute the below\ncommand with the correct file path to verify that the file is owned\nand\\ngroup-owned by root.\\nFor example,\\nstat -c %U:%G\n/usr/lib/systemd/system/docker.socket | grep -v root:root\\nThe above command\nshould not return anything.\\n\"\n  tag \"fix\": \"Step 1: Find out the file location:\\nsystemctl show -p\nFragmentPath docker.socket\\nStep 2: If the file does not exist, this\nrecommendation is not applicable. If the file exists,\\nexecute the below\ncommand with the correct file path to set the ownership and group\\nownership\nfor the file to root.\\nFor example,\\nchown root:root\n/usr/lib/systemd/system/docker.socket\\n\"\n  tag \"Default Value\": \"This file may not be present on the system. In that\ncase, this recommendation is not\\napplicable. By default, if the file is\npresent, the ownership and group-ownership for this file\\nis correctly set to\nroot.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-3.3.rb",
        "line": 1
      },
      "id": "M-3.3"
    },
    {
      "title": "3.4 Ensure that docker.socket file permissions are set to 644 or\nmore\nrestrictive (Scored)",
      "desc": "Verify that the docker.socket file permissions are correctly set to 644 or\nmore restrictive.\n    docker.socket file contains sensitive parameters that may alter the\nbehavior of Docker\n    remote API. Hence, it should be writable only by root to maintain the\nintegrity of the file.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://docs.docker.com/engine/reference/commandline/dockerd/#bind-dockerto-another-hostport-or-a-unix-socket\n2.\nhttps://github.com/YungSang/fedora-atomicpacker/blob/master/oem/docker.socket\n3.\nhttp://daviddaeschler.com/2014/12/14/centos-7rhel-7-and-docker-containerson-boot/\n",
        "severity": "medium",
        "cis_id": "3.4",
        "cis_control": "14.4 Protect Information With Access Control Lists\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "AC-3 (3)"
        ],
        "audit": "Step 1: Find out the file location:\nsystemctl show -p\nFragmentPath docker.socket\nStep 2: If the file does not exist, this\nrecommendation is not applicable. If the file exists,\nexecute the below\ncommand with the correct file path to verify that the file permissions are\nset\nto 644 or more restrictive.\nFor example,\nstat -c %a\n/usr/lib/systemd/system/docker.socket\n",
        "fix": "Step 1: Find out the file location:\nsystemctl show -p\nFragmentPath docker.socket\nStep 2: If the file does not exist, this\nrecommendation is not applicable. If the file exists,\nexecute the below\ncommand with the correct file path to set the file permissions to 644.\nFor\nexample,\nchmod 644 /usr/lib/systemd/system/docker.socket\n",
        "Default Value": "This file may not be present on the system. In that\ncase, this recommendation is not\napplicable. By default, if the file is\npresent, the file permissions for this file are correctly set\nto 644.\n"
      },
      "code": "control \"M-3.4\" do\n  title \"3.4 Ensure that docker.socket file permissions are set to 644 or\nmore\\nrestrictive (Scored)\"\n  desc  \"\n    Verify that the docker.socket file permissions are correctly set to 644 or\nmore restrictive.\n    docker.socket file contains sensitive parameters that may alter the\nbehavior of Docker\n    remote API. Hence, it should be writable only by root to maintain the\nintegrity of the file.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://docs.docker.com/engine/reference/commandline/dockerd/#bind-dockerto-another-hostport-or-a-unix-socket\\n2.\nhttps://github.com/YungSang/fedora-atomicpacker/blob/master/oem/docker.socket\\n3.\nhttp://daviddaeschler.com/2014/12/14/centos-7rhel-7-and-docker-containerson-boot/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"3.4\"\n  tag \"cis_control\": \"14.4 Protect Information With Access Control Lists\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"AC-3 (3)\"]\n  tag \"audit\": \"Step 1: Find out the file location:\\nsystemctl show -p\nFragmentPath docker.socket\\nStep 2: If the file does not exist, this\nrecommendation is not applicable. If the file exists,\\nexecute the below\ncommand with the correct file path to verify that the file permissions are\\nset\nto 644 or more restrictive.\\nFor example,\\nstat -c %a\n/usr/lib/systemd/system/docker.socket\\n\"\n  tag \"fix\": \"Step 1: Find out the file location:\\nsystemctl show -p\nFragmentPath docker.socket\\nStep 2: If the file does not exist, this\nrecommendation is not applicable. If the file exists,\\nexecute the below\ncommand with the correct file path to set the file permissions to 644.\\nFor\nexample,\\nchmod 644 /usr/lib/systemd/system/docker.socket\\n\"\n  tag \"Default Value\": \"This file may not be present on the system. In that\ncase, this recommendation is not\\napplicable. By default, if the file is\npresent, the file permissions for this file are correctly set\\nto 644.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-3.4.rb",
        "line": 1
      },
      "id": "M-3.4"
    },
    {
      "title": "3.5 Ensure that /etc/docker directory ownership is set to\nroot:root(Scored)",
      "desc": "Verify that the /etc/docker directory ownership and group-ownership is\ncorrectly set to\n    root.\n    /etc/docker directory contains certificates and keys in addition to various\nsensitive files.\n    Hence, it should be owned and group-owned by root to maintain the integrity\nof the\n    directory.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://docs.docker.com/engine/security/https/\n",
        "severity": "medium",
        "cis_id": "3.5",
        "cis_control": "5.1 Minimize And Sparingly Use Administrative\nPrivileges\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "AC-6 (9)"
        ],
        "audit": "Execute the below command to verify that the directory is owned\nand group-owned by\nroot:\nstat -c %U:%G /etc/docker | grep -v root:root\nThe\nabove command should not return anything.\n",
        "fix": "chown root:root /etc/docker\nThis would set the ownership and\ngroup-ownership for the directory to root.\n",
        "Default Value": "By default, the ownership and group-ownership for this\ndirectory is correctly set to root.\n"
      },
      "code": "control \"M-3.5\" do\n  title \"3.5 Ensure that /etc/docker directory ownership is set to\nroot:root(Scored)\"\n  desc  \"\n    Verify that the /etc/docker directory ownership and group-ownership is\ncorrectly set to\n    root.\n    /etc/docker directory contains certificates and keys in addition to various\nsensitive files.\n    Hence, it should be owned and group-owned by root to maintain the integrity\nof the\n    directory.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://docs.docker.com/engine/security/https/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"3.5\"\n  tag \"cis_control\": \"5.1 Minimize And Sparingly Use Administrative\nPrivileges\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"AC-6 (9)\"]\n  tag \"audit\": \"Execute the below command to verify that the directory is owned\nand group-owned by\\nroot:\\nstat -c %U:%G /etc/docker | grep -v root:root\\nThe\nabove command should not return anything.\\n\"\n  tag \"fix\": \"chown root:root /etc/docker\\nThis would set the ownership and\ngroup-ownership for the directory to root.\\n\"\n  tag \"Default Value\": \"By default, the ownership and group-ownership for this\ndirectory is correctly set to root.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-3.5.rb",
        "line": 1
      },
      "id": "M-3.5"
    },
    {
      "title": "3.6 Ensure that /etc/docker directory permissions are set to 755 or\nmore\nrestrictive (Scored)",
      "desc": "Verify that the /etc/docker directory permissions are correctly set to 755\nor more\n    restrictive.\n    /etc/docker directory contains certificates and keys in addition to various\nsensitive files.\n    Hence, it should only be writable by root to maintain the integrity of the\ndirectory.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://docs.docker.com/engine/security/https/\n",
        "severity": "medium",
        "cis_id": "3.6",
        "cis_control": "14.4 Protect Information With Access Control Lists\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "AC-3 (3)"
        ],
        "audit": "Execute the below command to verify that the directory has\npermissions of 755 or more\nrestrictive:\nstat -c %a /etc/docker\n",
        "fix": "chmod 755 /etc/docker\nThis would set the permissions for the\ndirectory to 755.\n",
        "Default Value": "By default, the permissions for this directory are\ncorrectly set to 755.\n"
      },
      "code": "control \"M-3.6\" do\n  title \"3.6 Ensure that /etc/docker directory permissions are set to 755 or\nmore\\nrestrictive (Scored)\"\n  desc  \"\n    Verify that the /etc/docker directory permissions are correctly set to 755\nor more\n    restrictive.\n    /etc/docker directory contains certificates and keys in addition to various\nsensitive files.\n    Hence, it should only be writable by root to maintain the integrity of the\ndirectory.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://docs.docker.com/engine/security/https/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"3.6\"\n  tag \"cis_control\": \"14.4 Protect Information With Access Control Lists\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"AC-3 (3)\"]\n  tag \"audit\": \"Execute the below command to verify that the directory has\npermissions of 755 or more\\nrestrictive:\\nstat -c %a /etc/docker\\n\"\n  tag \"fix\": \"chmod 755 /etc/docker\\nThis would set the permissions for the\ndirectory to 755.\\n\"\n  tag \"Default Value\": \"By default, the permissions for this directory are\ncorrectly set to 755.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-3.6.rb",
        "line": 1
      },
      "id": "M-3.6"
    },
    {
      "title": "3.7 Ensure that registry certificate file ownership is set to\nroot:root(Scored)",
      "desc": "Verify that all the registry certificate files (usually found under\n    /etc/docker/certs.d/<registry-name> directory) are owned and group-owned by\nroot.\n    /etc/docker/certs.d/<registry-name> directory contains Docker registry\ncertificates.\n    These certificate files must be owned and group-owned by root to maintain\nthe integrity of\n    the certificates.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://docs.docker.com/registry/insecure/\n",
        "severity": "medium",
        "cis_id": "3.7",
        "cis_control": "5.1 Minimize And Sparingly Use Administrative\nPrivileges\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "AC-6 (9)"
        ],
        "audit": "Execute the below command to verify that the registry\ncertificate files are owned and\ngroup-owned by root:\nstat -c %U:%G\n/etc/docker/certs.d/* | grep -v root:root\nThe above command should not return\nanything.\n",
        "fix": "chown root:root /etc/docker/certs.d/<registry-name>/*\nThis would\nset the ownership and group-ownership for the registry certificate files to\nroot.\n",
        "Default Value": "By default, the ownership and group-ownership for\nregistry certificate files is correctly set\nto root.\n"
      },
      "code": "control \"M-3.7\" do\n  title \"3.7 Ensure that registry certificate file ownership is set to\nroot:root(Scored)\"\n  desc  \"\n    Verify that all the registry certificate files (usually found under\n    /etc/docker/certs.d/<registry-name> directory) are owned and group-owned by\nroot.\n    /etc/docker/certs.d/<registry-name> directory contains Docker registry\ncertificates.\n    These certificate files must be owned and group-owned by root to maintain\nthe integrity of\n    the certificates.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://docs.docker.com/registry/insecure/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"3.7\"\n  tag \"cis_control\": \"5.1 Minimize And Sparingly Use Administrative\nPrivileges\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"AC-6 (9)\"]\n  tag \"audit\": \"Execute the below command to verify that the registry\ncertificate files are owned and\\ngroup-owned by root:\\nstat -c %U:%G\n/etc/docker/certs.d/* | grep -v root:root\\nThe above command should not return\nanything.\\n\"\n  tag \"fix\": \"chown root:root /etc/docker/certs.d/<registry-name>/*\\nThis would\nset the ownership and group-ownership for the registry certificate files to\nroot.\\n\"\n  tag \"Default Value\": \"By default, the ownership and group-ownership for\nregistry certificate files is correctly set\\nto root.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-3.7.rb",
        "line": 1
      },
      "id": "M-3.7"
    },
    {
      "title": "3.8 Ensure that registry certificate file permissions are set to 444\nor\nmore restrictive (Scored)",
      "desc": "Verify that all the registry certificate files (usually found under\n    /etc/docker/certs.d/<registry-name> directory) have permissions of 444 or\nmore\n    restrictive.\n    /etc/docker/certs.d/<registry-name> directory contains Docker registry\ncertificates.\n    These certificate files must have permissions of 444 to maintain the\nintegrity of the\n    certificates.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://docs.docker.com/registry/insecure/\n",
        "severity": "medium",
        "cis_id": "3.8",
        "cis_control": "14.4 Protect Information With Access Control Lists\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "AC-3 (3)"
        ],
        "audit": "Execute the below command to verify that the registry\ncertificate files have permissions of\n444 or more restrictive:\nstat -c %a\n/etc/docker/certs.d/<registry-name>/*\n",
        "fix": "chmod 444 /etc/docker/certs.d/<registry-name>/*\nThis would set\nthe permissions for registry certificate files to 444.\n",
        "Default Value": "By default, the permissions for registry certificate\nfiles might not be 444. The default file\npermissions are governed by the\nsystem or user specific umaskvalues.\n"
      },
      "code": "control \"M-3.8\" do\n  title \"3.8 Ensure that registry certificate file permissions are set to 444\nor\\nmore restrictive (Scored)\"\n  desc  \"\n    Verify that all the registry certificate files (usually found under\n    /etc/docker/certs.d/<registry-name> directory) have permissions of 444 or\nmore\n    restrictive.\n    /etc/docker/certs.d/<registry-name> directory contains Docker registry\ncertificates.\n    These certificate files must have permissions of 444 to maintain the\nintegrity of the\n    certificates.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://docs.docker.com/registry/insecure/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"3.8\"\n  tag \"cis_control\": \"14.4 Protect Information With Access Control Lists\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"AC-3 (3)\"]\n  tag \"audit\": \"Execute the below command to verify that the registry\ncertificate files have permissions of\\n444 or more restrictive:\\nstat -c %a\n/etc/docker/certs.d/<registry-name>/*\\n\"\n  tag \"fix\": \"chmod 444 /etc/docker/certs.d/<registry-name>/*\\nThis would set\nthe permissions for registry certificate files to 444.\\n\"\n  tag \"Default Value\": \"By default, the permissions for registry certificate\nfiles might not be 444. The default file\\npermissions are governed by the\nsystem or user specific umaskvalues.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-3.8.rb",
        "line": 1
      },
      "id": "M-3.8"
    },
    {
      "title": "3.9 Ensure that TLS CA certificate file ownership is set to\nroot:root(Scored)",
      "desc": "Verify that the TLS CA certificate file (the file that is passed alongwith\n--tlscacert\n    parameter) is owned and group-owned by root.\n    The TLS CA certificate file should be protected from any tampering. It is\nused to\n    authenticate Docker server based on given CA certificate. Hence, it must be\nowned and\n    group-owned by root to maintain the integrity of the CA certificate.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://docs.docker.com/registry/insecure/\n2.\nhttps://docs.docker.com/engine/security/https/\n",
        "severity": "medium",
        "cis_id": "3.9",
        "cis_control": "5.1 Minimize And Sparingly Use Administrative\nPrivileges\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "AC-6 (9)"
        ],
        "audit": "Execute the below command to verify that the TLS CA certificate\nfile is owned and groupowned by root:\nstat -c %U:%G <path to TLS CA\ncertificate file> | grep -v root:root\nThe above command should not return\nanything.\n",
        "fix": "chown root:root <path to TLS CA certificate file>\nThis would set\nthe ownership and group-ownership for the TLS CA certificate file to root.\n",
        "Default Value": "By default, the ownership and group-ownership for TLS\nCA certificate file is correctly set to\nroot.\n"
      },
      "code": "control \"M-3.9\" do\n  title \"3.9 Ensure that TLS CA certificate file ownership is set to\nroot:root(Scored)\"\n  desc  \"\n    Verify that the TLS CA certificate file (the file that is passed alongwith\n--tlscacert\n    parameter) is owned and group-owned by root.\n    The TLS CA certificate file should be protected from any tampering. It is\nused to\n    authenticate Docker server based on given CA certificate. Hence, it must be\nowned and\n    group-owned by root to maintain the integrity of the CA certificate.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://docs.docker.com/registry/insecure/\\n2.\nhttps://docs.docker.com/engine/security/https/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"3.9\"\n  tag \"cis_control\": \"5.1 Minimize And Sparingly Use Administrative\nPrivileges\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"AC-6 (9)\"]\n  tag \"audit\": \"Execute the below command to verify that the TLS CA certificate\nfile is owned and groupowned by root:\\nstat -c %U:%G <path to TLS CA\ncertificate file> | grep -v root:root\\nThe above command should not return\nanything.\\n\"\n  tag \"fix\": \"chown root:root <path to TLS CA certificate file>\\nThis would set\nthe ownership and group-ownership for the TLS CA certificate file to root.\\n\"\n  tag \"Default Value\": \"By default, the ownership and group-ownership for TLS\nCA certificate file is correctly set to\\nroot.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-3.9.rb",
        "line": 1
      },
      "id": "M-3.9"
    },
    {
      "title": "4.1 Ensure a user for the container has been created (Scored)",
      "desc": "Create a non-root user for the container in the Dockerfile for the\ncontainer image.\n    It is a good practice to run the container as a non-root user, if possible.\nThough user\n    namespace mapping is now available, if a user is already defined in the\ncontainer image, the\n    container is run as that user by default and specific user namespace\nremapping is not\n    required.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://github.com/docker/docker/issues/2918\n2.\nhttps://github.com/docker/docker/pull/4572\n3.\nhttps://github.com/docker/docker/issues/7906\n",
        "severity": "medium",
        "cis_id": "4.1",
        "cis_control": "5.1 Minimize And Sparingly Use Administrative\nPrivileges\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "AC-6 (9)"
        ],
        "audit": "docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}: User={{\n.Config.User }}'\nThe above command should return container\nusername or user ID. If it is blank it means,\nthe container is running as\nroot.\n",
        "fix": "Ensure that the Dockerfile for the container image contains below\ninstruction:\nUSER <username or ID>\nwhere username or ID refers to the user\nthat could be found in the container base image. If\nthere is no specific user\ncreated in the container base image, then add a useradd command\nto add the\nspecific user before USER instruction.\nFor example, add the below lines in the\nDockerfile to create a user in the container:\nRUN useradd -d /home/username -m\n-s /bin/bash username\nUSER username\nNote: If there are users in the image\nthat the containers do not need, consider deleting\nthem. After deleting those\nusers, commit the image and then generate new instances of\ncontainers for\nuse.\n",
        "Default Value": "By default, the containers are run with rootprivileges\nand as user rootinside the container.\n"
      },
      "code": "control \"M-4.1\" do\n  title \"4.1 Ensure a user for the container has been created (Scored)\"\n  desc  \"\n    Create a non-root user for the container in the Dockerfile for the\ncontainer image.\n    It is a good practice to run the container as a non-root user, if possible.\nThough user\n    namespace mapping is now available, if a user is already defined in the\ncontainer image, the\n    container is run as that user by default and specific user namespace\nremapping is not\n    required.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://github.com/docker/docker/issues/2918\\n2.\nhttps://github.com/docker/docker/pull/4572\\n3.\nhttps://github.com/docker/docker/issues/7906\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"4.1\"\n  tag \"cis_control\": \"5.1 Minimize And Sparingly Use Administrative\nPrivileges\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"AC-6 (9)\"]\n  tag \"audit\": \"docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}: User={{\\n.Config.User }}'\\nThe above command should return container\nusername or user ID. If it is blank it means,\\nthe container is running as\nroot.\\n\"\n  tag \"fix\": \"Ensure that the Dockerfile for the container image contains below\ninstruction:\\nUSER <username or ID>\\nwhere username or ID refers to the user\nthat could be found in the container base image. If\\nthere is no specific user\ncreated in the container base image, then add a useradd command\\nto add the\nspecific user before USER instruction.\\nFor example, add the below lines in the\nDockerfile to create a user in the container:\\nRUN useradd -d /home/username -m\n-s /bin/bash username\\nUSER username\\nNote: If there are users in the image\nthat the containers do not need, consider deleting\\nthem. After deleting those\nusers, commit the image and then generate new instances of\\ncontainers for\nuse.\\n\"\n  tag \"Default Value\": \"By default, the containers are run with rootprivileges\nand as user rootinside the container.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-4.1.rb",
        "line": 1
      },
      "id": "M-4.1"
    },
    {
      "title": "4.10 Ensure secrets are not stored in Dockerfiles (Not Scored)",
      "desc": "Do not store any secrets in Dockerfiles.\n    Dockerfiles could be backtracked easily by using native Docker commands\nsuch as docker\n    history and various tools and utilities. Also, as a general practice, image\npublishers\n    provide Dockerfiles to build the credibility for their images. Hence, the\nsecrets within these\n    Dockerfiles could be easily exposed and potentially be exploited.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://github.com/docker/docker/issues/13490\n2.\nhttp://12factor.net/config\n3.\nhttps://avicoder.me/2016/07/22/Twitter-Vine-Source-code-dump/\n",
        "severity": "medium",
        "cis_id": "4.10",
        "cis_control": "14 Controlled Access Based on the Need to Know\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "AC-6"
        ],
        "audit": "Step 1: Run the below command to get the list of\nimages:\ndocker images\nStep 2: Run the below command for each image in the\nlist above, and look for any secrets:\ndocker history\n<Image_ID>\nAlternatively, if you have access to Dockerfile for the image,\nverify that there are no secrets\nas described above.\n",
        "fix": "Do not store any kind of secrets within Dockerfiles.\n",
        "Default Value": "By default, there are no restrictions on storing config\nsecrets in the Dockerfiles.\n"
      },
      "code": "control \"M-4.10\" do\n  title \"4.10 Ensure secrets are not stored in Dockerfiles (Not Scored)\"\n  desc  \"\n    Do not store any secrets in Dockerfiles.\n    Dockerfiles could be backtracked easily by using native Docker commands\nsuch as docker\n    history and various tools and utilities. Also, as a general practice, image\npublishers\n    provide Dockerfiles to build the credibility for their images. Hence, the\nsecrets within these\n    Dockerfiles could be easily exposed and potentially be exploited.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://github.com/docker/docker/issues/13490\\n2.\nhttp://12factor.net/config\\n3.\nhttps://avicoder.me/2016/07/22/Twitter-Vine-Source-code-dump/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"4.10\"\n  tag \"cis_control\": \"14 Controlled Access Based on the Need to Know\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"AC-6\"]\n  tag \"audit\": \"Step 1: Run the below command to get the list of\nimages:\\ndocker images\\nStep 2: Run the below command for each image in the\nlist above, and look for any secrets:\\ndocker history\n<Image_ID>\\nAlternatively, if you have access to Dockerfile for the image,\nverify that there are no secrets\\nas described above.\\n\"\n  tag \"fix\": \"Do not store any kind of secrets within Dockerfiles.\\n\"\n  tag \"Default Value\": \"By default, there are no restrictions on storing config\nsecrets in the Dockerfiles.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-4.10.rb",
        "line": 1
      },
      "id": "M-4.10"
    },
    {
      "title": "4.11 Ensure verified packages are only Installed (Not Scored)",
      "desc": "Verify authenticity of the packages before installing them in the image.\n    Verifying authenticity of the packages is essential for building a secure\ncontainer image.\n    Tampered packages could potentially be malicious or have some known\nvulnerabilities that\n    could be exploited.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttp://www.oreilly.com/webops-perf/free/files/docker-security.pdf\n2.\nhttps://github.com/dockerlibrary/httpd/blob/12bf8c8883340c98b3988a7bade8ef2d0d6dcf8a/2.4/Dockerfil\ne\n3.\nhttps://github.com/dockerlibrary/php/blob/d8a4ccf4d620ec866d5b42335b699742df08c5f0/7.0/alpine/Doc\nkerfile\n4.\nhttps://access.redhat.com/security/team/key\n",
        "severity": "medium",
        "cis_id": "4.11",
        "cis_control": "18.1 Use Only Vendor-supported Software\n",
        "cis_level": "Level 2 - Docker",
        "nist": [
          "SI-2"
        ],
        "audit": "Step 1: Run the below command to get the list of\nimages:\ndocker images\nStep 2: Run the below command for each image in the\nlist above, and look for how the\nauthenticity of the packages is determined.\nThis could be via the use of GPG keys or other\nsecure package distribution\nmechanisms\ndocker history <Image_ID>\nAlternatively, if you have access to\nDockerfile for the image, verify that the authenticity of\nthe packages is\nchecked.\n",
        "fix": "Use GPG keys for downloading and verifying packages or any other\nsecure package\ndistribution mechanism of your choice.\n",
        "Default Value": "Not Applicable\n"
      },
      "code": "control \"M-4.11\" do\n  title \"4.11 Ensure verified packages are only Installed (Not Scored)\"\n  desc  \"\n    Verify authenticity of the packages before installing them in the image.\n    Verifying authenticity of the packages is essential for building a secure\ncontainer image.\n    Tampered packages could potentially be malicious or have some known\nvulnerabilities that\n    could be exploited.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttp://www.oreilly.com/webops-perf/free/files/docker-security.pdf\\n2.\nhttps://github.com/dockerlibrary/httpd/blob/12bf8c8883340c98b3988a7bade8ef2d0d6dcf8a/2.4/Dockerfil\\ne\\n3.\nhttps://github.com/dockerlibrary/php/blob/d8a4ccf4d620ec866d5b42335b699742df08c5f0/7.0/alpine/Doc\\nkerfile\\n4.\nhttps://access.redhat.com/security/team/key\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"4.11\"\n  tag \"cis_control\": \"18.1 Use Only Vendor-supported Software\\n\"\n  tag \"cis_level\": \"Level 2 - Docker\"\n  tag \"nist\": [\"SI-2\"]\n  tag \"audit\": \"Step 1: Run the below command to get the list of\nimages:\\ndocker images\\nStep 2: Run the below command for each image in the\nlist above, and look for how the\\nauthenticity of the packages is determined.\nThis could be via the use of GPG keys or other\\nsecure package distribution\nmechanisms\\ndocker history <Image_ID>\\nAlternatively, if you have access to\nDockerfile for the image, verify that the authenticity of\\nthe packages is\nchecked.\\n\"\n  tag \"fix\": \"Use GPG keys for downloading and verifying packages or any other\nsecure package\\ndistribution mechanism of your choice.\\n\"\n  tag \"Default Value\": \"Not Applicable\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-4.11.rb",
        "line": 1
      },
      "id": "M-4.11"
    },
    {
      "title": "4.2 Ensure that containers use trusted base images (Not Scored)",
      "desc": "Ensure that the container image is written either from scratch or is based\non another\n    established and trusted base image downloaded over a secure channel.\n    Official repositories are Docker images curated and optimized by the Docker\ncommunity or\n    the vendor. There could be other potentially unsafe public repositories.\nCaution should be\n    exercised when obtaining container images from Docker and third parties to\nhow they will\n    be used for your organization's data.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://titanous.com/posts/docker-insecurity\n2.\nhttps://registry.hub.docker.com/\n3.\nhttp://blog.docker.com/2014/10/docker-1-3-signed-images-process-injectionsecurity-options-mac-shared-directories/\n4.\nhttps://github.com/docker/docker/issues/8093\n5.\nhttps://docs.docker.com/engine/reference/commandline/pull/\n6.\nhttps://github.com/docker/docker/pull/11109\n7.\nhttps://blog.docker.com/2015/11/docker-trusted-registry-1-4/\n",
        "severity": "medium",
        "cis_id": "4.2",
        "cis_control": "3 Secure Configurations for Hardware and Software on\nMobile Devices, Laptops,\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "CM-6"
        ],
        "audit": "Step 1 - Inspect the Docker host for Docker images used by\nexecuting the below command:\ndocker images\nThis would list all the container\nimages that are currently available for use on the Docker\nhost. Interview the\nsystem administrator and obtain a proof of evidence that the list of\nimages\nwas obtained from trusted source over a secure channel or from a trusted,\nsecure\nprivate Docker registry.\nStep 2 - For each Docker image found on the\nDocker host, inspect the image for how it was\nbuilt to verify if from trusted\nsources and hardened configuration:\ndocker history <imageName>\n",
        "fix": "\n\n\nConfigure and use Docker Content trust.\nInspect Docker\nimage history to evaluate their risk to operate on your network.\nScan Docker\nimages for vulnerabilities in their dependencies and configurations\nthey will\nimpose upon your network.\n",
        "Default Value": "Not Applicable.\n"
      },
      "code": "control \"M-4.2\" do\n  title \"4.2 Ensure that containers use trusted base images (Not Scored)\"\n  desc  \"\n    Ensure that the container image is written either from scratch or is based\non another\n    established and trusted base image downloaded over a secure channel.\n    Official repositories are Docker images curated and optimized by the Docker\ncommunity or\n    the vendor. There could be other potentially unsafe public repositories.\nCaution should be\n    exercised when obtaining container images from Docker and third parties to\nhow they will\n    be used for your organization's data.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://titanous.com/posts/docker-insecurity\\n2.\nhttps://registry.hub.docker.com/\\n3.\nhttp://blog.docker.com/2014/10/docker-1-3-signed-images-process-injectionsecurity-options-mac-shared-directories/\\n4.\nhttps://github.com/docker/docker/issues/8093\\n5.\nhttps://docs.docker.com/engine/reference/commandline/pull/\\n6.\nhttps://github.com/docker/docker/pull/11109\\n7.\nhttps://blog.docker.com/2015/11/docker-trusted-registry-1-4/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"4.2\"\n  tag \"cis_control\": \"3 Secure Configurations for Hardware and Software on\nMobile Devices, Laptops,\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"CM-6\"]\n  tag \"audit\": \"Step 1 - Inspect the Docker host for Docker images used by\nexecuting the below command:\\ndocker images\\nThis would list all the container\nimages that are currently available for use on the Docker\\nhost. Interview the\nsystem administrator and obtain a proof of evidence that the list of\\nimages\nwas obtained from trusted source over a secure channel or from a trusted,\nsecure\\nprivate Docker registry.\\nStep 2 - For each Docker image found on the\nDocker host, inspect the image for how it was\\nbuilt to verify if from trusted\nsources and hardened configuration:\\ndocker history <imageName>\\n\"\n  tag \"fix\": \"\\n\\n\\nConfigure and use Docker Content trust.\\nInspect Docker\nimage history to evaluate their risk to operate on your network.\\nScan Docker\nimages for vulnerabilities in their dependencies and configurations\\nthey will\nimpose upon your network.\\n\"\n  tag \"Default Value\": \"Not Applicable.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-4.2.rb",
        "line": 1
      },
      "id": "M-4.2"
    },
    {
      "title": "4.3 Ensure unnecessary packages are not installed in the container\n(Not\nScored)",
      "desc": "Containers tend to be minimal and slim down versions of the Operating\nSystem. Do not\n    install anything that does not justify the purpose of container.\n    Bloating containers with unnecessary software could possibly increase the\nattack surface\n    of the container. This also voids the concept of minimal and slim down\nversions of\n    container images. Hence, do not install anything else apart from what is\ntruly needed for\n    the purpose of the container.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://docs.docker.com/userguide/dockerimages/\n2.\nhttp://www.livewyer.com/blog/2015/02/24/slimming-down-your-dockercontainers-alpine-linux\n3.\nhttps://github.com/progrium/busybox\n",
        "severity": "medium",
        "cis_id": "4.3",
        "cis_control": "18 Application Software Security\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "SI-1"
        ],
        "audit": "Step 1: List all the running instances of containers by\nexecuting below command:\ndocker ps --quiet\nStep 2: For each container\ninstance, execute the below or equivalent command:\ndocker exec $INSTANCE_ID\nrpm -qa\nThe above command would list the packages installed on the container.\nReview the list and\nensure that it is legitimate.\n",
        "fix": "At the outset, do not install anything on the container that does\nnot justify the purpose. If\nthe image had some packages that your container\ndoes not use, uninstall them.\nConsider using a minimal base image rather than\nthe standard Redhat/Centos/Debian\nimages if you can. Some of the options\ninclude BusyBox and Alpine.\nNot only does this trim your image size from\n>150Mb to ~20 Mb, there are also fewer tools\nand paths to escalate privileges.\nYou can even remove the package installer as a final\nhardening measure for\nleaf/production containers.\n",
        "Default Value": "Not Applicable.\n"
      },
      "code": "control \"M-4.3\" do\n  title \"4.3 Ensure unnecessary packages are not installed in the container\n(Not\\nScored)\"\n  desc  \"\n    Containers tend to be minimal and slim down versions of the Operating\nSystem. Do not\n    install anything that does not justify the purpose of container.\n    Bloating containers with unnecessary software could possibly increase the\nattack surface\n    of the container. This also voids the concept of minimal and slim down\nversions of\n    container images. Hence, do not install anything else apart from what is\ntruly needed for\n    the purpose of the container.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://docs.docker.com/userguide/dockerimages/\\n2.\nhttp://www.livewyer.com/blog/2015/02/24/slimming-down-your-dockercontainers-alpine-linux\\n3.\nhttps://github.com/progrium/busybox\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"4.3\"\n  tag \"cis_control\": \"18 Application Software Security\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"SI-1\"]\n  tag \"audit\": \"Step 1: List all the running instances of containers by\nexecuting below command:\\ndocker ps --quiet\\nStep 2: For each container\ninstance, execute the below or equivalent command:\\ndocker exec $INSTANCE_ID\nrpm -qa\\nThe above command would list the packages installed on the container.\nReview the list and\\nensure that it is legitimate.\\n\"\n  tag \"fix\": \"At the outset, do not install anything on the container that does\nnot justify the purpose. If\\nthe image had some packages that your container\ndoes not use, uninstall them.\\nConsider using a minimal base image rather than\nthe standard Redhat/Centos/Debian\\nimages if you can. Some of the options\ninclude BusyBox and Alpine.\\nNot only does this trim your image size from\n>150Mb to ~20 Mb, there are also fewer tools\\nand paths to escalate privileges.\nYou can even remove the package installer as a final\\nhardening measure for\nleaf/production containers.\\n\"\n  tag \"Default Value\": \"Not Applicable.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-4.3.rb",
        "line": 1
      },
      "id": "M-4.3"
    },
    {
      "title": "4.4 Ensure images are scanned and rebuilt to include security\npatches(Not Scored)",
      "desc": "Images should be scanned \"frequently\" for any vulnerabilities. Rebuild\nthe images to\n    include patches and then instantiate new containers from it.\n    Vulnerabilities are loopholes/bugs that can be exploited and security\npatches are updates\n    to resolve these vulnerabilities. We can use image vulnerability scanning\ntools to find any\n    kind of vulnerabilities within the images and then check for available\npatches to mitigate\n    these vulnerabilities. Patches update the system to the most recent code\nbase. Being on the\n    current code base is important because that's where vendors focus on fixing\nproblems.\n    Evaluate the security patches before applying and follow the patching best\npractices.\n    Also, it would be better if, image vulnerability scanning tools could\nperform binary level\n    analysis or hash based verification instead of just version string matching.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\n2.\n3.\n4.\nhttps://docs.docker.com/userguide/dockerimages/\nhttps://docs.docker.com/docker-cloud/builds/image-scan/\nhttps://blog.docker.com/2016/05/docker-security-scanning/\nhttps://docs.docker.com/engine/reference/builder/#/onbuild\n",
        "severity": "medium",
        "cis_id": "4.4",
        "cis_control": "18.1 Use Only Vendor-supported Software\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "SI-2"
        ],
        "audit": "Step 1: List all the running instances of containers by\nexecuting below command:\ndocker ps --quiet\nStep 2: For each container\ninstance, execute the below or equivalent command to find the\nlist of packages\ninstalled within the container. Ensure that the security updates for\nvarious\naffected packages are installed.\ndocker exec $INSTANCE_ID rpm\n-qa\nAlternatively, you could run image vulnerability scanning tools which can\nscan all the\nimages in your ecosystem and then apply patches for the detected\nvulnerabilities based on\nyour patch management procedures.\n",
        "fix": "Follow the below steps to rebuild the images with security\npatches:\nStep 1: Pull all the base images (i.e., given your set of\nDockerfiles, extract all images\ndeclared in FROM instructions, and re-pull\nthem to check for an updated/patched versions).\nPatch the packages within the\nimages too.\ndocker pull\nStep 2: Force a rebuild of each image:\ndocker build\n--no-cache\nStep 3: Restart all containers with the updated images.\nYou could\nalso use ONBUILD directive in the Dockerfile to trigger particular\nupdate\ninstructions for images that you know are used as base images\nfrequently.\n",
        "Default Value": "By default, containers and images are not updated of\ntheir own.\n"
      },
      "code": "control \"M-4.4\" do\n  title \"4.4 Ensure images are scanned and rebuilt to include security\npatches(Not Scored)\"\n  desc  \"\n    Images should be scanned \\\"frequently\\\" for any vulnerabilities. Rebuild\nthe images to\n    include patches and then instantiate new containers from it.\n    Vulnerabilities are loopholes/bugs that can be exploited and security\npatches are updates\n    to resolve these vulnerabilities. We can use image vulnerability scanning\ntools to find any\n    kind of vulnerabilities within the images and then check for available\npatches to mitigate\n    these vulnerabilities. Patches update the system to the most recent code\nbase. Being on the\n    current code base is important because that's where vendors focus on fixing\nproblems.\n    Evaluate the security patches before applying and follow the patching best\npractices.\n    Also, it would be better if, image vulnerability scanning tools could\nperform binary level\n    analysis or hash based verification instead of just version string matching.\n\n  \"\n  impact 0.5\n  tag \"ref\":\n\"1.\\n2.\\n3.\\n4.\\nhttps://docs.docker.com/userguide/dockerimages/\\nhttps://docs.docker.com/docker-cloud/builds/image-scan/\\nhttps://blog.docker.com/2016/05/docker-security-scanning/\\nhttps://docs.docker.com/engine/reference/builder/#/onbuild\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"4.4\"\n  tag \"cis_control\": \"18.1 Use Only Vendor-supported Software\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"SI-2\"]\n  tag \"audit\": \"Step 1: List all the running instances of containers by\nexecuting below command:\\ndocker ps --quiet\\nStep 2: For each container\ninstance, execute the below or equivalent command to find the\\nlist of packages\ninstalled within the container. Ensure that the security updates for\nvarious\\naffected packages are installed.\\ndocker exec $INSTANCE_ID rpm\n-qa\\nAlternatively, you could run image vulnerability scanning tools which can\nscan all the\\nimages in your ecosystem and then apply patches for the detected\nvulnerabilities based on\\nyour patch management procedures.\\n\"\n  tag \"fix\": \"Follow the below steps to rebuild the images with security\npatches:\\nStep 1: Pull all the base images (i.e., given your set of\nDockerfiles, extract all images\\ndeclared in FROM instructions, and re-pull\nthem to check for an updated/patched versions).\\nPatch the packages within the\nimages too.\\ndocker pull\\nStep 2: Force a rebuild of each image:\\ndocker build\n--no-cache\\nStep 3: Restart all containers with the updated images.\\nYou could\nalso use ONBUILD directive in the Dockerfile to trigger particular\nupdate\\ninstructions for images that you know are used as base images\nfrequently.\\n\"\n  tag \"Default Value\": \"By default, containers and images are not updated of\ntheir own.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-4.4.rb",
        "line": 1
      },
      "id": "M-4.4"
    },
    {
      "title": "4.5 Ensure Content trust for Docker is Enabled (Scored)",
      "desc": "Content trust is disabled by default. You should enable it.\n    Content trust provides the ability to use digital signatures for data sent\nto and received\n    from remote Docker registries. These signatures allow client-side\nverification of the\n    integrity and publisher of specific image tags. This ensures provenance of\ncontainer images.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://docs.docker.com/engine/security/trust/content_trust/\n2.\nhttps://docs.docker.com/engine/reference/commandline/cli/#notary\n3.\nhttps://docs.docker.com/engine/reference/commandline/cli/#environmentvariables\n",
        "severity": "medium",
        "cis_id": "4.5",
        "cis_control": "18 Application Software Security\n",
        "cis_level": "Level 2 - Docker",
        "nist": [
          "SI-1"
        ],
        "audit": "echo $DOCKER_CONTENT_TRUST\nThis should return 1.\n",
        "fix": "To enable content trust in a bash shell, enter the following\ncommand:\nexport DOCKER_CONTENT_TRUST=1\nAlternatively, set this environment\nvariable in your profile file so that content trust in\nenabled on every\nlogin.\n",
        "Default Value": "By default, content trust is disabled.\n"
      },
      "code": "control \"M-4.5\" do\n  title \"4.5 Ensure Content trust for Docker is Enabled (Scored)\"\n  desc  \"\n    Content trust is disabled by default. You should enable it.\n    Content trust provides the ability to use digital signatures for data sent\nto and received\n    from remote Docker registries. These signatures allow client-side\nverification of the\n    integrity and publisher of specific image tags. This ensures provenance of\ncontainer images.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://docs.docker.com/engine/security/trust/content_trust/\\n2.\nhttps://docs.docker.com/engine/reference/commandline/cli/#notary\\n3.\nhttps://docs.docker.com/engine/reference/commandline/cli/#environmentvariables\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"4.5\"\n  tag \"cis_control\": \"18 Application Software Security\\n\"\n  tag \"cis_level\": \"Level 2 - Docker\"\n  tag \"nist\": [\"SI-1\"]\n  tag \"audit\": \"echo $DOCKER_CONTENT_TRUST\\nThis should return 1.\\n\"\n  tag \"fix\": \"To enable content trust in a bash shell, enter the following\ncommand:\\nexport DOCKER_CONTENT_TRUST=1\\nAlternatively, set this environment\nvariable in your profile file so that content trust in\\nenabled on every\nlogin.\\n\"\n  tag \"Default Value\": \"By default, content trust is disabled.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-4.5.rb",
        "line": 1
      },
      "id": "M-4.5"
    },
    {
      "title": "4.6 Ensure HEALTHCHECK instructions have been added to the\ncontainer\nimage (Scored)",
      "desc": "Add HEALTHCHECK instruction in your docker container images to perform the\nhealth check\n    on running containers.\n    One of the important security triads is availability. Adding HEALTHCHECK\ninstruction to your\n    container image ensures that the docker engine periodically checks the\nrunning container\n    instances against that instruction to ensure that the instances are still\nworking.\n    Based on the reported health status, the docker engine could then exit\nnon-working\n    containers and instantiate new ones.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://docs.docker.com/engine/reference/builder/#healthcheck\n",
        "severity": "medium",
        "cis_id": "4.6",
        "cis_control": "18 Application Software Security\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "SI-1"
        ],
        "audit": "Run the below command and ensure that the docker image has\nappropriate HEALTHCHECK\ninstruction set up.\ndocker inspect --format='{{\n.Config.Healthcheck }}' <IMAGE>\n",
        "fix": "Follow Docker documentation and rebuild your container image with\nHEALTHCHECK\ninstruction.\n",
        "Default Value": "By default, HEALTHCHECK is not set.\n"
      },
      "code": "control \"M-4.6\" do\n  title \"4.6 Ensure HEALTHCHECK instructions have been added to the\ncontainer\\nimage (Scored)\"\n  desc  \"\n    Add HEALTHCHECK instruction in your docker container images to perform the\nhealth check\n    on running containers.\n    One of the important security triads is availability. Adding HEALTHCHECK\ninstruction to your\n    container image ensures that the docker engine periodically checks the\nrunning container\n    instances against that instruction to ensure that the instances are still\nworking.\n    Based on the reported health status, the docker engine could then exit\nnon-working\n    containers and instantiate new ones.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://docs.docker.com/engine/reference/builder/#healthcheck\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"4.6\"\n  tag \"cis_control\": \"18 Application Software Security\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"SI-1\"]\n  tag \"audit\": \"Run the below command and ensure that the docker image has\nappropriate HEALTHCHECK\\ninstruction set up.\\ndocker inspect --format='{{\n.Config.Healthcheck }}' <IMAGE>\\n\"\n  tag \"fix\": \"Follow Docker documentation and rebuild your container image with\nHEALTHCHECK\\ninstruction.\\n\"\n  tag \"Default Value\": \"By default, HEALTHCHECK is not set.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-4.6.rb",
        "line": 1
      },
      "id": "M-4.6"
    },
    {
      "title": "4.7 Ensure update instructions are not use alone in the Dockerfile\n(Not\nScored)",
      "desc": "Do not use update instructions such as apt-get update alone or in a single\nline in the\n    Dockerfile.\n    Adding the update instructions in a single line on the Dockerfile will\ncache the update layer.\n    Thus, when you build any image later using the same instruction, previously\ncached update\n    layer will be used. This could potentially deny any fresh updates to go in\nthe later builds.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://docs.docker.com/engine/userguide/eng-image/dockerfile_bestpractices/#run\n2.\nhttps://github.com/docker/docker/issues/3313\n",
        "severity": "medium",
        "cis_id": "4.7",
        "cis_control": "18 Application Software Security\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "SI-1"
        ],
        "audit": "Step 1: Run the below command to get the list of\nimages:\ndocker images\nStep 2: Run the below command for each image in the\nlist above, and look for any update\ninstructions being in a single\nline:\ndocker history <Image_ID>\nAlternatively, if you have access to\nDockerfile for the image, verify that there are no update\ninstructions as\ndescribed above.\n",
        "fix": "Use update instructions along with install instructions (or any\nother) and version pinning\nfor packages while installing them. This would bust\nthe cache and force to extract the\nrequired versions.\nAlternatively, you\ncould use --no-cache flag during docker build process to avoid using\ncached\nlayers.\n",
        "Default Value": "By default, docker does not enforce any restrictions on\nusing update instructions.\n"
      },
      "code": "control \"M-4.7\" do\n  title \"4.7 Ensure update instructions are not use alone in the Dockerfile\n(Not\\nScored)\"\n  desc  \"\n    Do not use update instructions such as apt-get update alone or in a single\nline in the\n    Dockerfile.\n    Adding the update instructions in a single line on the Dockerfile will\ncache the update layer.\n    Thus, when you build any image later using the same instruction, previously\ncached update\n    layer will be used. This could potentially deny any fresh updates to go in\nthe later builds.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://docs.docker.com/engine/userguide/eng-image/dockerfile_bestpractices/#run\\n2.\nhttps://github.com/docker/docker/issues/3313\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"4.7\"\n  tag \"cis_control\": \"18 Application Software Security\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"SI-1\"]\n  tag \"audit\": \"Step 1: Run the below command to get the list of\nimages:\\ndocker images\\nStep 2: Run the below command for each image in the\nlist above, and look for any update\\ninstructions being in a single\nline:\\ndocker history <Image_ID>\\nAlternatively, if you have access to\nDockerfile for the image, verify that there are no update\\ninstructions as\ndescribed above.\\n\"\n  tag \"fix\": \"Use update instructions along with install instructions (or any\nother) and version pinning\\nfor packages while installing them. This would bust\nthe cache and force to extract the\\nrequired versions.\\nAlternatively, you\ncould use --no-cache flag during docker build process to avoid using\\ncached\nlayers.\\n\"\n  tag \"Default Value\": \"By default, docker does not enforce any restrictions on\nusing update instructions.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-4.7.rb",
        "line": 1
      },
      "id": "M-4.7"
    },
    {
      "title": "4.8 Ensure setuid and setgid permissions are removed in the images(Not\nScored)",
      "desc": "Removing setuid and setgid permissions in the images would prevent\nprivilege escalation\n    attacks in the containers.\n    setuid and setgid permissions could be used for elevating privileges. While\nthese\n    permissions are at times legitimately needed, these could potentially be\nused in privilege\n    escalation attacks. Thus, you should consider dropping these permissions\nfor the packages\n    which do not need them within the images.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttp://www.oreilly.com/webops-perf/free/files/docker-security.pdf\n2.\nhttp://containersolutions.com/content/uploads/2015/06/15.06.15_DockerCheatSheet_A2.pdf\n3.\nhttp://man7.org/linux/man-pages/man2/setuid.2.html\n4.\nhttp://man7.org/linux/man-pages/man2/setgid.2.html\n",
        "severity": "medium",
        "cis_id": "4.8",
        "cis_control": "5.1 Minimize And Sparingly Use Administrative\nPrivileges\n",
        "cis_level": "Level 2 - Docker",
        "nist": [
          "AC-6 (9)"
        ],
        "audit": "Run the below command on the image to list the executables\nhaving setuid and setgid\npermissions:\ndocker run <Image_ID> find / -perm\n+6000 -type f -exec ls -ld {} \\; 2>\n/dev/null\nCarefully, review the list and\nensure that it is legitimate.\n",
        "fix": "Allow setuid and setgid permissions only on executables which\nneed them. You could\nremove these permissions during build time by adding the\nfollowing command in your\nDockerfile, preferably towards the end of the\nDockerfile:\nRUN find / -perm +6000 -type f -exec chmod a-s {} \\; || true\n",
        "Default Value": "Not Applicable\n"
      },
      "code": "control \"M-4.8\" do\n  title \"4.8 Ensure setuid and setgid permissions are removed in the images(Not\nScored)\"\n  desc  \"\n    Removing setuid and setgid permissions in the images would prevent\nprivilege escalation\n    attacks in the containers.\n    setuid and setgid permissions could be used for elevating privileges. While\nthese\n    permissions are at times legitimately needed, these could potentially be\nused in privilege\n    escalation attacks. Thus, you should consider dropping these permissions\nfor the packages\n    which do not need them within the images.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttp://www.oreilly.com/webops-perf/free/files/docker-security.pdf\\n2.\nhttp://containersolutions.com/content/uploads/2015/06/15.06.15_DockerCheatSheet_A2.pdf\\n3.\nhttp://man7.org/linux/man-pages/man2/setuid.2.html\\n4.\nhttp://man7.org/linux/man-pages/man2/setgid.2.html\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"4.8\"\n  tag \"cis_control\": \"5.1 Minimize And Sparingly Use Administrative\nPrivileges\\n\"\n  tag \"cis_level\": \"Level 2 - Docker\"\n  tag \"nist\": [\"AC-6 (9)\"]\n  tag \"audit\": \"Run the below command on the image to list the executables\nhaving setuid and setgid\\npermissions:\\ndocker run <Image_ID> find / -perm\n+6000 -type f -exec ls -ld {} \\\\; 2>\\n/dev/null\\nCarefully, review the list and\nensure that it is legitimate.\\n\"\n  tag \"fix\": \"Allow setuid and setgid permissions only on executables which\nneed them. You could\\nremove these permissions during build time by adding the\nfollowing command in your\\nDockerfile, preferably towards the end of the\nDockerfile:\\nRUN find / -perm +6000 -type f -exec chmod a-s {} \\\\; || true\\n\"\n  tag \"Default Value\": \"Not Applicable\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-4.8.rb",
        "line": 1
      },
      "id": "M-4.8"
    },
    {
      "title": "4.9 Ensure COPY is used instead of ADD in Dockerfile (Not Scored)",
      "desc": "Use COPY instruction instead of ADD instruction in the Dockerfile.\n    COPY instruction just copies the files from the local host machine to the\ncontainer file\n    system. ADD instruction potentially could retrieve files from remote URLs\nand perform\n    operations such as unpacking. Thus, ADD instruction introduces risks such\nas adding\n    malicious files from URLs without scanning and unpacking procedure\nvulnerabilities.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://docs.docker.com/engine/userguide/eng-image/dockerfile_bestpractices/#add-or-copy\n",
        "severity": "medium",
        "cis_id": "4.9",
        "cis_control": "18 Application Software Security\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "SI-1"
        ],
        "audit": "Step 1: Run the below command to get the list of\nimages:\ndocker images\nStep 2: Run the below command for each image in the\nlist above and look for any ADD\ninstructions:\ndocker history\n<Image_ID>\nAlternatively, if you have access to Dockerfile for the image,\nverify that there are no ADD\ninstructions.\n",
        "fix": "Use COPY instructions in Dockerfiles.\n",
        "Default Value": "Not Applicable\n"
      },
      "code": "control \"M-4.9\" do\n  title \"4.9 Ensure COPY is used instead of ADD in Dockerfile (Not Scored)\"\n  desc  \"\n    Use COPY instruction instead of ADD instruction in the Dockerfile.\n    COPY instruction just copies the files from the local host machine to the\ncontainer file\n    system. ADD instruction potentially could retrieve files from remote URLs\nand perform\n    operations such as unpacking. Thus, ADD instruction introduces risks such\nas adding\n    malicious files from URLs without scanning and unpacking procedure\nvulnerabilities.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://docs.docker.com/engine/userguide/eng-image/dockerfile_bestpractices/#add-or-copy\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"4.9\"\n  tag \"cis_control\": \"18 Application Software Security\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"SI-1\"]\n  tag \"audit\": \"Step 1: Run the below command to get the list of\nimages:\\ndocker images\\nStep 2: Run the below command for each image in the\nlist above and look for any ADD\\ninstructions:\\ndocker history\n<Image_ID>\\nAlternatively, if you have access to Dockerfile for the image,\nverify that there are no ADD\\ninstructions.\\n\"\n  tag \"fix\": \"Use COPY instructions in Dockerfiles.\\n\"\n  tag \"Default Value\": \"Not Applicable\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-4.9.rb",
        "line": 1
      },
      "id": "M-4.9"
    },
    {
      "title": "5.1 Ensure AppArmor Profile is Enabled (Scored)",
      "desc": "AppArmor is an effective and easy-to-use Linux application security system.\nIt is available\n    on quite a few Linux distributions by default such as Debian and Ubuntu.\n    AppArmor protects the Linux OS and applications from various threats by\nenforcing\n    security policy which is also known as AppArmor profile. You can create\nyour own\n    AppArmor profile for containers or use the Docker's default AppArmor\nprofile. This would\n    enforce security policies on the containers as defined in the profile.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://docs.docker.com/engine/security/apparmor/\n2.\nhttps://docs.docker.com/engine/reference/run/#security-configuration\n3.\nhttps://docs.docker.com/engine/security/security/#other-kernel-security-features\n",
        "severity": "medium",
        "cis_id": "5.1",
        "cis_control": "14.4 Protect Information With Access Control Lists\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "AC-3 (3)"
        ],
        "audit": "docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}:\nAppArmorProfile={{ .AppArmorProfile }}'\nThe above command should return a\nvalid AppArmor Profile for each container instance.\n",
        "fix": "If AppArmor is applicable for your Linux OS, use it. You may have\nto follow below set of\nsteps:\n1.\n2.\n3.\n4.\nVerify if AppArmor is\ninstalled. If not, install it.\nCreate or import a AppArmor profile for Docker\ncontainers.\nPut this profile in enforcing mode.\nStart your Docker container\nusing the customized AppArmor profile. For example,\ndocker run --interactive\n--tty --security-opt=\"apparmor:PROFILENAME\" centos\n/bin/bash\nAlternatively,\nyou can keep the docker's default apparmor profile.\n",
        "Default Value": "By default, docker-default AppArmor profile is applied\nfor running containers and this\nprofile can be found at\n/etc/apparmor.d/docker.\n"
      },
      "code": "control \"M-5.1\" do\n  title \"5.1 Ensure AppArmor Profile is Enabled (Scored)\"\n  desc  \"\n    AppArmor is an effective and easy-to-use Linux application security system.\nIt is available\n    on quite a few Linux distributions by default such as Debian and Ubuntu.\n    AppArmor protects the Linux OS and applications from various threats by\nenforcing\n    security policy which is also known as AppArmor profile. You can create\nyour own\n    AppArmor profile for containers or use the Docker's default AppArmor\nprofile. This would\n    enforce security policies on the containers as defined in the profile.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://docs.docker.com/engine/security/apparmor/\\n2.\nhttps://docs.docker.com/engine/reference/run/#security-configuration\\n3.\nhttps://docs.docker.com/engine/security/security/#other-kernel-security-features\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"5.1\"\n  tag \"cis_control\": \"14.4 Protect Information With Access Control Lists\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"AC-3 (3)\"]\n  tag \"audit\": \"docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}:\\nAppArmorProfile={{ .AppArmorProfile }}'\\nThe above command should return a\nvalid AppArmor Profile for each container instance.\\n\"\n  tag \"fix\": \"If AppArmor is applicable for your Linux OS, use it. You may have\nto follow below set of\\nsteps:\\n1.\\n2.\\n3.\\n4.\\nVerify if AppArmor is\ninstalled. If not, install it.\\nCreate or import a AppArmor profile for Docker\ncontainers.\\nPut this profile in enforcing mode.\\nStart your Docker container\nusing the customized AppArmor profile. For example,\\ndocker run --interactive\n--tty --security-opt=\\\"apparmor:PROFILENAME\\\" centos\\n/bin/bash\\nAlternatively,\nyou can keep the docker's default apparmor profile.\\n\"\n  tag \"Default Value\": \"By default, docker-default AppArmor profile is applied\nfor running containers and this\\nprofile can be found at\n/etc/apparmor.d/docker.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-5.1.rb",
        "line": 1
      },
      "id": "M-5.1"
    },
    {
      "title": "5.10 Ensure memory usage for container is limited (Scored)",
      "desc": "By default, all containers on a Docker host share the resources equally. By\nusing the\n    resource management capabilities of Docker host, such as memory limit, you\ncan control\n    the amount of memory that a container may consume.\n    By default, container can use all of the memory on the host. You can use\nmemory limit\n    mechanism to prevent a denial of service arising from one container\nconsuming all of the\n    host’s resources such that other containers on the same host cannot perform\ntheir intended\n    functions. Having no limit on memory can lead to issues where one container\ncan easily\n    make the whole system unstable and as a result unusable.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://goldmann.pl/blog/2014/09/11/resource-management-in-docker/\n2.\nhttps://docs.docker.com/engine/reference/commandline/run/#options\n3.\nhttps://docs.docker.com/engine/admin/runmetrics/\n",
        "severity": "medium",
        "cis_id": "5.10",
        "cis_control": "18 Application Software Security\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "SI-1"
        ],
        "audit": "docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}: Memory={{\n.HostConfig.Memory }}'\nIf the above command returns 0, it means\nthe memory limits are not in place. If the above\ncommand returns a non-zero\nvalue, it means memory limits are in place.\n",
        "fix": "Run the container with only as much memory as required. Always\nrun the container using\nthe --memory argument.\nFor example, you could run a\ncontainer as below:\ndocker run --interactive --tty --memory 256m centos\n/bin/bash\nIn the above example, the container is started with a memory limit\nof 256 MB.\nNote: Please note that the output of the below command would return\nvalues in scientific\nnotation if memory limits are in place.\ndocker inspect\n--format='{{.Config.Memory}}' 7c5a2d4c7fe0\nFor example, if the memory limit is\nset to 256 MB for the above container instance, the\noutput of the above\ncommand would be 2.68435456e+08 and NOT 256m. You should\nconvert this value\nusing a scientific calculator or programmatic methods.\n",
        "Default Value": "By default, all containers on a Docker host share the\nresources equally. No memory limits\nare enforced.\n"
      },
      "code": "control \"M-5.10\" do\n  title \"5.10 Ensure memory usage for container is limited (Scored)\"\n  desc  \"\n    By default, all containers on a Docker host share the resources equally. By\nusing the\n    resource management capabilities of Docker host, such as memory limit, you\ncan control\n    the amount of memory that a container may consume.\n    By default, container can use all of the memory on the host. You can use\nmemory limit\n    mechanism to prevent a denial of service arising from one container\nconsuming all of the\n    host’s resources such that other containers on the same host cannot perform\ntheir intended\n    functions. Having no limit on memory can lead to issues where one container\ncan easily\n    make the whole system unstable and as a result unusable.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://goldmann.pl/blog/2014/09/11/resource-management-in-docker/\\n2.\nhttps://docs.docker.com/engine/reference/commandline/run/#options\\n3.\nhttps://docs.docker.com/engine/admin/runmetrics/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"5.10\"\n  tag \"cis_control\": \"18 Application Software Security\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"SI-1\"]\n  tag \"audit\": \"docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}: Memory={{\\n.HostConfig.Memory }}'\\nIf the above command returns 0, it means\nthe memory limits are not in place. If the above\\ncommand returns a non-zero\nvalue, it means memory limits are in place.\\n\"\n  tag \"fix\": \"Run the container with only as much memory as required. Always\nrun the container using\\nthe --memory argument.\\nFor example, you could run a\ncontainer as below:\\ndocker run --interactive --tty --memory 256m centos\n/bin/bash\\nIn the above example, the container is started with a memory limit\nof 256 MB.\\nNote: Please note that the output of the below command would return\nvalues in scientific\\nnotation if memory limits are in place.\\ndocker inspect\n--format='{{.Config.Memory}}' 7c5a2d4c7fe0\\nFor example, if the memory limit is\nset to 256 MB for the above container instance, the\\noutput of the above\ncommand would be 2.68435456e+08 and NOT 256m. You should\\nconvert this value\nusing a scientific calculator or programmatic methods.\\n\"\n  tag \"Default Value\": \"By default, all containers on a Docker host share the\nresources equally. No memory limits\\nare enforced.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-5.10.rb",
        "line": 1
      },
      "id": "M-5.10"
    },
    {
      "title": "5.11 Ensure CPU priority is set appropriately on the container\n(Scored)",
      "desc": "By default, all containers on a Docker host share the resources equally. By\nusing the\n    resource management capabilities of Docker host, such as CPU shares, you\ncan control the\n    host CPU resources that a container may consume.\n    By default, CPU time is divided between containers equally. If it is\ndesired, to control the\n    CPU time amongst the container instances, you can use CPU sharing feature.\nCPU sharing\n    allows to prioritize one container over the other and forbids the lower\npriority container to\n    claim CPU resources more often. This ensures that the high priority\ncontainers are served\n    better.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://goldmann.pl/blog/2014/09/11/resource-management-in-docker/\n2.\nhttps://docs.docker.com/engine/reference/commandline/run/#options\n3.\nhttps://docs.docker.com/engine/admin/runmetrics/\n",
        "severity": "medium",
        "cis_id": "5.11",
        "cis_control": "18 Application Software Security\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "SI-1"
        ],
        "audit": "docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}:\nCpuShares={{ .HostConfig.CpuShares }}'\nIf the above command returns 0 or\n1024, it means the CPU shares are not in place. If the\nabove command returns a\nnon-zero value other than 1024, it means CPU shares are in\nplace.\n",
        "fix": "Manage the CPU shares between your containers. To do so start the\ncontainer using the -cpu-shares argument.\nFor example, you could run a\ncontainer as below:\ndocker run --interactive --tty --cpu-shares 512 centos\n/bin/bash\nIn the above example, the container is started with CPU shares of\n50% of what the other\ncontainers use. So, if the other container has CPU\nshares of 80%, this container will have\nCPU shares of 40%.\nNote: Every new\ncontainer will have 1024 shares of CPU by default. However, this value\nis\nshown as 0 if you run the command mentioned in the audit\nsection.\nAlternatively,\n1. Navigate to /sys/fs/cgroup/cpu/system.slice/\ndirectory.\n2. Check your container instance ID using docker ps.\n3. Now,\ninside the above directory (in step 1), you would have a directory by\nname\ndocker-<Instance ID>.scope. For example,\ndocker4acae729e8659c6be696ee35b2237cc1fe4edd2672e9186434c5116e1a6fbed6.scope.\nNavigate\nto this directory.\n4. You will find a file named cpu.shares. Execute cat\ncpu.shares. This will always\ngive you the CPU share value based on the system.\nSo, even if there is no CPU shares\nconfigured using -c or --cpu-shares\nargument in the docker run command, this\nfile will have a value of 1024.\nIf\nwe set one container’s CPU shares to 512 it will receive half of the CPU time\ncompared to\nthe other container. So, take 1024 as 100% and then do quick math\nto derive the number\nthat you should set for respective CPU shares. For\nexample, use 512 if you want to set 50%\nand 256 if you want to set 25%.\n",
        "Default Value": "By default, all containers on a Docker host share the\nresources equally. No CPU shares are\nenforced.\n"
      },
      "code": "control \"M-5.11\" do\n  title \"5.11 Ensure CPU priority is set appropriately on the container\n(Scored)\"\n  desc  \"\n    By default, all containers on a Docker host share the resources equally. By\nusing the\n    resource management capabilities of Docker host, such as CPU shares, you\ncan control the\n    host CPU resources that a container may consume.\n    By default, CPU time is divided between containers equally. If it is\ndesired, to control the\n    CPU time amongst the container instances, you can use CPU sharing feature.\nCPU sharing\n    allows to prioritize one container over the other and forbids the lower\npriority container to\n    claim CPU resources more often. This ensures that the high priority\ncontainers are served\n    better.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://goldmann.pl/blog/2014/09/11/resource-management-in-docker/\\n2.\nhttps://docs.docker.com/engine/reference/commandline/run/#options\\n3.\nhttps://docs.docker.com/engine/admin/runmetrics/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"5.11\"\n  tag \"cis_control\": \"18 Application Software Security\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"SI-1\"]\n  tag \"audit\": \"docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}:\\nCpuShares={{ .HostConfig.CpuShares }}'\\nIf the above command returns 0 or\n1024, it means the CPU shares are not in place. If the\\nabove command returns a\nnon-zero value other than 1024, it means CPU shares are in\\nplace.\\n\"\n  tag \"fix\": \"Manage the CPU shares between your containers. To do so start the\ncontainer using the -cpu-shares argument.\\nFor example, you could run a\ncontainer as below:\\ndocker run --interactive --tty --cpu-shares 512 centos\n/bin/bash\\nIn the above example, the container is started with CPU shares of\n50% of what the other\\ncontainers use. So, if the other container has CPU\nshares of 80%, this container will have\\nCPU shares of 40%.\\nNote: Every new\ncontainer will have 1024 shares of CPU by default. However, this value\nis\\nshown as 0 if you run the command mentioned in the audit\nsection.\\nAlternatively,\\n1. Navigate to /sys/fs/cgroup/cpu/system.slice/\ndirectory.\\n2. Check your container instance ID using docker ps.\\n3. Now,\ninside the above directory (in step 1), you would have a directory by\nname\\ndocker-<Instance ID>.scope. For example,\ndocker4acae729e8659c6be696ee35b2237cc1fe4edd2672e9186434c5116e1a6fbed6.scope.\\nNavigate\nto this directory.\\n4. You will find a file named cpu.shares. Execute cat\ncpu.shares. This will always\\ngive you the CPU share value based on the system.\nSo, even if there is no CPU shares\\nconfigured using -c or --cpu-shares\nargument in the docker run command, this\\nfile will have a value of 1024.\\nIf\nwe set one container’s CPU shares to 512 it will receive half of the CPU time\ncompared to\\nthe other container. So, take 1024 as 100% and then do quick math\nto derive the number\\nthat you should set for respective CPU shares. For\nexample, use 512 if you want to set 50%\\nand 256 if you want to set 25%.\\n\"\n  tag \"Default Value\": \"By default, all containers on a Docker host share the\nresources equally. No CPU shares are\\nenforced.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-5.11.rb",
        "line": 1
      },
      "id": "M-5.11"
    },
    {
      "title": "5.12 Ensure the container's root filesystem is mounted as read\nonly(Scored)",
      "desc": "The container's root filesystem should be treated as a 'golden image' by\nusing Docker run's\n    --read-only option. This prevents any writes to the container's root\nfilesystem at\n    container runtime and enforces the principle of immutable infrastructure.\n    Enabling this option forces containers at runtime to explicitly define\ntheir data writing\n    strategy to persist or not persist their data.\n    This also reduces security attack vectors since the container instance's\nfilesystem cannot\n    be tampered with or written to unless it has explicit read-write\npermissions on its\n    filesystem folder and directories.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. http://docs.docker.com/reference/commandline/cli/#run\n2.\nhttps://docs.docker.com/engine/tutorials/dockervolumes/\n3.\nhttp://www.projectatomic.io/blog/2015/12/making-docker-images-write-only-inproduction/\n4.\nhttps://docs.docker.com/engine/reference/commandline/run/#mount-tmpfstmpfs\n5.\nhttps://docs.docker.com/engine/tutorials/dockervolumes/#creating-andmounting-a-data-volume-container\n",
        "severity": "medium",
        "cis_id": "5.12",
        "cis_control": "14 Controlled Access Based on the Need to Know\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "AC-6"
        ],
        "audit": "Run the following command on the docker host:\ndocker ps\n--quiet --all | xargs docker inspect --format '{{ .Id }}:\nReadonlyRootfs={{\n.HostConfig.ReadonlyRootfs }}'\nIf the above command returns true, it means the\ncontainer's root filesystem is mounted\nread-only.\nIf the above command\nreturns false, it means the container's root filesystem is writable.\n",
        "fix": "Add a --read-only flag at a container's runtime to enforce the\ncontainer's root filesystem\nto be mounted as read only.\ndocker run <Run\narguments> --read-only <Container Image Name or ID> <Command>\nEnabling the\n--read-only option at a container's runtime should be used by\nadministrators\nto force a container's executable processes to only write\ncontainer data to explicit storage\nlocations during the container's\nruntime.\nExamples of explicit storage locations during a container's runtime\ninclude, but not limited\nto:\n1. Use the --tmpfs option to mount a temporary\nfile system for non-persistent data\nwrites.\ndocker run --interactive --tty\n--read-only --tmpfs \"/run\" --tmpfs \"/tmp\"\ncentos /bin/bash\n2. Enabling\nDocker rw mounts at a container's runtime to persist container data\ndirectly\non the Docker host filesystem.\ndocker run --interactive --tty --read-only -v\n/opt/app/data:/run/app/data:rw\ncentos /bin/bash\n3. Utilizing Docker\nshared-storage volume plugins for Docker data volume to persist\ncontainer\ndata.\ndocker volume create -d convoy --opt o=size=20GB my-named-volume\ndocker\nrun --interactive --tty --read-only -v my-named-volume:/run/app/data\ncentos\n/bin/bash\n3. Transmitting container data outside of the docker during the\ncontainer's runtime\nfor container data to persist container data. Examples\ninclude hosted databases,\nnetwork file shares, and APIs.\n",
        "Default Value": "By default, a container will have its root filesystem\nwritable allowing all container\nprocesses to write files owned by the\ncontainer's runtime user.\n"
      },
      "code": "control \"M-5.12\" do\n  title \"5.12 Ensure the container's root filesystem is mounted as read\nonly(Scored)\"\n  desc  \"\n    The container's root filesystem should be treated as a 'golden image' by\nusing Docker run's\n    --read-only option. This prevents any writes to the container's root\nfilesystem at\n    container runtime and enforces the principle of immutable infrastructure.\n    Enabling this option forces containers at runtime to explicitly define\ntheir data writing\n    strategy to persist or not persist their data.\n    This also reduces security attack vectors since the container instance's\nfilesystem cannot\n    be tampered with or written to unless it has explicit read-write\npermissions on its\n    filesystem folder and directories.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. http://docs.docker.com/reference/commandline/cli/#run\\n2.\nhttps://docs.docker.com/engine/tutorials/dockervolumes/\\n3.\nhttp://www.projectatomic.io/blog/2015/12/making-docker-images-write-only-inproduction/\\n4.\nhttps://docs.docker.com/engine/reference/commandline/run/#mount-tmpfstmpfs\\n5.\nhttps://docs.docker.com/engine/tutorials/dockervolumes/#creating-andmounting-a-data-volume-container\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"5.12\"\n  tag \"cis_control\": \"14 Controlled Access Based on the Need to Know\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"AC-6\"]\n  tag \"audit\": \"Run the following command on the docker host:\\ndocker ps\n--quiet --all | xargs docker inspect --format '{{ .Id }}:\\nReadonlyRootfs={{\n.HostConfig.ReadonlyRootfs }}'\\nIf the above command returns true, it means the\ncontainer's root filesystem is mounted\\nread-only.\\nIf the above command\nreturns false, it means the container's root filesystem is writable.\\n\"\n  tag \"fix\": \"Add a --read-only flag at a container's runtime to enforce the\ncontainer's root filesystem\\nto be mounted as read only.\\ndocker run <Run\narguments> --read-only <Container Image Name or ID> <Command>\\nEnabling the\n--read-only option at a container's runtime should be used by\nadministrators\\nto force a container's executable processes to only write\ncontainer data to explicit storage\\nlocations during the container's\nruntime.\\nExamples of explicit storage locations during a container's runtime\ninclude, but not limited\\nto:\\n1. Use the --tmpfs option to mount a temporary\nfile system for non-persistent data\\nwrites.\\ndocker run --interactive --tty\n--read-only --tmpfs \\\"/run\\\" --tmpfs \\\"/tmp\\\"\\ncentos /bin/bash\\n2. Enabling\nDocker rw mounts at a container's runtime to persist container data\\ndirectly\non the Docker host filesystem.\\ndocker run --interactive --tty --read-only -v\n/opt/app/data:/run/app/data:rw\\ncentos /bin/bash\\n3. Utilizing Docker\nshared-storage volume plugins for Docker data volume to persist\\ncontainer\ndata.\\ndocker volume create -d convoy --opt o=size=20GB my-named-volume\\ndocker\nrun --interactive --tty --read-only -v my-named-volume:/run/app/data\\ncentos\n/bin/bash\\n3. Transmitting container data outside of the docker during the\ncontainer's runtime\\nfor container data to persist container data. Examples\ninclude hosted databases,\\nnetwork file shares, and APIs.\\n\"\n  tag \"Default Value\": \"By default, a container will have its root filesystem\nwritable allowing all container\\nprocesses to write files owned by the\ncontainer's runtime user.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-5.12.rb",
        "line": 1
      },
      "id": "M-5.12"
    },
    {
      "title": "5.13 Ensure incoming container traffic is binded to a specific\nhost\ninterface (Scored)",
      "desc": "By default, Docker containers can make connections to the outside world,\nbut the outside\n    world cannot connect to containers. Each outgoing connection will appear to\noriginate\n    from one of the host machine's own IP addresses. Only allow container\nservices to be\n    contacted through a specific external interface on the host machine.\n    If you have multiple network interfaces on your host machine, the container\ncan accept\n    connections on the exposed ports on any network interface. This might not\nbe desired and\n    may not be secured. Many a times a particular interface is exposed\nexternally and services\n    such as intrusion detection, intrusion prevention, firewall, load\nbalancing, etc. are run on\n    those interfaces to screen incoming public traffic. Hence, you should not\naccept incoming\n    connections on any interface. You should only allow incoming connections\nfrom a\n    particular external interface.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://docs.docker.com/engine/userguide/networking/\n",
        "severity": "medium",
        "cis_id": "5.13",
        "cis_control": "9 Limitation and Control of Network Ports, Protocols, and\nServices\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "SC-7"
        ],
        "audit": "List all the running instances of containers and their port\nmapping by executing the below\ncommand:\ndocker ps --quiet | xargs docker\ninspect --format '{{ .Id }}: Ports={{\n.NetworkSettings.Ports }}'\nReview the\nlist and ensure that the exposed container ports are tied to a\nparticular\ninterface and not to the wildcard IP address - 0.0.0.0.\nFor\nexample, if the above command returns as below, then this is non-compliant and\nthe\ncontainer can accept connections on any host interface on the specified\nport 49153.\nPorts=map[443/tcp:<nil> 80/tcp:[map[HostPort:49153\nHostIp:0.0.0.0]]]\nHowever, if the exposed port is tied to a particular\ninterface on the host as below, then this\nrecommendation is configured as\ndesired and is compliant.\nPorts=map[443/tcp:<nil> 80/tcp:[map[HostIp:10.2.3.4\nHostPort:49153]]]\n",
        "fix": "Bind the container port to a specific host interface on the\ndesired host port.\nFor example,\ndocker run --detach --publish\n10.2.3.4:49153:80 nginx\nIn the example above, the container port 80 is bound\nto the host port on 49153 and would\naccept incoming connection only from\n10.2.3.4 external interface.\n",
        "Default Value": "By default, Docker exposes the container ports on\n0.0.0.0, the wildcard IP address that\nwill match any possible incoming network\ninterface on the host machine.\n"
      },
      "code": "control \"M-5.13\" do\n  title \"5.13 Ensure incoming container traffic is binded to a specific\nhost\\ninterface (Scored)\"\n  desc  \"\n    By default, Docker containers can make connections to the outside world,\nbut the outside\n    world cannot connect to containers. Each outgoing connection will appear to\noriginate\n    from one of the host machine's own IP addresses. Only allow container\nservices to be\n    contacted through a specific external interface on the host machine.\n    If you have multiple network interfaces on your host machine, the container\ncan accept\n    connections on the exposed ports on any network interface. This might not\nbe desired and\n    may not be secured. Many a times a particular interface is exposed\nexternally and services\n    such as intrusion detection, intrusion prevention, firewall, load\nbalancing, etc. are run on\n    those interfaces to screen incoming public traffic. Hence, you should not\naccept incoming\n    connections on any interface. You should only allow incoming connections\nfrom a\n    particular external interface.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://docs.docker.com/engine/userguide/networking/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"5.13\"\n  tag \"cis_control\": \"9 Limitation and Control of Network Ports, Protocols, and\nServices\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"SC-7\"]\n  tag \"audit\": \"List all the running instances of containers and their port\nmapping by executing the below\\ncommand:\\ndocker ps --quiet | xargs docker\ninspect --format '{{ .Id }}: Ports={{\\n.NetworkSettings.Ports }}'\\nReview the\nlist and ensure that the exposed container ports are tied to a\nparticular\\ninterface and not to the wildcard IP address - 0.0.0.0.\\nFor\nexample, if the above command returns as below, then this is non-compliant and\nthe\\ncontainer can accept connections on any host interface on the specified\nport 49153.\\nPorts=map[443/tcp:<nil> 80/tcp:[map[HostPort:49153\nHostIp:0.0.0.0]]]\\nHowever, if the exposed port is tied to a particular\ninterface on the host as below, then this\\nrecommendation is configured as\ndesired and is compliant.\\nPorts=map[443/tcp:<nil> 80/tcp:[map[HostIp:10.2.3.4\nHostPort:49153]]]\\n\"\n  tag \"fix\": \"Bind the container port to a specific host interface on the\ndesired host port.\\nFor example,\\ndocker run --detach --publish\n10.2.3.4:49153:80 nginx\\nIn the example above, the container port 80 is bound\nto the host port on 49153 and would\\naccept incoming connection only from\n10.2.3.4 external interface.\\n\"\n  tag \"Default Value\": \"By default, Docker exposes the container ports on\n0.0.0.0, the wildcard IP address that\\nwill match any possible incoming network\ninterface on the host machine.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-5.13.rb",
        "line": 1
      },
      "id": "M-5.13"
    },
    {
      "title": "5.14 Ensure 'on-failure' container restart policy is set to '5'\n(Scored)",
      "desc": "Using the --restart flag in docker run command you can specify a restart\npolicy for how a\n    container should or should not be restarted on exit. You should choose the\non-failure\n    restart policy and limit the restart attempts to 5.\n    If you indefinitely keep trying to start the container, it could possibly\nlead to a denial of\n    service on the host. It could be an easy way to do a distributed denial of\nservice attack\n    especially if you have many containers on the same host. Additionally,\nignoring the exit\n    status of the container and always attempting to restart the container\nleads to noninvestigation of the root cause behind containers getting\nterminated. If a container gets\n    terminated, you should investigate on the reason behind it instead of just\nattempting to\n    restart it indefinitely. Thus, it is recommended to use on-failure restart\npolicy and limit it\n    to maximum of 5 restart attempts.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://docs.docker.com/engine/reference/commandline/run/#restart-policiesrestart\n",
        "severity": "medium",
        "cis_id": "5.14",
        "cis_control": "18 Application Software Security\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "SI-1"
        ],
        "audit": "docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}:\nRestartPolicyName={{ .HostConfig.RestartPolicy.Name }}\nMaximumRetryCount={{\n.HostConfig.RestartPolicy.MaximumRetryCount }}'\n\n\n\nIf\nthe above command returns RestartPolicyName=always, then the system is\nnot\nconfigured as desired and hence this recommendation is non-compliant.\nIf\nthe above command returns RestartPolicyName=no or just\nRestartPolicyName=,\nthen the restart policies are not being used and the\ncontainer would never be\nrestarted of its own. This recommendation is then Not\nApplicable and can be\nassumed to be compliant.\nIf the above command returns\nRestartPolicyName=on-failure, then verify that the\nnumber of restart attempts\nis set to 5 or less by looking at MaximumRetryCount.\n",
        "fix": "If a container is desired to be restarted of its own, then, for\nexample, you could start the\ncontainer as below:\ndocker run --detach\n--restart=on-failure:5 nginx\n",
        "Default Value": "By default, containers are not configured with restart\npolicies. Hence, containers do not\nattempt to restart of their own.\n"
      },
      "code": "control \"M-5.14\" do\n  title \"5.14 Ensure 'on-failure' container restart policy is set to '5'\n(Scored)\"\n  desc  \"\n    Using the --restart flag in docker run command you can specify a restart\npolicy for how a\n    container should or should not be restarted on exit. You should choose the\non-failure\n    restart policy and limit the restart attempts to 5.\n    If you indefinitely keep trying to start the container, it could possibly\nlead to a denial of\n    service on the host. It could be an easy way to do a distributed denial of\nservice attack\n    especially if you have many containers on the same host. Additionally,\nignoring the exit\n    status of the container and always attempting to restart the container\nleads to noninvestigation of the root cause behind containers getting\nterminated. If a container gets\n    terminated, you should investigate on the reason behind it instead of just\nattempting to\n    restart it indefinitely. Thus, it is recommended to use on-failure restart\npolicy and limit it\n    to maximum of 5 restart attempts.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://docs.docker.com/engine/reference/commandline/run/#restart-policiesrestart\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"5.14\"\n  tag \"cis_control\": \"18 Application Software Security\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"SI-1\"]\n  tag \"audit\": \"docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}:\\nRestartPolicyName={{ .HostConfig.RestartPolicy.Name }}\nMaximumRetryCount={{\\n.HostConfig.RestartPolicy.MaximumRetryCount }}'\\n\\n\\n\\nIf\nthe above command returns RestartPolicyName=always, then the system is\nnot\\nconfigured as desired and hence this recommendation is non-compliant.\\nIf\nthe above command returns RestartPolicyName=no or just\nRestartPolicyName=,\\nthen the restart policies are not being used and the\ncontainer would never be\\nrestarted of its own. This recommendation is then Not\nApplicable and can be\\nassumed to be compliant.\\nIf the above command returns\nRestartPolicyName=on-failure, then verify that the\\nnumber of restart attempts\nis set to 5 or less by looking at MaximumRetryCount.\\n\"\n  tag \"fix\": \"If a container is desired to be restarted of its own, then, for\nexample, you could start the\\ncontainer as below:\\ndocker run --detach\n--restart=on-failure:5 nginx\\n\"\n  tag \"Default Value\": \"By default, containers are not configured with restart\npolicies. Hence, containers do not\\nattempt to restart of their own.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-5.14.rb",
        "line": 1
      },
      "id": "M-5.14"
    },
    {
      "title": "5.15 Ensure the host's process namespace is not shared (Scored)",
      "desc": "Process ID (PID) namespaces isolate the process ID number space, meaning\nthat processes\n    in different PID namespaces can have the same PID. This is process level\nisolation between\n    containers and the host.\n    PID namespace provides separation of processes. The PID Namespace removes\nthe view of\n    the system processes, and allows process ids to be reused including PID 1.\nIf the host's PID\n    namespace is shared with the container, it would basically allow processes\nwithin the\n    container to see all of the processes on the host system. This breaks the\nbenefit of process\n    level isolation between the host and the containers. Someone having access\nto the\n    container can eventually know all the processes running on the host system\nand can even\n    kill the host system processes from within the container. This can be\ncatastrophic. Hence,\n    do not share the host's process namespace with the containers.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://docs.docker.com/engine/reference/run/#pid-settings-pid\n2.\nhttp://man7.org/linux/man-pages/man7/pid_namespaces.7.html\n",
        "severity": "medium",
        "cis_id": "5.15",
        "cis_control": "18 Application Software Security\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "SI-1"
        ],
        "audit": "docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}:\nPidMode={{ .HostConfig.PidMode }}'\nIf the above command returns host, it\nmeans the host PID namespace is shared with the\ncontainer else this\nrecommendation is compliant.\n",
        "fix": "Do not start a container with --pid=host argument.\nFor example,\ndo not start a container as below:\ndocker run --interactive --tty --pid=host\ncentos /bin/bash\n",
        "Default Value": "By default, all containers have the PID namespace\nenabled and the host's process\nnamespace is not shared with the containers.\n"
      },
      "code": "control \"M-5.15\" do\n  title \"5.15 Ensure the host's process namespace is not shared (Scored)\"\n  desc  \"\n    Process ID (PID) namespaces isolate the process ID number space, meaning\nthat processes\n    in different PID namespaces can have the same PID. This is process level\nisolation between\n    containers and the host.\n    PID namespace provides separation of processes. The PID Namespace removes\nthe view of\n    the system processes, and allows process ids to be reused including PID 1.\nIf the host's PID\n    namespace is shared with the container, it would basically allow processes\nwithin the\n    container to see all of the processes on the host system. This breaks the\nbenefit of process\n    level isolation between the host and the containers. Someone having access\nto the\n    container can eventually know all the processes running on the host system\nand can even\n    kill the host system processes from within the container. This can be\ncatastrophic. Hence,\n    do not share the host's process namespace with the containers.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://docs.docker.com/engine/reference/run/#pid-settings-pid\\n2.\nhttp://man7.org/linux/man-pages/man7/pid_namespaces.7.html\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"5.15\"\n  tag \"cis_control\": \"18 Application Software Security\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"SI-1\"]\n  tag \"audit\": \"docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}:\\nPidMode={{ .HostConfig.PidMode }}'\\nIf the above command returns host, it\nmeans the host PID namespace is shared with the\\ncontainer else this\nrecommendation is compliant.\\n\"\n  tag \"fix\": \"Do not start a container with --pid=host argument.\\nFor example,\ndo not start a container as below:\\ndocker run --interactive --tty --pid=host\ncentos /bin/bash\\n\"\n  tag \"Default Value\": \"By default, all containers have the PID namespace\nenabled and the host's process\\nnamespace is not shared with the containers.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-5.15.rb",
        "line": 1
      },
      "id": "M-5.15"
    },
    {
      "title": "5.16 Ensure the host's IPC namespace is not shared (Scored)",
      "desc": "IPC (POSIX/SysV IPC) namespace provides separation of named shared memory\nsegments,\n    semaphores and message queues. IPC namespace on the host thus should not be\nshared\n    with the containers and should remain isolated.\n    IPC namespace provides separation of IPC between the host and containers.\nIf the host's\n    IPC namespace is shared with the container, it would basically allow\nprocesses within the\n    container to see all of the IPC on the host system. This breaks the benefit\nof IPC level\n    isolation between the host and the containers. Someone having access to the\ncontainer can\n    eventually manipulate the host IPC. This can be catastrophic. Hence, do not\nshare the host's\n    IPC namespace with the containers.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://docs.docker.com/engine/reference/run/#ipc-settings-ipc\n2.\nhttp://man7.org/linux/man-pages/man7/namespaces.7.html\n",
        "severity": "medium",
        "cis_id": "5.16",
        "cis_control": "18 Application Software Security\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "SI-1"
        ],
        "audit": "docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}:\nIpcMode={{ .HostConfig.IpcMode }}'\nIf the above command returns host, it\nmeans the host IPC namespace is shared with the\ncontainer. If the above\ncommand returns nothing, then the host's IPC namespace is not\nshared. This\nrecommendation is then compliant.\n",
        "fix": "Do not start a container with --ipc=host argument. For example,\ndo not start a container\nas below:\ndocker run --interactive --tty --ipc=host\ncentos /bin/bash\n",
        "Default Value": "By default, all containers have the IPC namespace\nenabled and host IPC namespace is not\nshared with any container.\n"
      },
      "code": "control \"M-5.16\" do\n  title \"5.16 Ensure the host's IPC namespace is not shared (Scored)\"\n  desc  \"\n    IPC (POSIX/SysV IPC) namespace provides separation of named shared memory\nsegments,\n    semaphores and message queues. IPC namespace on the host thus should not be\nshared\n    with the containers and should remain isolated.\n    IPC namespace provides separation of IPC between the host and containers.\nIf the host's\n    IPC namespace is shared with the container, it would basically allow\nprocesses within the\n    container to see all of the IPC on the host system. This breaks the benefit\nof IPC level\n    isolation between the host and the containers. Someone having access to the\ncontainer can\n    eventually manipulate the host IPC. This can be catastrophic. Hence, do not\nshare the host's\n    IPC namespace with the containers.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://docs.docker.com/engine/reference/run/#ipc-settings-ipc\\n2.\nhttp://man7.org/linux/man-pages/man7/namespaces.7.html\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"5.16\"\n  tag \"cis_control\": \"18 Application Software Security\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"SI-1\"]\n  tag \"audit\": \"docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}:\\nIpcMode={{ .HostConfig.IpcMode }}'\\nIf the above command returns host, it\nmeans the host IPC namespace is shared with the\\ncontainer. If the above\ncommand returns nothing, then the host's IPC namespace is not\\nshared. This\nrecommendation is then compliant.\\n\"\n  tag \"fix\": \"Do not start a container with --ipc=host argument. For example,\ndo not start a container\\nas below:\\ndocker run --interactive --tty --ipc=host\ncentos /bin/bash\\n\"\n  tag \"Default Value\": \"By default, all containers have the IPC namespace\nenabled and host IPC namespace is not\\nshared with any container.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-5.16.rb",
        "line": 1
      },
      "id": "M-5.16"
    },
    {
      "title": "5.17 Ensure host devices are not directly exposed to containers\n(Not\nScored)",
      "desc": "Host devices can be directly exposed to containers at runtime. Do not\ndirectly expose host\n    devices to containers especially for containers that are not trusted.\n    The --device option exposes the host devices to the containers and\nconsequently, the\n    containers can directly access such host devices. You would not require the\ncontainer to\n    run in privileged mode to access and manipulate the host devices. By\ndefault, the\n    container will be able to read, write and mknod these devices.\nAdditionally, it is possible for\n    containers to remove block devices from the host. Hence, do not expose host\ndevices to\n    containers directly.\n    If at all, you would want to expose the host device to a container, use the\nsharing\n    permissions appropriately:\n\n\n\n    r - read only\n    w - writable\n    m - mknod allowed",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://docs.docker.com/engine/reference/commandline/run/#options\n",
        "severity": "medium",
        "cis_id": "5.17",
        "cis_control": "14 Controlled Access Based on the Need to Know\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "AC-6"
        ],
        "audit": "docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}:\nDevices={{ .HostConfig.Devices }}'\nThe above command would list out each\ndevice with below information:\n\n\n\nCgroupPermissions - For example,\nrwm\nPathInContainer - Device path within the container\nPathOnHost - Device\npath on the host\nVerify that the host device is needed to be accessed from\nwithin the container and the\npermissions required are correctly set. If the\nabove command returns [], then the container\ndoes not have access to host\ndevices. This recommendation can be assumed to be\ncompliant.\n",
        "fix": "Do not directly expose the host devices to containers. If at all,\nyou need to expose the host\ndevices to containers, use the correct set of\npermissions:\nFor example, do not start a container as below:\ndocker run\n--interactive --tty --device=/dev/tty0:/dev/tty0:rwm\n-device=/dev/temp_sda:/dev/temp_sda:rwm centos bash\nFor example, share the\nhost device with correct permissions:\ndocker run --interactive --tty\n--device=/dev/tty0:/dev/tty0:rw -device=/dev/temp_sda:/dev/temp_sda:r centos\nbash\n",
        "Default Value": "By default, no host devices are exposed to containers.\nIf you do not provide sharing\npermissions and choose to expose a host device\nto a container, the host device would be\nexposed with read, write and mknod\npermissions.\n"
      },
      "code": "control \"M-5.17\" do\n  title \"5.17 Ensure host devices are not directly exposed to containers\n(Not\\nScored)\"\n  desc  \"\n    Host devices can be directly exposed to containers at runtime. Do not\ndirectly expose host\n    devices to containers especially for containers that are not trusted.\n    The --device option exposes the host devices to the containers and\nconsequently, the\n    containers can directly access such host devices. You would not require the\ncontainer to\n    run in privileged mode to access and manipulate the host devices. By\ndefault, the\n    container will be able to read, write and mknod these devices.\nAdditionally, it is possible for\n    containers to remove block devices from the host. Hence, do not expose host\ndevices to\n    containers directly.\n    If at all, you would want to expose the host device to a container, use the\nsharing\n    permissions appropriately:\n\n\n\n    r - read only\n    w - writable\n    m - mknod allowed\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://docs.docker.com/engine/reference/commandline/run/#options\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"5.17\"\n  tag \"cis_control\": \"14 Controlled Access Based on the Need to Know\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"AC-6\"]\n  tag \"audit\": \"docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}:\\nDevices={{ .HostConfig.Devices }}'\\nThe above command would list out each\ndevice with below information:\\n\\n\\n\\nCgroupPermissions - For example,\nrwm\\nPathInContainer - Device path within the container\\nPathOnHost - Device\npath on the host\\nVerify that the host device is needed to be accessed from\nwithin the container and the\\npermissions required are correctly set. If the\nabove command returns [], then the container\\ndoes not have access to host\ndevices. This recommendation can be assumed to be\\ncompliant.\\n\"\n  tag \"fix\": \"Do not directly expose the host devices to containers. If at all,\nyou need to expose the host\\ndevices to containers, use the correct set of\npermissions:\\nFor example, do not start a container as below:\\ndocker run\n--interactive --tty --device=/dev/tty0:/dev/tty0:rwm\n-device=/dev/temp_sda:/dev/temp_sda:rwm centos bash\\nFor example, share the\nhost device with correct permissions:\\ndocker run --interactive --tty\n--device=/dev/tty0:/dev/tty0:rw -device=/dev/temp_sda:/dev/temp_sda:r centos\nbash\\n\"\n  tag \"Default Value\": \"By default, no host devices are exposed to containers.\nIf you do not provide sharing\\npermissions and choose to expose a host device\nto a container, the host device would be\\nexposed with read, write and mknod\npermissions.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-5.17.rb",
        "line": 1
      },
      "id": "M-5.17"
    },
    {
      "title": "5.18 Ensure the default ulimit is overwritten at runtime, only if\nneeded(Not Scored)",
      "desc": "The default ulimit is set at the Docker daemon level. However, you may\noverride the default\n    ulimit setting, if needed, during container runtime.\n    ulimit provides control over the resources available to the shell and to\nprocesses started\n    by it. Setting system resource limits judiciously saves you from many\ndisasters such as a\n    fork bomb. Sometimes, even friendly users and legitimate processes can\noveruse system\n    resources and in-turn can make the system unusable.\n    The default ulimit set at the Docker daemon level should be honored. If the\ndefault ulimit\n    settings are not appropriate for a particular container instance, you may\noverride them as\n    an exception. But, do not make this a practice. If most of the container\ninstances are\n    overriding default ulimit settings, consider changing the default ulimit\nsettings to\n    something that is appropriate for your needs.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://docs.docker.com/engine/reference/commandline/run/#set-ulimits-incontainer-ulimit\n2.\nhttp://www.oreilly.com/webops-perf/free/files/docker-security.pdf\n",
        "severity": "medium",
        "cis_id": "5.18",
        "cis_control": "18 Application Software Security\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "SI-1"
        ],
        "audit": "docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}:\nUlimits={{ .HostConfig.Ulimits }}'\nThe above command should return\nUlimits=<no value> for each container instance until\nand unless there is an\nexception and a need to override the default ulimit settings.\n",
        "fix": "Only override the default ulimit settings if needed.\nFor\nexample, to override default ulimit settings start a container as\nbelow:\ndocker run --ulimit nofile=1024:1024 --interactive --tty centos\n/bin/bash\n",
        "Default Value": "Container instances inherit the default ulimit settings\nset at the Docker daemon level.\n"
      },
      "code": "control \"M-5.18\" do\n  title \"5.18 Ensure the default ulimit is overwritten at runtime, only if\nneeded(Not Scored)\"\n  desc  \"\n    The default ulimit is set at the Docker daemon level. However, you may\noverride the default\n    ulimit setting, if needed, during container runtime.\n    ulimit provides control over the resources available to the shell and to\nprocesses started\n    by it. Setting system resource limits judiciously saves you from many\ndisasters such as a\n    fork bomb. Sometimes, even friendly users and legitimate processes can\noveruse system\n    resources and in-turn can make the system unusable.\n    The default ulimit set at the Docker daemon level should be honored. If the\ndefault ulimit\n    settings are not appropriate for a particular container instance, you may\noverride them as\n    an exception. But, do not make this a practice. If most of the container\ninstances are\n    overriding default ulimit settings, consider changing the default ulimit\nsettings to\n    something that is appropriate for your needs.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://docs.docker.com/engine/reference/commandline/run/#set-ulimits-incontainer-ulimit\\n2.\nhttp://www.oreilly.com/webops-perf/free/files/docker-security.pdf\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"5.18\"\n  tag \"cis_control\": \"18 Application Software Security\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"SI-1\"]\n  tag \"audit\": \"docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}:\\nUlimits={{ .HostConfig.Ulimits }}'\\nThe above command should return\nUlimits=<no value> for each container instance until\\nand unless there is an\nexception and a need to override the default ulimit settings.\\n\"\n  tag \"fix\": \"Only override the default ulimit settings if needed.\\nFor\nexample, to override default ulimit settings start a container as\nbelow:\\ndocker run --ulimit nofile=1024:1024 --interactive --tty centos\n/bin/bash\\n\"\n  tag \"Default Value\": \"Container instances inherit the default ulimit settings\nset at the Docker daemon level.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-5.18.rb",
        "line": 1
      },
      "id": "M-5.18"
    },
    {
      "title": "5.19 Ensure mount propagation mode is not set to shared (Scored)",
      "desc": "Mount propagation mode allows mounting volumes in shared, slave or private\nmode on a\n    container. Do not use shared mount propagation mode until needed.\n    A shared mount is replicated at all mounts and the changes made at any\nmount point are\n    propagated to all mounts. Mounting a volume in shared mode does not\nrestrict any other\n    container to mount and make changes to that volume. This might be\ncatastrophic if the\n    mounted volume is sensitive to changes. Do not set mount propagation mode\nto shared\n    until needed.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://github.com/docker/docker/pull/17034\n2.\nhttps://docs.docker.com/engine/reference/run/#volume-shared-filesystems\n3.\nhttps://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt\n",
        "severity": "medium",
        "cis_id": "5.19",
        "cis_control": "14 Controlled Access Based on the Need to Know\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "AC-6"
        ],
        "audit": "docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}:\nPropagation={{range $mnt := .Mounts}} {{json $mnt.Propagation}}\n{{end}}'\nThe above command would return the propagation mode for mounted\nvolumes.\nPropagation mode should not be set to shared unless needed. The above\ncommand might\nthrow errors if there are no mounts. In that case, this\nrecommendation is not applicable.\n",
        "fix": "Do not mount volumes in shared mode propagation.\nFor example, do\nnot start container as below:\ndocker run <Run arguments>\n--volume=/hostPath:/containerPath:shared\n<Container Image Name or ID>\n<Command>\n",
        "Default Value": "By default, the container mounts are private.\n"
      },
      "code": "control \"M-5.19\" do\n  title \"5.19 Ensure mount propagation mode is not set to shared (Scored)\"\n  desc  \"\n    Mount propagation mode allows mounting volumes in shared, slave or private\nmode on a\n    container. Do not use shared mount propagation mode until needed.\n    A shared mount is replicated at all mounts and the changes made at any\nmount point are\n    propagated to all mounts. Mounting a volume in shared mode does not\nrestrict any other\n    container to mount and make changes to that volume. This might be\ncatastrophic if the\n    mounted volume is sensitive to changes. Do not set mount propagation mode\nto shared\n    until needed.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://github.com/docker/docker/pull/17034\\n2.\nhttps://docs.docker.com/engine/reference/run/#volume-shared-filesystems\\n3.\nhttps://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"5.19\"\n  tag \"cis_control\": \"14 Controlled Access Based on the Need to Know\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"AC-6\"]\n  tag \"audit\": \"docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}:\\nPropagation={{range $mnt := .Mounts}} {{json $mnt.Propagation}}\n{{end}}'\\nThe above command would return the propagation mode for mounted\nvolumes.\\nPropagation mode should not be set to shared unless needed. The above\ncommand might\\nthrow errors if there are no mounts. In that case, this\nrecommendation is not applicable.\\n\"\n  tag \"fix\": \"Do not mount volumes in shared mode propagation.\\nFor example, do\nnot start container as below:\\ndocker run <Run arguments>\n--volume=/hostPath:/containerPath:shared\\n<Container Image Name or ID>\n<Command>\\n\"\n  tag \"Default Value\": \"By default, the container mounts are private.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-5.19.rb",
        "line": 1
      },
      "id": "M-5.19"
    },
    {
      "title": "5.2 Ensure SELinux security options are set, if applicable (Scored)",
      "desc": "SELinux is an effective and easy-to-use Linux application security system.\nIt is available on\n    quite a few Linux distributions by default such as Red Hat and Fedora.\n    SELinux provides a Mandatory Access Control (MAC) system that greatly\naugments the\n    default Discretionary Access Control (DAC) model. You can thus add an extra\nlayer of safety\n    by enabling SELinux on your Linux host, if applicable.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\n2.\n3.\n4.\nhttps://docs.docker.com/engine/security/security/#other-kernel-security-features\nhttps://docs.docker.com/engine/reference/run/#security-configuration\nhttp://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/\nhttps://access.redhat.com/documentation/enus/red_hat_enterprise_linux_atomic_host/7/html/container_security_guide/docker_\nselinux_security_policy\n",
        "severity": "medium",
        "cis_id": "5.2",
        "cis_control": "14.4 Protect Information With Access Control Lists\n",
        "cis_level": "Level 2 - Docker",
        "nist": [
          "AC-3 (3)"
        ],
        "audit": "docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}:\nSecurityOpt={{ .HostConfig.SecurityOpt }}'\nThe above command should\nreturn all the security options currently configured for the\ncontainers.\n",
        "fix": "If SELinux is applicable for your Linux OS, use it. You may have\nto follow below set of steps:\n1.\n2.\n3.\n4.\nSet the SELinux State.\nSet the\nSELinux Policy.\nCreate or import a SELinux policy template for Docker\ncontainers.\nStart Docker in daemon mode with SELinux enabled. For\nexample,\ndocker daemon --selinux-enabled\n5. Start your Docker container using\nthe security options. For example,\ndocker run --interactive --tty\n--security-opt label=level:TopSecret centos\n/bin/bash\n",
        "Default Value": "By default, no SELinux security options are applied on\ncontainers.\n"
      },
      "code": "control \"M-5.2\" do\n  title \"5.2 Ensure SELinux security options are set, if applicable (Scored)\"\n  desc  \"\n    SELinux is an effective and easy-to-use Linux application security system.\nIt is available on\n    quite a few Linux distributions by default such as Red Hat and Fedora.\n    SELinux provides a Mandatory Access Control (MAC) system that greatly\naugments the\n    default Discretionary Access Control (DAC) model. You can thus add an extra\nlayer of safety\n    by enabling SELinux on your Linux host, if applicable.\n\n  \"\n  impact 0.5\n  tag \"ref\":\n\"1.\\n2.\\n3.\\n4.\\nhttps://docs.docker.com/engine/security/security/#other-kernel-security-features\\nhttps://docs.docker.com/engine/reference/run/#security-configuration\\nhttp://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/\\nhttps://access.redhat.com/documentation/enus/red_hat_enterprise_linux_atomic_host/7/html/container_security_guide/docker_\\nselinux_security_policy\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"5.2\"\n  tag \"cis_control\": \"14.4 Protect Information With Access Control Lists\\n\"\n  tag \"cis_level\": \"Level 2 - Docker\"\n  tag \"nist\": [\"AC-3 (3)\"]\n  tag \"audit\": \"docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}:\\nSecurityOpt={{ .HostConfig.SecurityOpt }}'\\nThe above command should\nreturn all the security options currently configured for the\\ncontainers.\\n\"\n  tag \"fix\": \"If SELinux is applicable for your Linux OS, use it. You may have\nto follow below set of steps:\\n1.\\n2.\\n3.\\n4.\\nSet the SELinux State.\\nSet the\nSELinux Policy.\\nCreate or import a SELinux policy template for Docker\ncontainers.\\nStart Docker in daemon mode with SELinux enabled. For\nexample,\\ndocker daemon --selinux-enabled\\n5. Start your Docker container using\nthe security options. For example,\\ndocker run --interactive --tty\n--security-opt label=level:TopSecret centos\\n/bin/bash\\n\"\n  tag \"Default Value\": \"By default, no SELinux security options are applied on\ncontainers.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-5.2.rb",
        "line": 1
      },
      "id": "M-5.2"
    },
    {
      "title": "5.20 Ensure the host's UTS namespace is not shared (Scored)",
      "desc": "UTS namespaces provide isolation of two system identifiers: the hostname\nand the NIS\n    domain name. It is used for setting the hostname and the domain that is\nvisible to running\n    processes in that namespace. Processes running within containers do not\ntypically require\n    to know hostname and domain name. Hence, the namespace should not be shared\nwith the\n    host.\n    Sharing the UTS namespace with the host provides full permission to the\ncontainer to\n    change the hostname of the host. This is insecure and should not be allowed.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://docs.docker.com/engine/reference/run/#uts-settings-uts\n2.\nhttp://man7.org/linux/man-pages/man7/namespaces.7.html\n",
        "severity": "medium",
        "cis_id": "5.20",
        "cis_control": "18 Application Software Security\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "SI-1"
        ],
        "audit": "docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}:\nUTSMode={{ .HostConfig.UTSMode }}'\nIf the above command returns host, it\nmeans the host UTS namespace is shared with the\ncontainer and this\nrecommendation is non-compliant. If the above command returns\nnothing, then\nthe host's UTS namespace is not shared. This recommendation is\nthen\ncompliant.\n",
        "fix": "Do not start a container with --uts=host argument.\nFor example,\ndo not start a container as below:\ndocker run --rm --interactive --tty\n--uts=host rhel7.2\n",
        "Default Value": "By default, all containers have the UTS namespace\nenabled and host UTS namespace is not\nshared with any container.\n"
      },
      "code": "control \"M-5.20\" do\n  title \"5.20 Ensure the host's UTS namespace is not shared (Scored)\"\n  desc  \"\n    UTS namespaces provide isolation of two system identifiers: the hostname\nand the NIS\n    domain name. It is used for setting the hostname and the domain that is\nvisible to running\n    processes in that namespace. Processes running within containers do not\ntypically require\n    to know hostname and domain name. Hence, the namespace should not be shared\nwith the\n    host.\n    Sharing the UTS namespace with the host provides full permission to the\ncontainer to\n    change the hostname of the host. This is insecure and should not be allowed.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://docs.docker.com/engine/reference/run/#uts-settings-uts\\n2.\nhttp://man7.org/linux/man-pages/man7/namespaces.7.html\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"5.20\"\n  tag \"cis_control\": \"18 Application Software Security\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"SI-1\"]\n  tag \"audit\": \"docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}:\\nUTSMode={{ .HostConfig.UTSMode }}'\\nIf the above command returns host, it\nmeans the host UTS namespace is shared with the\\ncontainer and this\nrecommendation is non-compliant. If the above command returns\\nnothing, then\nthe host's UTS namespace is not shared. This recommendation is\nthen\\ncompliant.\\n\"\n  tag \"fix\": \"Do not start a container with --uts=host argument.\\nFor example,\ndo not start a container as below:\\ndocker run --rm --interactive --tty\n--uts=host rhel7.2\\n\"\n  tag \"Default Value\": \"By default, all containers have the UTS namespace\nenabled and host UTS namespace is not\\nshared with any container.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-5.20.rb",
        "line": 1
      },
      "id": "M-5.20"
    },
    {
      "title": "5.21 Ensure the default seccomp profile is not Disabled (Scored)",
      "desc": "Seccomp filtering provides a means for a process to specify a filter for\nincoming system\n    calls. The default Docker seccomp profile works on whitelist basis and\nallows 311 system\n    calls blocking all others. It should not be disabled unless it hinders your\ncontainer\n    application usage.\n    A large number of system calls are exposed to every userland process with\nmany of them\n    going unused for the entire lifetime of the process. Most of the\napplications do not need all\n    the system calls and thus benefit by having a reduced set of available\nsystem calls. The\n    reduced set of system calls reduces the total kernel surface exposed to the\napplication and\n    thus improvises application security.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttp://blog.scalock.com/new-docker-security-features-and-what-they-meanseccomp-profiles\n2.\nhttps://docs.docker.com/engine/reference/run/#security-configuration\n3.\nhttps://github.com/docker/docker/blob/master/profiles/seccomp/default.json\n4.\nhttps://docs.docker.com/engine/security/seccomp/\n5.\nhttps://www.kernel.org/doc/Documentation/prctl/seccomp_filter.txt\n6.\nhttps://github.com/docker/docker/issues/22870\n",
        "severity": "medium",
        "cis_id": "5.21",
        "cis_control": "18 Application Software Security\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "SI-1"
        ],
        "audit": "docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}:\nSecurityOpt={{ .HostConfig.SecurityOpt }}'\nThe above command should\nreturn <no value> or your modified seccomp profile. If it\nreturns\n[seccomp:unconfined], that means this recommendation is non-compliant and\nthe\ncontainer is running without any seccomp profiles.\n",
        "fix": "By default, seccomp profiles are enabled. You do not need to do\nanything unless you want\nto modify and use the modified seccomp profile.\n",
        "Default Value": "When you run a container, it uses the default profile\nunless you override it with the -security-opt option.\n"
      },
      "code": "control \"M-5.21\" do\n  title \"5.21 Ensure the default seccomp profile is not Disabled (Scored)\"\n  desc  \"\n    Seccomp filtering provides a means for a process to specify a filter for\nincoming system\n    calls. The default Docker seccomp profile works on whitelist basis and\nallows 311 system\n    calls blocking all others. It should not be disabled unless it hinders your\ncontainer\n    application usage.\n    A large number of system calls are exposed to every userland process with\nmany of them\n    going unused for the entire lifetime of the process. Most of the\napplications do not need all\n    the system calls and thus benefit by having a reduced set of available\nsystem calls. The\n    reduced set of system calls reduces the total kernel surface exposed to the\napplication and\n    thus improvises application security.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttp://blog.scalock.com/new-docker-security-features-and-what-they-meanseccomp-profiles\\n2.\nhttps://docs.docker.com/engine/reference/run/#security-configuration\\n3.\nhttps://github.com/docker/docker/blob/master/profiles/seccomp/default.json\\n4.\nhttps://docs.docker.com/engine/security/seccomp/\\n5.\nhttps://www.kernel.org/doc/Documentation/prctl/seccomp_filter.txt\\n6.\nhttps://github.com/docker/docker/issues/22870\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"5.21\"\n  tag \"cis_control\": \"18 Application Software Security\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"SI-1\"]\n  tag \"audit\": \"docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}:\\nSecurityOpt={{ .HostConfig.SecurityOpt }}'\\nThe above command should\nreturn <no value> or your modified seccomp profile. If it\\nreturns\n[seccomp:unconfined], that means this recommendation is non-compliant and\nthe\\ncontainer is running without any seccomp profiles.\\n\"\n  tag \"fix\": \"By default, seccomp profiles are enabled. You do not need to do\nanything unless you want\\nto modify and use the modified seccomp profile.\\n\"\n  tag \"Default Value\": \"When you run a container, it uses the default profile\nunless you override it with the -security-opt option.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-5.21.rb",
        "line": 1
      },
      "id": "M-5.21"
    },
    {
      "title": "5.22 Ensure docker exec commands are not used with privileged\noption(Scored)",
      "desc": "Do not docker exec with --privileged option.\n    Using --privileged option in docker exec gives extended Linux capabilities\nto the\n    command. This could potentially be insecure and unsafe to do especially\nwhen you are\n    running containers with dropped capabilities or with enhanced restrictions.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://docs.docker.com/engine/reference/commandline/exec/\n",
        "severity": "medium",
        "cis_id": "5.22",
        "cis_control": "5.1 Minimize And Sparingly Use Administrative\nPrivileges\n",
        "cis_level": "Level 2 - Docker",
        "nist": [
          "AC-6 (9)"
        ],
        "audit": "If you have auditing enabled as prescribed in Section 1, you\ncan use the below command to\nfilter out docker exec commands that used\n--privileged option.\nausearch -k docker | grep exec | grep privileged\n",
        "fix": "Do not use --privileged option in docker exec command.\n",
        "Default Value": "By default, docker exec command runs without\n--privileged option.\n"
      },
      "code": "control \"M-5.22\" do\n  title \"5.22 Ensure docker exec commands are not used with privileged\noption(Scored)\"\n  desc  \"\n    Do not docker exec with --privileged option.\n    Using --privileged option in docker exec gives extended Linux capabilities\nto the\n    command. This could potentially be insecure and unsafe to do especially\nwhen you are\n    running containers with dropped capabilities or with enhanced restrictions.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://docs.docker.com/engine/reference/commandline/exec/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"5.22\"\n  tag \"cis_control\": \"5.1 Minimize And Sparingly Use Administrative\nPrivileges\\n\"\n  tag \"cis_level\": \"Level 2 - Docker\"\n  tag \"nist\": [\"AC-6 (9)\"]\n  tag \"audit\": \"If you have auditing enabled as prescribed in Section 1, you\ncan use the below command to\\nfilter out docker exec commands that used\n--privileged option.\\nausearch -k docker | grep exec | grep privileged\\n\"\n  tag \"fix\": \"Do not use --privileged option in docker exec command.\\n\"\n  tag \"Default Value\": \"By default, docker exec command runs without\n--privileged option.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-5.22.rb",
        "line": 1
      },
      "id": "M-5.22"
    },
    {
      "title": "5.23 Ensure docker exec commands are not used with user option(Scored)",
      "desc": "Do not docker exec with --user option.\n    Using --user option in docker exec executes the command within the\ncontainer as that\n    user. This could potentially be insecure and unsafe to do especially when\nyou are running\n    containers with dropped capabilities or with enhanced restrictions.\n    For example, suppose your container is running as tomcat user (or any other\nnon-root\n    user), it would be possible to run a command through docker exec as\nrootwith -user=root option. This could potentially be dangerous.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://docs.docker.com/engine/reference/commandline/exec/\n",
        "severity": "medium",
        "cis_id": "5.23",
        "cis_control": "5 Controlled Use of Administration Privileges\n",
        "cis_level": "Level 2 - Docker",
        "nist": [
          "AC-6"
        ],
        "audit": "If you have auditing enabled as prescribed in Section 1, you\ncan use the below command to\nfilter out docker exec commands that used --user\noption.\nausearch -k docker | grep exec | grep user\n",
        "fix": "Do not use --user option in docker exec command.\n",
        "Default Value": "By default, docker exec command runs without --user\noption.\n"
      },
      "code": "control \"M-5.23\" do\n  title \"5.23 Ensure docker exec commands are not used with user option(Scored)\"\n  desc  \"\n    Do not docker exec with --user option.\n    Using --user option in docker exec executes the command within the\ncontainer as that\n    user. This could potentially be insecure and unsafe to do especially when\nyou are running\n    containers with dropped capabilities or with enhanced restrictions.\n    For example, suppose your container is running as tomcat user (or any other\nnon-root\n    user), it would be possible to run a command through docker exec as\nrootwith -user=root option. This could potentially be dangerous.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://docs.docker.com/engine/reference/commandline/exec/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"5.23\"\n  tag \"cis_control\": \"5 Controlled Use of Administration Privileges\\n\"\n  tag \"cis_level\": \"Level 2 - Docker\"\n  tag \"nist\": [\"AC-6\"]\n  tag \"audit\": \"If you have auditing enabled as prescribed in Section 1, you\ncan use the below command to\\nfilter out docker exec commands that used --user\noption.\\nausearch -k docker | grep exec | grep user\\n\"\n  tag \"fix\": \"Do not use --user option in docker exec command.\\n\"\n  tag \"Default Value\": \"By default, docker exec command runs without --user\noption.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-5.23.rb",
        "line": 1
      },
      "id": "M-5.23"
    },
    {
      "title": "5.24 Ensure cgroup usage is confirmed (Scored)",
      "desc": "It is possible to attach to a particular cgroup on container run.\nConfirming cgroup usage\n    would ensure that containers are running under defined cgroups.\n    System administrators typically define cgroups under which containers are\nsupposed to\n    run. Even if cgroups are not explicitly defined by the system\nadministrators, containers run\n    under docker cgroup by default.\n    At run-time, it is possible to attach to a different cgroup other than the\none that was\n    expected to be used. This usage should be monitored and confirmed. By\nattaching to a\n    different cgroup than the one that is expected, excess permissions and\nresources might be\n    granted to the container and thus, can prove to be unsafe.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://docs.docker.com/engine/reference/run/#specify-custom-cgroups\n2.\nhttps://access.redhat.com/documentation/enUS/Red_Hat_Enterprise_Linux/6/html/Resource_Management_Guide/ch01.html\n",
        "severity": "medium",
        "cis_id": "5.24",
        "cis_control": "18 Application Software Security\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "SI-1"
        ],
        "audit": "docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}:\nCgroupParent={{ .HostConfig.CgroupParent }}'\nThe above command would\nreturn the cgroup under which the containers are running. If it\nis blank, it\nmeans containers are running under default docker cgroup. In that case,\nthis\nrecommendation is compliant. If the containers are found to be running\nunder cgroup\nother than the one that was expected, this recommendation is\nnon-compliant.\n",
        "fix": "Do not use --cgroup-parent option in docker run command unless\nneeded.\n",
        "Default Value": "By default, containers run under docker cgroup.\n"
      },
      "code": "control \"M-5.24\" do\n  title \"5.24 Ensure cgroup usage is confirmed (Scored)\"\n  desc  \"\n    It is possible to attach to a particular cgroup on container run.\nConfirming cgroup usage\n    would ensure that containers are running under defined cgroups.\n    System administrators typically define cgroups under which containers are\nsupposed to\n    run. Even if cgroups are not explicitly defined by the system\nadministrators, containers run\n    under docker cgroup by default.\n    At run-time, it is possible to attach to a different cgroup other than the\none that was\n    expected to be used. This usage should be monitored and confirmed. By\nattaching to a\n    different cgroup than the one that is expected, excess permissions and\nresources might be\n    granted to the container and thus, can prove to be unsafe.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://docs.docker.com/engine/reference/run/#specify-custom-cgroups\\n2.\nhttps://access.redhat.com/documentation/enUS/Red_Hat_Enterprise_Linux/6/html/Resource_Management_Guide/ch01.html\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"5.24\"\n  tag \"cis_control\": \"18 Application Software Security\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"SI-1\"]\n  tag \"audit\": \"docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}:\\nCgroupParent={{ .HostConfig.CgroupParent }}'\\nThe above command would\nreturn the cgroup under which the containers are running. If it\\nis blank, it\nmeans containers are running under default docker cgroup. In that case,\nthis\\nrecommendation is compliant. If the containers are found to be running\nunder cgroup\\nother than the one that was expected, this recommendation is\nnon-compliant.\\n\"\n  tag \"fix\": \"Do not use --cgroup-parent option in docker run command unless\nneeded.\\n\"\n  tag \"Default Value\": \"By default, containers run under docker cgroup.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-5.24.rb",
        "line": 1
      },
      "id": "M-5.24"
    },
    {
      "title": "5.25 Ensure the container is restricted from acquiring\nadditional\nprivileges (Scored)",
      "desc": "Restrict the container from acquiring additional privileges via suid or\nsgid bits.\n    A process can set the no_new_priv bit in the kernel. It persists across\nfork, clone and\n    execve. The no_new_priv bit ensures that the process or its children\nprocesses do not gain\n    any additional privileges via suid or sgid bits. This way a lot of\ndangerous operations\n    become a lot less dangerous because there is no possibility of subverting\nprivileged\n    binaries.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://github.com/projectatomic/atomic-site/issues/269\n2.\n3.\n4.\n5.\nhttps://github.com/docker/docker/pull/20727\nhttps://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt\nhttps://lwn.net/Articles/475678/\nhttps://lwn.net/Articles/475362/\n",
        "severity": "medium",
        "cis_id": "5.25",
        "cis_control": "5 Controlled Use of Administration Privileges\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "AC-6"
        ],
        "audit": "docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}:\nSecurityOpt={{ .HostConfig.SecurityOpt }}'\nThe above command should\nreturn all the security options currently configured for the\ncontainers.\nno-new-privileges should also be one of them.\n",
        "fix": "For example, you should start your container as below:\ndocker\nrun --rm -it --security-opt=no-new-privileges ubuntu bash\n",
        "Default Value": "By default, new privileges are not restricted.\n"
      },
      "code": "control \"M-5.25\" do\n  title \"5.25 Ensure the container is restricted from acquiring\nadditional\\nprivileges (Scored)\"\n  desc  \"\n    Restrict the container from acquiring additional privileges via suid or\nsgid bits.\n    A process can set the no_new_priv bit in the kernel. It persists across\nfork, clone and\n    execve. The no_new_priv bit ensures that the process or its children\nprocesses do not gain\n    any additional privileges via suid or sgid bits. This way a lot of\ndangerous operations\n    become a lot less dangerous because there is no possibility of subverting\nprivileged\n    binaries.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://github.com/projectatomic/atomic-site/issues/269\\n2.\\n3.\\n4.\\n5.\\nhttps://github.com/docker/docker/pull/20727\\nhttps://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt\\nhttps://lwn.net/Articles/475678/\\nhttps://lwn.net/Articles/475362/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"5.25\"\n  tag \"cis_control\": \"5 Controlled Use of Administration Privileges\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"AC-6\"]\n  tag \"audit\": \"docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}:\\nSecurityOpt={{ .HostConfig.SecurityOpt }}'\\nThe above command should\nreturn all the security options currently configured for the\\ncontainers.\nno-new-privileges should also be one of them.\\n\"\n  tag \"fix\": \"For example, you should start your container as below:\\ndocker\nrun --rm -it --security-opt=no-new-privileges ubuntu bash\\n\"\n  tag \"Default Value\": \"By default, new privileges are not restricted.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-5.25.rb",
        "line": 1
      },
      "id": "M-5.25"
    },
    {
      "title": "5.26 Ensure container health is checked at runtime (Scored)",
      "desc": "If the container image does not have an HEALTHCHECK instruction defined,\nuse --health-cmd\n    parameter at container runtime for checking container health.\n    One of the important security triads is availability. If the container\nimage you are using\n    does not have a pre-defined HEALTHCHECK instruction, use the --health-cmd\nparameter to\n    check container health at runtime.\n    Based on the reported health status, you could take necessary actions.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://docs.docker.com/engine/reference/run/#healthcheck\n",
        "severity": "medium",
        "cis_id": "5.26",
        "cis_control": "18 Application Software Security\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "SI-1"
        ],
        "audit": "Run the below command and ensure that all the containers are\nreporting health status:\ndocker ps --quiet | xargs docker inspect --format '{{\n.Id }}: Health={{\n.State.Health.Status }}'\n",
        "fix": "Run the container using --health-cmd and the other\nparameters.\nFor example,\ndocker run -d --health-cmd='stat /etc/passwd || exit\n1' nginx\n",
        "Default Value": "By default, health checks are not done at container\nruntime.\n"
      },
      "code": "control \"M-5.26\" do\n  title \"5.26 Ensure container health is checked at runtime (Scored)\"\n  desc  \"\n    If the container image does not have an HEALTHCHECK instruction defined,\nuse --health-cmd\n    parameter at container runtime for checking container health.\n    One of the important security triads is availability. If the container\nimage you are using\n    does not have a pre-defined HEALTHCHECK instruction, use the --health-cmd\nparameter to\n    check container health at runtime.\n    Based on the reported health status, you could take necessary actions.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://docs.docker.com/engine/reference/run/#healthcheck\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"5.26\"\n  tag \"cis_control\": \"18 Application Software Security\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"SI-1\"]\n  tag \"audit\": \"Run the below command and ensure that all the containers are\nreporting health status:\\ndocker ps --quiet | xargs docker inspect --format '{{\n.Id }}: Health={{\\n.State.Health.Status }}'\\n\"\n  tag \"fix\": \"Run the container using --health-cmd and the other\nparameters.\\nFor example,\\ndocker run -d --health-cmd='stat /etc/passwd || exit\n1' nginx\\n\"\n  tag \"Default Value\": \"By default, health checks are not done at container\nruntime.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-5.26.rb",
        "line": 1
      },
      "id": "M-5.26"
    },
    {
      "title": "5.27 Ensure docker commands always get the latest version of\nthe\nimage (Not Scored)",
      "desc": "Always ensure that you are using the latest version of the image within\nyour repository and\n    not the cached older versions.\n    Multiple docker commands such as docker pull, docker run, etc. are known to\nhave an\n    issue that by default, they extract the local copy of the image, if\npresent, even though there\n    is an updated version of the image with the \"same tag\" in the upstream\nrepository. This\n    could lead to using older and vulnerable images.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://github.com/docker/docker/pull/16609\n",
        "severity": "medium",
        "cis_id": "5.27",
        "cis_control": "18.1 Use Only Vendor-supported Software\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "SI-2"
        ],
        "audit": "Step 1: Open your image repository and list the image version\nhistory for the image you\nare inspecting.\nStep 2: Observe the status when the\ndocker pull command is triggered.\nIf the status is shown as Image is up to\ndate, it means that you are getting the cached\nversion of the image.\nStep 3:\nMatch the version of the image you are running with the latest version reported\nin\nyour repository which tells if you are running the cached version or the\nlatest copy.\n",
        "fix": "Use proper version pinning mechanisms (the latest tag which is\nassigned by default is still\nvulnerable to caching attacks) to avoid\nextracting the cached older versions. Version\npinning mechanisms should be\nused for base images, packages, and entire images too. You\ncan customize\nversion pinning rules as per your requirements.\n",
        "Default Value": "By default, docker commands extract the local copy\nunless version pinning mechanisms are\nused or the local cache is cleared.\n"
      },
      "code": "control \"M-5.27\" do\n  title \"5.27 Ensure docker commands always get the latest version of\nthe\\nimage (Not Scored)\"\n  desc  \"\n    Always ensure that you are using the latest version of the image within\nyour repository and\n    not the cached older versions.\n    Multiple docker commands such as docker pull, docker run, etc. are known to\nhave an\n    issue that by default, they extract the local copy of the image, if\npresent, even though there\n    is an updated version of the image with the \\\"same tag\\\" in the upstream\nrepository. This\n    could lead to using older and vulnerable images.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://github.com/docker/docker/pull/16609\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"5.27\"\n  tag \"cis_control\": \"18.1 Use Only Vendor-supported Software\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"SI-2\"]\n  tag \"audit\": \"Step 1: Open your image repository and list the image version\nhistory for the image you\\nare inspecting.\\nStep 2: Observe the status when the\ndocker pull command is triggered.\\nIf the status is shown as Image is up to\ndate, it means that you are getting the cached\\nversion of the image.\\nStep 3:\nMatch the version of the image you are running with the latest version reported\nin\\nyour repository which tells if you are running the cached version or the\nlatest copy.\\n\"\n  tag \"fix\": \"Use proper version pinning mechanisms (the latest tag which is\nassigned by default is still\\nvulnerable to caching attacks) to avoid\nextracting the cached older versions. Version\\npinning mechanisms should be\nused for base images, packages, and entire images too. You\\ncan customize\nversion pinning rules as per your requirements.\\n\"\n  tag \"Default Value\": \"By default, docker commands extract the local copy\nunless version pinning mechanisms are\\nused or the local cache is cleared.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-5.27.rb",
        "line": 1
      },
      "id": "M-5.27"
    },
    {
      "title": "5.28 Ensure PIDs cgroup limit is used (Scored)",
      "desc": "Use --pids-limit flag at container runtime.\n    Attackers could launch a fork bomb with a single command inside the\ncontainer. This fork\n    bomb can crash the entire system and requires a restart of the host to make\nthe system\n    functional again. PIDs cgroup --pids-limit will prevent this kind of\nattacks by restricting\n    the number of forks that can happen inside a container at a given time.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://github.com/docker/docker/pull/18697\n2.\nhttps://docs.docker.com/engine/reference/commandline/run/#options\n",
        "severity": "medium",
        "cis_id": "5.28",
        "cis_control": "18 Application Software Security\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "SI-1"
        ],
        "audit": "Run the below command and ensure that PidsLimit is not set to 0\nor -1. A PidsLimit of 0\nor -1 means that any number of processes can be forked\ninside the container concurrently.\ndocker ps --quiet --all | xargs docker\ninspect --format '{{ .Id }}:\nPidsLimit={{ .HostConfig.PidsLimit }}'\n",
        "fix": "Use --pids-limit flag while launching the container with an\nappropriate value.\nFor example,\ndocker run -it --pids-limit 100\n<Image_ID>\nIn the above example, the number of processes allowed to run at any\ngiven time is set to\n100. After a limit of 100 concurrently running processes\nis reached, docker would restrict\nany new process creation.\n",
        "Default Value": "The Default value for --pids-limit is 0 which means\nthere is no restriction on the number\nof forks. Also, note that PIDs cgroup\nlimit works only for the kernel versions 4.3+.\n"
      },
      "code": "control \"M-5.28\" do\n  title \"5.28 Ensure PIDs cgroup limit is used (Scored)\"\n  desc  \"\n    Use --pids-limit flag at container runtime.\n    Attackers could launch a fork bomb with a single command inside the\ncontainer. This fork\n    bomb can crash the entire system and requires a restart of the host to make\nthe system\n    functional again. PIDs cgroup --pids-limit will prevent this kind of\nattacks by restricting\n    the number of forks that can happen inside a container at a given time.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://github.com/docker/docker/pull/18697\\n2.\nhttps://docs.docker.com/engine/reference/commandline/run/#options\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"5.28\"\n  tag \"cis_control\": \"18 Application Software Security\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"SI-1\"]\n  tag \"audit\": \"Run the below command and ensure that PidsLimit is not set to 0\nor -1. A PidsLimit of 0\\nor -1 means that any number of processes can be forked\ninside the container concurrently.\\ndocker ps --quiet --all | xargs docker\ninspect --format '{{ .Id }}:\\nPidsLimit={{ .HostConfig.PidsLimit }}'\\n\"\n  tag \"fix\": \"Use --pids-limit flag while launching the container with an\nappropriate value.\\nFor example,\\ndocker run -it --pids-limit 100\n<Image_ID>\\nIn the above example, the number of processes allowed to run at any\ngiven time is set to\\n100. After a limit of 100 concurrently running processes\nis reached, docker would restrict\\nany new process creation.\\n\"\n  tag \"Default Value\": \"The Default value for --pids-limit is 0 which means\nthere is no restriction on the number\\nof forks. Also, note that PIDs cgroup\nlimit works only for the kernel versions 4.3+.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-5.28.rb",
        "line": 1
      },
      "id": "M-5.28"
    },
    {
      "title": "5.29 Ensure Docker's default bridge docker0 is not used (Not Scored)",
      "desc": "Do not use Docker's default bridge docker0. Use docker's user-defined\nnetworks for\n    container networking.\n    Docker connects virtual interfaces created in the bridge mode to a common\nbridge called\n    docker0. This default networking model is vulnerable to ARP spoofing and\nMAC flooding\n    attacks since there is no filtering applied.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://github.com/nyantec/narwhal\n2.\nhttps://arxiv.org/pdf/1501.02967\n3.\nhttps://docs.docker.com/engine/userguide/networking/\n",
        "severity": "medium",
        "cis_id": "5.29",
        "cis_control": "9 Limitation and Control of Network Ports, Protocols, and\nServices\n",
        "cis_level": "Level 2 - Docker",
        "nist": [
          "SC-7"
        ],
        "audit": "Run the below command, and verify that containers are on a\nuser-defined network and not\nthe default docker0 bridge.\ndocker network ls\n--quiet | xargs xargs docker network inspect --format '{{\n.Name }}: {{\n.Options }}'\n",
        "fix": "Follow Docker documentation and setup a user-defined network. Run\nall the containers in\nthe defined network.\n",
        "Default Value": "By default, docker runs containers on its docker0\nbridge.\n"
      },
      "code": "control \"M-5.29\" do\n  title \"5.29 Ensure Docker's default bridge docker0 is not used (Not Scored)\"\n  desc  \"\n    Do not use Docker's default bridge docker0. Use docker's user-defined\nnetworks for\n    container networking.\n    Docker connects virtual interfaces created in the bridge mode to a common\nbridge called\n    docker0. This default networking model is vulnerable to ARP spoofing and\nMAC flooding\n    attacks since there is no filtering applied.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://github.com/nyantec/narwhal\\n2.\nhttps://arxiv.org/pdf/1501.02967\\n3.\nhttps://docs.docker.com/engine/userguide/networking/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"5.29\"\n  tag \"cis_control\": \"9 Limitation and Control of Network Ports, Protocols, and\nServices\\n\"\n  tag \"cis_level\": \"Level 2 - Docker\"\n  tag \"nist\": [\"SC-7\"]\n  tag \"audit\": \"Run the below command, and verify that containers are on a\nuser-defined network and not\\nthe default docker0 bridge.\\ndocker network ls\n--quiet | xargs xargs docker network inspect --format '{{\\n.Name }}: {{\n.Options }}'\\n\"\n  tag \"fix\": \"Follow Docker documentation and setup a user-defined network. Run\nall the containers in\\nthe defined network.\\n\"\n  tag \"Default Value\": \"By default, docker runs containers on its docker0\nbridge.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-5.29.rb",
        "line": 1
      },
      "id": "M-5.29"
    },
    {
      "title": "5.3 Ensure Linux Kernel Capabilities are restricted within\ncontainers(Scored)",
      "desc": "By default, Docker starts containers with a restricted set of Linux Kernel\nCapabilities. It\n    means that any process may be granted the required capabilities instead of\nroot access.\n    Using Linux Kernel Capabilities, the processes do not have to run as root\nfor almost all the\n    specific areas where root privileges are usually needed.\n    Docker supports the addition and removal of capabilities, allowing the use\nof a non-default\n    profile. This may make Docker more secure through capability removal, or\nless secure\n    through the addition of capabilities. It is thus recommended to remove all\ncapabilities\n    except those explicitly required for your container process.\n    For example, capabilities such as below are usually not needed for\ncontainer process:\n    NET_ADMIN\n    SYS_ADMIN\n    SYS_MODULE",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://docs.docker.com/engine/security/security/#linux-kernel-capabilities\n2.\nhttp://man7.org/linux/man-pages/man7/capabilities.7.html\n3.\nhttp://www.oreilly.com/webops-perf/free/files/docker-security.pdf\n",
        "severity": "medium",
        "cis_id": "5.3",
        "cis_control": "5.1 Minimize And Sparingly Use Administrative\nPrivileges\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "AC-6 (9)"
        ],
        "audit": "docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}: CapAdd={{\n.HostConfig.CapAdd }} CapDrop={{ .HostConfig.CapDrop }}'\nVerify\nthat the added and dropped Linux Kernel Capabilities are in line with the\nones\nneeded for container process for each container instance.\n",
        "fix": "Execute the below command to add needed capabilities:\n$> docker\nrun --cap-add={\"Capability 1\",\"Capability 2\"}\nFor example,\ndocker run\n--interactive --tty --cap-add={\"NET_ADMIN\",\"SYS_ADMIN\"}\ncentos:latest\n/bin/bash\nExecute the below command to drop unneeded capabilities:\n$> docker\nrun --cap-drop={\"Capability 1\",\"Capability 2\"}\nFor example,\ndocker run\n--interactive --tty --cap-drop={\"SETUID\",\"SETGID\"}\ncentos:latest\n/bin/bash\nAlternatively,\nYou may choose to drop all\ncapabilities and add only add the needed ones:\n$> docker run --cap-drop=all\n--cap-add={\"Capability 1\",\"Capability 2\"}\nFor example,\ndocker run\n--interactive --tty --cap-drop=all --capadd={\"NET_ADMIN\",\"SYS_ADMIN\"}\ncentos:latest /bin/bash\n",
        "Default Value": "By default, below capabilities are available for\ncontainers:\nAUDIT_WRITE\nCHOWN\nDAC_OVERRIDE\nFOWNER\nFSETID\nKILL\nMKNOD\nNET_BIND_SERVICE\nNET_RAW\nSETFCAP\nSETGID\nSETPCAP\nSETUID\nSYS_CHROOT\n"
      },
      "code": "control \"M-5.3\" do\n  title \"5.3 Ensure Linux Kernel Capabilities are restricted within\ncontainers(Scored)\"\n  desc  \"\n    By default, Docker starts containers with a restricted set of Linux Kernel\nCapabilities. It\n    means that any process may be granted the required capabilities instead of\nroot access.\n    Using Linux Kernel Capabilities, the processes do not have to run as root\nfor almost all the\n    specific areas where root privileges are usually needed.\n    Docker supports the addition and removal of capabilities, allowing the use\nof a non-default\n    profile. This may make Docker more secure through capability removal, or\nless secure\n    through the addition of capabilities. It is thus recommended to remove all\ncapabilities\n    except those explicitly required for your container process.\n    For example, capabilities such as below are usually not needed for\ncontainer process:\n    NET_ADMIN\n    SYS_ADMIN\n    SYS_MODULE\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://docs.docker.com/engine/security/security/#linux-kernel-capabilities\\n2.\nhttp://man7.org/linux/man-pages/man7/capabilities.7.html\\n3.\nhttp://www.oreilly.com/webops-perf/free/files/docker-security.pdf\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"5.3\"\n  tag \"cis_control\": \"5.1 Minimize And Sparingly Use Administrative\nPrivileges\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"AC-6 (9)\"]\n  tag \"audit\": \"docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}: CapAdd={{\\n.HostConfig.CapAdd }} CapDrop={{ .HostConfig.CapDrop }}'\\nVerify\nthat the added and dropped Linux Kernel Capabilities are in line with the\nones\\nneeded for container process for each container instance.\\n\"\n  tag \"fix\": \"Execute the below command to add needed capabilities:\\n$> docker\nrun --cap-add={\\\"Capability 1\\\",\\\"Capability 2\\\"}\\nFor example,\\ndocker run\n--interactive --tty --cap-add={\\\"NET_ADMIN\\\",\\\"SYS_ADMIN\\\"}\\ncentos:latest\n/bin/bash\\nExecute the below command to drop unneeded capabilities:\\n$> docker\nrun --cap-drop={\\\"Capability 1\\\",\\\"Capability 2\\\"}\\nFor example,\\ndocker run\n--interactive --tty --cap-drop={\\\"SETUID\\\",\\\"SETGID\\\"}\ncentos:latest\\n/bin/bash\\nAlternatively,\\nYou may choose to drop all\ncapabilities and add only add the needed ones:\\n$> docker run --cap-drop=all\n--cap-add={\\\"Capability 1\\\",\\\"Capability 2\\\"}\\nFor example,\\ndocker run\n--interactive --tty --cap-drop=all --capadd={\\\"NET_ADMIN\\\",\\\"SYS_ADMIN\\\"}\ncentos:latest /bin/bash\\n\"\n  tag \"Default Value\": \"By default, below capabilities are available for\ncontainers:\\nAUDIT_WRITE\\nCHOWN\\nDAC_OVERRIDE\\nFOWNER\\nFSETID\\nKILL\\nMKNOD\\nNET_BIND_SERVICE\\nNET_RAW\\nSETFCAP\\nSETGID\\nSETPCAP\\nSETUID\\nSYS_CHROOT\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-5.3.rb",
        "line": 1
      },
      "id": "M-5.3"
    },
    {
      "title": "5.30 Ensure the host's user namespaces is not shared (Scored)",
      "desc": "Do not share the host's user namespaces with the containers.\n    User namespaces ensure that a root process inside the container will be\nmapped to a nonroot process outside the container. Sharing the user namespaces\nof the host with the\n    container thus does not isolate users on the host with users on the\ncontainers.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://docs.docker.com/engine/security/userns-remap/\n2.\nhttps://docs.docker.com/engine/reference/commandline/run/#options\n3.\nhttps://github.com/docker/docker/pull/12648\n4.\nhttps://events.linuxfoundation.org/sites/events/files/slides/User%20Namespaces\n%20-%20ContainerCon%202015%20-%2016-9-final_0.pdf\n",
        "severity": "medium",
        "cis_id": "5.30",
        "cis_control": "12 Boundary Defense\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "SC-7"
        ],
        "audit": "Run the below command and ensure that it does not return any\nvalue for UsernsMode. If it\nreturns a value of host, it means the host user\nnamespace is shared with the containers.\ndocker ps --quiet --all | xargs\ndocker inspect --format '{{ .Id }}:\nUsernsMode={{ .HostConfig.UsernsMode }}'\n",
        "fix": "Do not share user namespaces between host and containers.\nFor\nexample, do not run a container as below:\ndocker run --rm -it --userns=host\nubuntu bash\n",
        "Default Value": "By default, the host user namespace is shared with the\ncontainers until user namespace\nsupport is enabled.\n"
      },
      "code": "control \"M-5.30\" do\n  title \"5.30 Ensure the host's user namespaces is not shared (Scored)\"\n  desc  \"\n    Do not share the host's user namespaces with the containers.\n    User namespaces ensure that a root process inside the container will be\nmapped to a nonroot process outside the container. Sharing the user namespaces\nof the host with the\n    container thus does not isolate users on the host with users on the\ncontainers.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://docs.docker.com/engine/security/userns-remap/\\n2.\nhttps://docs.docker.com/engine/reference/commandline/run/#options\\n3.\nhttps://github.com/docker/docker/pull/12648\\n4.\nhttps://events.linuxfoundation.org/sites/events/files/slides/User%20Namespaces\\n%20-%20ContainerCon%202015%20-%2016-9-final_0.pdf\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"5.30\"\n  tag \"cis_control\": \"12 Boundary Defense\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"SC-7\"]\n  tag \"audit\": \"Run the below command and ensure that it does not return any\nvalue for UsernsMode. If it\\nreturns a value of host, it means the host user\nnamespace is shared with the containers.\\ndocker ps --quiet --all | xargs\ndocker inspect --format '{{ .Id }}:\\nUsernsMode={{ .HostConfig.UsernsMode }}'\\n\"\n  tag \"fix\": \"Do not share user namespaces between host and containers.\\nFor\nexample, do not run a container as below:\\ndocker run --rm -it --userns=host\nubuntu bash\\n\"\n  tag \"Default Value\": \"By default, the host user namespace is shared with the\ncontainers until user namespace\\nsupport is enabled.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-5.30.rb",
        "line": 1
      },
      "id": "M-5.30"
    },
    {
      "title": "5.31 Ensure the Docker socket is not mounted inside any\ncontainers(Scored)",
      "desc": "The docker socket docker.sock should not be mounted inside a container.\n    If the docker socket is mounted inside a container it would allow processes\nrunning within\n    the container to execute docker commands which effectively allows for full\ncontrol of the\n    host.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://raesene.github.io/blog/2016/03/06/The-Dangers-Of-Docker.sock/\n2.\nhttps://forums.docker.com/t/docker-in-docker-vs-mounting-var-run-dockersock/9450/2\n3.\nhttps://github.com/docker/docker/issues/21109\n",
        "severity": "medium",
        "cis_id": "5.31",
        "cis_control": "9 Limitation and Control of Network Ports, Protocols, and\nServices\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "SC-7"
        ],
        "audit": "docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}:\nVolumes={{ .Mounts }}' | grep docker.sock\nThe above command would return\nany instances where docker.sock had been mapped to\na container as a volume.\n",
        "fix": "Ensure that no containers mount docker.sock as a volume.\n",
        "Default Value": "By default, docker.sock is not mounted inside\ncontainers.\n"
      },
      "code": "control \"M-5.31\" do\n  title \"5.31 Ensure the Docker socket is not mounted inside any\ncontainers(Scored)\"\n  desc  \"\n    The docker socket docker.sock should not be mounted inside a container.\n    If the docker socket is mounted inside a container it would allow processes\nrunning within\n    the container to execute docker commands which effectively allows for full\ncontrol of the\n    host.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://raesene.github.io/blog/2016/03/06/The-Dangers-Of-Docker.sock/\\n2.\nhttps://forums.docker.com/t/docker-in-docker-vs-mounting-var-run-dockersock/9450/2\\n3.\nhttps://github.com/docker/docker/issues/21109\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"5.31\"\n  tag \"cis_control\": \"9 Limitation and Control of Network Ports, Protocols, and\nServices\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"SC-7\"]\n  tag \"audit\": \"docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}:\\nVolumes={{ .Mounts }}' | grep docker.sock\\nThe above command would return\nany instances where docker.sock had been mapped to\\na container as a volume.\\n\"\n  tag \"fix\": \"Ensure that no containers mount docker.sock as a volume.\\n\"\n  tag \"Default Value\": \"By default, docker.sock is not mounted inside\ncontainers.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-5.31.rb",
        "line": 1
      },
      "id": "M-5.31"
    },
    {
      "title": "5.4 Ensure privileged containers are not used (Scored)",
      "desc": "Using the --privileged flag gives all Linux Kernel Capabilities to the\ncontainer thus\n    overwriting the --cap-add and --cap-drop flags. Ensure that it is not used.\n    The --privileged flag gives all capabilities to the container, and it also\nlifts all the\n    limitations enforced by the device cgroup controller. In other words, the\ncontainer can then\n    do almost everything that the host can do. This flag exists to allow\nspecial use-cases, like\n    running Docker within Docker.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://docs.docker.com/engine/reference/run/#runtime-privilege-and-linuxcapabilities\n",
        "severity": "medium",
        "cis_id": "5.4",
        "cis_control": "5.1 Minimize And Sparingly Use Administrative\nPrivileges\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "AC-6 (9)"
        ],
        "audit": "docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}:\nPrivileged={{ .HostConfig.Privileged }}'\nThe above command should return\nPrivileged=false for each container instance.\n",
        "fix": "Do not run container with the --privileged flag.\nFor example, do\nnot start a container as below:\ndocker run --interactive --tty --privileged\ncentos /bin/bash\n",
        "Default Value": "False.\n"
      },
      "code": "control \"M-5.4\" do\n  title \"5.4 Ensure privileged containers are not used (Scored)\"\n  desc  \"\n    Using the --privileged flag gives all Linux Kernel Capabilities to the\ncontainer thus\n    overwriting the --cap-add and --cap-drop flags. Ensure that it is not used.\n    The --privileged flag gives all capabilities to the container, and it also\nlifts all the\n    limitations enforced by the device cgroup controller. In other words, the\ncontainer can then\n    do almost everything that the host can do. This flag exists to allow\nspecial use-cases, like\n    running Docker within Docker.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://docs.docker.com/engine/reference/run/#runtime-privilege-and-linuxcapabilities\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"5.4\"\n  tag \"cis_control\": \"5.1 Minimize And Sparingly Use Administrative\nPrivileges\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"AC-6 (9)\"]\n  tag \"audit\": \"docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}:\\nPrivileged={{ .HostConfig.Privileged }}'\\nThe above command should return\nPrivileged=false for each container instance.\\n\"\n  tag \"fix\": \"Do not run container with the --privileged flag.\\nFor example, do\nnot start a container as below:\\ndocker run --interactive --tty --privileged\ncentos /bin/bash\\n\"\n  tag \"Default Value\": \"False.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-5.4.rb",
        "line": 1
      },
      "id": "M-5.4"
    },
    {
      "title": "5.5 Ensure sensitive host system directories are not mounted\non\ncontainers (Scored)",
      "desc": "Sensitive host system directories such as below should not be allowed to be\nmounted as\n    container volumes especially in read-write mode.\n    /\n    /boot\n    /dev\n    /etc\n    /lib\n    /proc\n    /sys\n    /usr\n    If sensitive directories are mounted in read-write mode, it would be\npossible to make\n    changes to files within those sensitive directories. The changes might\nbring down security\n    implications or unwarranted changes that could put the Docker host in\ncompromised state.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://docs.docker.com/engine/tutorials/dockervolumes/\n",
        "severity": "medium",
        "cis_id": "5.5",
        "cis_control": "14 Controlled Access Based on the Need to Know\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "AC-6"
        ],
        "audit": "docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}:\nVolumes={{ .Mounts }}'\nThe above commands would return the list of\ncurrent mapped directories and whether\nthey are mounted in read-write mode for\neach container instance.\n",
        "fix": "Do not mount host sensitive directories on containers especially\nin read-write mode.\n",
        "Default Value": "Docker defaults to a read-write volume but you can also\nmount a directory read-only. By\ndefault, no sensitive host directories are\nmounted on containers.\n"
      },
      "code": "control \"M-5.5\" do\n  title \"5.5 Ensure sensitive host system directories are not mounted\non\\ncontainers (Scored)\"\n  desc  \"\n    Sensitive host system directories such as below should not be allowed to be\nmounted as\n    container volumes especially in read-write mode.\n    /\n    /boot\n    /dev\n    /etc\n    /lib\n    /proc\n    /sys\n    /usr\n    If sensitive directories are mounted in read-write mode, it would be\npossible to make\n    changes to files within those sensitive directories. The changes might\nbring down security\n    implications or unwarranted changes that could put the Docker host in\ncompromised state.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://docs.docker.com/engine/tutorials/dockervolumes/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"5.5\"\n  tag \"cis_control\": \"14 Controlled Access Based on the Need to Know\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"AC-6\"]\n  tag \"audit\": \"docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}:\\nVolumes={{ .Mounts }}'\\nThe above commands would return the list of\ncurrent mapped directories and whether\\nthey are mounted in read-write mode for\neach container instance.\\n\"\n  tag \"fix\": \"Do not mount host sensitive directories on containers especially\nin read-write mode.\\n\"\n  tag \"Default Value\": \"Docker defaults to a read-write volume but you can also\nmount a directory read-only. By\\ndefault, no sensitive host directories are\nmounted on containers.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-5.5.rb",
        "line": 1
      },
      "id": "M-5.5"
    },
    {
      "title": "5.6 Ensure ssh is not run within containers (Scored)",
      "desc": "SSH server should not be running within the container. You should SSH into\nthe Docker\n    host, and use nsenter tool to enter a container from a remote host.\n    Running SSH within the container increases the complexity of security\nmanagement by\n    making it\n\n\n\n    Difficult to manage access policies and security compliance for SSH server\n    Difficult to manage keys and passwords across various containers\n    Difficult to manage security upgrades for SSH server\n    It is possible to have shell access to a container without using SSH, the\nneedlessly\n    increasing the complexity of security management should be avoided.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttp://blog.docker.com/2014/06/why-you-dont-need-to-run-sshd-in-docker/\n",
        "severity": "medium",
        "cis_id": "5.6",
        "cis_control": "9.1 Limit Open Ports, Protocols, and Services\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "CM-7 (1)"
        ],
        "audit": "Step 1: List all the running instances of containers by\nexecuting below command:\ndocker ps --quiet\nStep 2: For each container\ninstance, execute the below command:\ndocker exec $INSTANCE_ID ps -el\nEnsure\nthat there is no process for SSH server.\n",
        "fix": "Uninstall SSH server from the container and use nsenteror any\nother commands such as\ndocker exec or docker attach to interact with the\ncontainer instance.\ndocker exec --interactive --tty $INSTANCE_ID\nsh\nOR\ndocker attach $INSTANCE_ID\n",
        "Default Value": "By default, SSH server is not running inside the\ncontainer. Only one process per container is\nallowed.\n"
      },
      "code": "control \"M-5.6\" do\n  title \"5.6 Ensure ssh is not run within containers (Scored)\"\n  desc  \"\n    SSH server should not be running within the container. You should SSH into\nthe Docker\n    host, and use nsenter tool to enter a container from a remote host.\n    Running SSH within the container increases the complexity of security\nmanagement by\n    making it\n\n\n\n    Difficult to manage access policies and security compliance for SSH server\n    Difficult to manage keys and passwords across various containers\n    Difficult to manage security upgrades for SSH server\n    It is possible to have shell access to a container without using SSH, the\nneedlessly\n    increasing the complexity of security management should be avoided.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttp://blog.docker.com/2014/06/why-you-dont-need-to-run-sshd-in-docker/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"5.6\"\n  tag \"cis_control\": \"9.1 Limit Open Ports, Protocols, and Services\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"CM-7 (1)\"]\n  tag \"audit\": \"Step 1: List all the running instances of containers by\nexecuting below command:\\ndocker ps --quiet\\nStep 2: For each container\ninstance, execute the below command:\\ndocker exec $INSTANCE_ID ps -el\\nEnsure\nthat there is no process for SSH server.\\n\"\n  tag \"fix\": \"Uninstall SSH server from the container and use nsenteror any\nother commands such as\\ndocker exec or docker attach to interact with the\ncontainer instance.\\ndocker exec --interactive --tty $INSTANCE_ID\nsh\\nOR\\ndocker attach $INSTANCE_ID\\n\"\n  tag \"Default Value\": \"By default, SSH server is not running inside the\ncontainer. Only one process per container is\\nallowed.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-5.6.rb",
        "line": 1
      },
      "id": "M-5.6"
    },
    {
      "title": "5.7 Ensure privileged ports are not mapped within containers (Scored)",
      "desc": "The TCP/IP port numbers below 1024are considered privileged ports. Normal\nusers and\n    processes are not allowed to use them for various security reasons. Docker\nallows a\n    container port to be mapped to a privileged port.\n    By default, if the user does not specifically declare the container port to\nhost port mapping,\n    Docker automatically and correctly maps the container port to one available\nin 4915365535 block on the host. But, Docker allows a container port to be\nmapped to a privileged\n    port on the host if the user explicitly declared it. This is so because\ncontainers are executed\n    with NET_BIND_SERVICE Linux kernel capability that does not restrict the\nprivileged port\n    mapping. The privileged ports receive and transmit various sensitive and\nprivileged data.\n    Allowing containers to use them can bring serious implications.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://docs.docker.com/engine/userguide/networking/\n",
        "severity": "medium",
        "cis_id": "5.7",
        "cis_control": "9.1 Limit Open Ports, Protocols, and Services\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "CM-7 (1)"
        ],
        "audit": "List all running containers instances and their port mapping by\nexecuting the below\ncommand:\ndocker ps --quiet | xargs docker inspect\n--format '{{ .Id }}: Ports={{\n.NetworkSettings.Ports }}'\nReview the list and\nensure that container ports are not mapped to host port numbers\nbelow 1024.\n",
        "fix": "Do not map the container ports to privileged host ports when\nstarting a container. Also,\nensure that there is no such container to host\nprivileged port mapping declarations in the\nDockerfile.\n",
        "Default Value": "By default, mapping a container port to a privileged\nport on the host is allowed.\nNote: There might be certain cases where you want\nto map privileged ports, because if you\nforbid it, then the corresponding\napplication has to run outside of a container.\nFor example: HTTP and HTTPS\nload balancers have to bind 80/tcp and 443/tcp\nrespectively. Forbidding to map\nprivileged ports effectively forbids from running those in a\ncontainer, and\nmandates using an external load balancer. In such cases, those\ncontainers\ninstances should be marked as exceptions for this recommendation.\n"
      },
      "code": "control \"M-5.7\" do\n  title \"5.7 Ensure privileged ports are not mapped within containers (Scored)\"\n  desc  \"\n    The TCP/IP port numbers below 1024are considered privileged ports. Normal\nusers and\n    processes are not allowed to use them for various security reasons. Docker\nallows a\n    container port to be mapped to a privileged port.\n    By default, if the user does not specifically declare the container port to\nhost port mapping,\n    Docker automatically and correctly maps the container port to one available\nin 4915365535 block on the host. But, Docker allows a container port to be\nmapped to a privileged\n    port on the host if the user explicitly declared it. This is so because\ncontainers are executed\n    with NET_BIND_SERVICE Linux kernel capability that does not restrict the\nprivileged port\n    mapping. The privileged ports receive and transmit various sensitive and\nprivileged data.\n    Allowing containers to use them can bring serious implications.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://docs.docker.com/engine/userguide/networking/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"5.7\"\n  tag \"cis_control\": \"9.1 Limit Open Ports, Protocols, and Services\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"CM-7 (1)\"]\n  tag \"audit\": \"List all running containers instances and their port mapping by\nexecuting the below\\ncommand:\\ndocker ps --quiet | xargs docker inspect\n--format '{{ .Id }}: Ports={{\\n.NetworkSettings.Ports }}'\\nReview the list and\nensure that container ports are not mapped to host port numbers\\nbelow 1024.\\n\"\n  tag \"fix\": \"Do not map the container ports to privileged host ports when\nstarting a container. Also,\\nensure that there is no such container to host\nprivileged port mapping declarations in the\\nDockerfile.\\n\"\n  tag \"Default Value\": \"By default, mapping a container port to a privileged\nport on the host is allowed.\\nNote: There might be certain cases where you want\nto map privileged ports, because if you\\nforbid it, then the corresponding\napplication has to run outside of a container.\\nFor example: HTTP and HTTPS\nload balancers have to bind 80/tcp and 443/tcp\\nrespectively. Forbidding to map\nprivileged ports effectively forbids from running those in a\\ncontainer, and\nmandates using an external load balancer. In such cases, those\ncontainers\\ninstances should be marked as exceptions for this recommendation.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-5.7.rb",
        "line": 1
      },
      "id": "M-5.7"
    },
    {
      "title": "5.8 Ensure only needed ports are open on the container (Scored)",
      "desc": "Dockerfile for a container image defines the ports to be opened by default\non a container\n    instance. The list of ports may or may not be relevant to the application\nyou are running\n    within the container.\n    A container can be run just with the ports defined in the Dockerfile for\nits image or can be\n    arbitrarily passed run time parameters to open a list of ports.\nAdditionally, Overtime,\n    Dockerfile may undergo various changes and the list of exposed ports may or\nmay not be\n    relevant to the application you are running within the container. Opening\nunneeded ports\n    increase the attack surface of the container and the containerized\napplication. As a\n    recommended practice, do not open unneeded ports.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://docs.docker.com/engine/userguide/networking/\n",
        "severity": "medium",
        "cis_id": "5.8",
        "cis_control": "9.1 Limit Open Ports, Protocols, and Services\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "CM-7 (1)"
        ],
        "audit": "List all the running instances of containers and their port\nmapping by executing the below\ncommand:\ndocker ps --quiet | xargs docker\ninspect --format '{{ .Id }}: Ports={{\n.NetworkSettings.Ports }}'\nReview the\nlist and ensure that the ports mapped are the ones that are really needed\nfor\nthe container.\n",
        "fix": "Fix the Dockerfile of the container image to expose only needed\nports by your\ncontainerized application. You can also completely ignore the\nlist of ports defined in the\nDockerfile by NOT using -P (UPPERCASE) or\n--publish-all flag when starting the\ncontainer. Use the -p (lowercase) or\n--publish flag to explicitly define the ports that you\nneed for a particular\ncontainer instance.\nFor example,\ndocker run --interactive --tty --publish\n5000 --publish 5001 --publish 5002\ncentos /bin/bash\n",
        "Default Value": "By default, all the ports that are listed in the\nDockerfile under EXPOSE instruction for an\nimage are opened when a container\nis run with -P or --publish-all flag.\n"
      },
      "code": "control \"M-5.8\" do\n  title \"5.8 Ensure only needed ports are open on the container (Scored)\"\n  desc  \"\n    Dockerfile for a container image defines the ports to be opened by default\non a container\n    instance. The list of ports may or may not be relevant to the application\nyou are running\n    within the container.\n    A container can be run just with the ports defined in the Dockerfile for\nits image or can be\n    arbitrarily passed run time parameters to open a list of ports.\nAdditionally, Overtime,\n    Dockerfile may undergo various changes and the list of exposed ports may or\nmay not be\n    relevant to the application you are running within the container. Opening\nunneeded ports\n    increase the attack surface of the container and the containerized\napplication. As a\n    recommended practice, do not open unneeded ports.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://docs.docker.com/engine/userguide/networking/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"5.8\"\n  tag \"cis_control\": \"9.1 Limit Open Ports, Protocols, and Services\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"CM-7 (1)\"]\n  tag \"audit\": \"List all the running instances of containers and their port\nmapping by executing the below\\ncommand:\\ndocker ps --quiet | xargs docker\ninspect --format '{{ .Id }}: Ports={{\\n.NetworkSettings.Ports }}'\\nReview the\nlist and ensure that the ports mapped are the ones that are really needed\nfor\\nthe container.\\n\"\n  tag \"fix\": \"Fix the Dockerfile of the container image to expose only needed\nports by your\\ncontainerized application. You can also completely ignore the\nlist of ports defined in the\\nDockerfile by NOT using -P (UPPERCASE) or\n--publish-all flag when starting the\\ncontainer. Use the -p (lowercase) or\n--publish flag to explicitly define the ports that you\\nneed for a particular\ncontainer instance.\\nFor example,\\ndocker run --interactive --tty --publish\n5000 --publish 5001 --publish 5002\\ncentos /bin/bash\\n\"\n  tag \"Default Value\": \"By default, all the ports that are listed in the\nDockerfile under EXPOSE instruction for an\\nimage are opened when a container\nis run with -P or --publish-all flag.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-5.8.rb",
        "line": 1
      },
      "id": "M-5.8"
    },
    {
      "title": "5.9 Ensure the host's network namespace is not shared (Scored)",
      "desc": "The networking mode on a container when set to --net=host, skips placing\nthe container\n    inside separate network stack. In essence, this choice tells Docker to not\ncontainerize the\n    container's networking. This would network-wise mean that the container\nlives \"outside\"\n    in the main Docker host and has full access to its network interfaces.\n    This is potentially dangerous. It allows the container process to open\nlow-numbered ports\n    like any other root process. It also allows the container to access network\nservices like Dbus on the Docker host. Thus, a container process can\npotentially do unexpected things\n    such as shutting down the Docker host. You should not use this option.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://docs.docker.com/engine/userguide/networking/\n2.\nhttps://docs.docker.com/engine/reference/run/#network-settings\n",
        "severity": "medium",
        "cis_id": "5.9",
        "cis_control": "12 Boundary Defense\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "SC-7"
        ],
        "audit": "docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}:\nNetworkMode={{ .HostConfig.NetworkMode }}'\nIf the above command returns\nNetworkMode=host, it means that --net=host option was\npassed when container\nwas started. This would be non-compliant.\n",
        "fix": "Do not pass --net=host option when starting the container.\n",
        "Default Value": "By default, container connects to Docker bridge.\n"
      },
      "code": "control \"M-5.9\" do\n  title \"5.9 Ensure the host's network namespace is not shared (Scored)\"\n  desc  \"\n    The networking mode on a container when set to --net=host, skips placing\nthe container\n    inside separate network stack. In essence, this choice tells Docker to not\ncontainerize the\n    container's networking. This would network-wise mean that the container\nlives \\\"outside\\\"\n    in the main Docker host and has full access to its network interfaces.\n    This is potentially dangerous. It allows the container process to open\nlow-numbered ports\n    like any other root process. It also allows the container to access network\nservices like Dbus on the Docker host. Thus, a container process can\npotentially do unexpected things\n    such as shutting down the Docker host. You should not use this option.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://docs.docker.com/engine/userguide/networking/\\n2.\nhttps://docs.docker.com/engine/reference/run/#network-settings\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"5.9\"\n  tag \"cis_control\": \"12 Boundary Defense\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"SC-7\"]\n  tag \"audit\": \"docker ps --quiet --all | xargs docker inspect --format '{{ .Id\n}}:\\nNetworkMode={{ .HostConfig.NetworkMode }}'\\nIf the above command returns\nNetworkMode=host, it means that --net=host option was\\npassed when container\nwas started. This would be non-compliant.\\n\"\n  tag \"fix\": \"Do not pass --net=host option when starting the container.\\n\"\n  tag \"Default Value\": \"By default, container connects to Docker bridge.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-5.9.rb",
        "line": 1
      },
      "id": "M-5.9"
    },
    {
      "title": "6.1 Ensure image sprawl is avoided (Not Scored)",
      "desc": "Do not keep a large number of container images on the same host. Use only\ntagged images\n    as appropriate.\n    Tagged images are useful to fall back from \"latest\" to a specific version\nof an image in\n    production. Images with unused or old tags may contain vulnerabilities that\nmight be\n    exploited, if instantiated. Additionally, if you fail to remove unused\nimages from the system\n    and there are various such redundant and unused images, the host filesystem\nmay become\n    full and could lead to denial of service.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttp://craiccomputing.blogspot.in/2014/09/clean-up-unused-docker-containersand.html\n2.\nhttps://forums.docker.com/t/command-to-remove-all-unused-images/20/8\n3.\nhttps://github.com/docker/docker/issues/9054\n4.\nhttps://docs.docker.com/engine/reference/commandline/rmi/\n5.\nhttps://docs.docker.com/engine/reference/commandline/pull/\n6.\nhttps://github.com/docker/docker/pull/11109\n",
        "severity": "medium",
        "cis_id": "6.1",
        "cis_control": "18 Application Software Security\n",
        "cis_level": "Level 1 - Linux Host OS",
        "nist": [
          "SI-1"
        ],
        "audit": "Step 1 Make a list of all image IDs that are currently\ninstantiated by executing below\ncommand:\ndocker images --quiet | xargs docker\ninspect --format '{{ .Id }}: Image={{\n.Config.Image }}'\nStep 2: List all the\nimages present on the system by executing below command:\ndocker images\nStep\n3: Compare the list of image IDs populated from Step 1 and Step 2 and find out\nimages\nthat are currently not being instantiated. If any such unused or old\nimages are found,\ndiscuss with the system administrator the need to keep such\nimages on the system. If such\na need is not justified enough, then this\nrecommendation is non-compliant.\n",
        "fix": "Keep the set of the images that you actually need and establish a\nworkflow to remove old or\nstale images from the host. Additionally, use\nfeatures such as pull-by-digest to get specific\nimages from the\nregistry.\nAdditionally, you can follow below set of steps to find out unused\nimages on the system and\ndelete them.\nStep 1 Make a list of all image IDs\nthat are currently instantiated by executing below\ncommand:\ndocker images\n--quiet | xargs docker inspect --format '{{ .Id }}: Image={{\n.Config.Image\n}}'\nStep 2: List all the images present on the system by executing below\ncommand:\ndocker images\nStep 3: Compare the list of image IDs populated from\nStep 1 and Step 2 and find out images\nthat are currently not being\ninstantiated.\nStep 4: Decide if you want to keep the images that are not\ncurrently in use. If not delete\nthem by executing below command:\ndocker rmi\n$IMAGE_ID\n",
        "Default Value": "Images and layered filesystems remain accessible on the\nhost until the administrator\nremoves all tags that refer to those images or\nlayers.\n"
      },
      "code": "control \"M-6.1\" do\n  title \"6.1 Ensure image sprawl is avoided (Not Scored)\"\n  desc  \"\n    Do not keep a large number of container images on the same host. Use only\ntagged images\n    as appropriate.\n    Tagged images are useful to fall back from \\\"latest\\\" to a specific version\nof an image in\n    production. Images with unused or old tags may contain vulnerabilities that\nmight be\n    exploited, if instantiated. Additionally, if you fail to remove unused\nimages from the system\n    and there are various such redundant and unused images, the host filesystem\nmay become\n    full and could lead to denial of service.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttp://craiccomputing.blogspot.in/2014/09/clean-up-unused-docker-containersand.html\\n2.\nhttps://forums.docker.com/t/command-to-remove-all-unused-images/20/8\\n3.\nhttps://github.com/docker/docker/issues/9054\\n4.\nhttps://docs.docker.com/engine/reference/commandline/rmi/\\n5.\nhttps://docs.docker.com/engine/reference/commandline/pull/\\n6.\nhttps://github.com/docker/docker/pull/11109\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"6.1\"\n  tag \"cis_control\": \"18 Application Software Security\\n\"\n  tag \"cis_level\": \"Level 1 - Linux Host OS\"\n  tag \"nist\": [\"SI-1\"]\n  tag \"audit\": \"Step 1 Make a list of all image IDs that are currently\ninstantiated by executing below\\ncommand:\\ndocker images --quiet | xargs docker\ninspect --format '{{ .Id }}: Image={{\\n.Config.Image }}'\\nStep 2: List all the\nimages present on the system by executing below command:\\ndocker images\\nStep\n3: Compare the list of image IDs populated from Step 1 and Step 2 and find out\nimages\\nthat are currently not being instantiated. If any such unused or old\nimages are found,\\ndiscuss with the system administrator the need to keep such\nimages on the system. If such\\na need is not justified enough, then this\nrecommendation is non-compliant.\\n\"\n  tag \"fix\": \"Keep the set of the images that you actually need and establish a\nworkflow to remove old or\\nstale images from the host. Additionally, use\nfeatures such as pull-by-digest to get specific\\nimages from the\nregistry.\\nAdditionally, you can follow below set of steps to find out unused\nimages on the system and\\ndelete them.\\nStep 1 Make a list of all image IDs\nthat are currently instantiated by executing below\\ncommand:\\ndocker images\n--quiet | xargs docker inspect --format '{{ .Id }}: Image={{\\n.Config.Image\n}}'\\nStep 2: List all the images present on the system by executing below\ncommand:\\ndocker images\\nStep 3: Compare the list of image IDs populated from\nStep 1 and Step 2 and find out images\\nthat are currently not being\ninstantiated.\\nStep 4: Decide if you want to keep the images that are not\ncurrently in use. If not delete\\nthem by executing below command:\\ndocker rmi\n$IMAGE_ID\\n\"\n  tag \"Default Value\": \"Images and layered filesystems remain accessible on the\nhost until the administrator\\nremoves all tags that refer to those images or\nlayers.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-6.1.rb",
        "line": 1
      },
      "id": "M-6.1"
    },
    {
      "title": "6.2 Ensure container sprawl is avoided (Not Scored)",
      "desc": "Do not keep a large number of containers on the same host.\n    The flexibility of containers makes it easy to run multiple instances of\napplications and\n    indirectly leads to Docker images that exist at varying security patch\nlevels. It also means\n    that you are consuming host resources that otherwise could have been used\nfor running\n    'useful' containers. Having more than just the manageable number of\ncontainers on a\n    particular host makes the situation vulnerable to mishandling,\nmisconfiguration and\n    fragmentation. Thus, avoid container sprawl and keep the number of\ncontainers on a host\n    to a manageable total.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://zeltser.com/security-risks-and-benefits-of-docker-application/\n2.\nhttp://searchsdn.techtarget.com/feature/Docker-networking-How-Linuxcontainers-will-change-your-network\n",
        "severity": "medium",
        "cis_id": "6.2",
        "cis_control": "18 Application Software Security\n",
        "cis_level": "Level 1 - Linux Host OS",
        "nist": [
          "SI-1"
        ],
        "audit": "Step 1 - Find the total number of containers you have on the\nhost:\ndocker info --format '{{ .Containers }}'\nStep 2 - Execute the below\ncommands to find the total number of containers that are\nactually running or\nin the stopped state on the host.\ndocker info --format '{{ .ContainersStopped\n}}'\ndocker info --format '{{ .ContainersRunning }}'\nIf the difference between\nthe number of containers that are stopped on the host and the\nnumber of\ncontainers that are actually running on the host is large (say 25 or more),\nthen\nperhaps, the containers are sprawled on the host.\n",
        "fix": "Periodically check your container inventory per host and clean up\nthe stopped containers\nusing the below command:\ndocker container prune\n",
        "Default Value": "By default, Docker does not restrict the number of\ncontainers you may have on a host.\n"
      },
      "code": "control \"M-6.2\" do\n  title \"6.2 Ensure container sprawl is avoided (Not Scored)\"\n  desc  \"\n    Do not keep a large number of containers on the same host.\n    The flexibility of containers makes it easy to run multiple instances of\napplications and\n    indirectly leads to Docker images that exist at varying security patch\nlevels. It also means\n    that you are consuming host resources that otherwise could have been used\nfor running\n    'useful' containers. Having more than just the manageable number of\ncontainers on a\n    particular host makes the situation vulnerable to mishandling,\nmisconfiguration and\n    fragmentation. Thus, avoid container sprawl and keep the number of\ncontainers on a host\n    to a manageable total.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://zeltser.com/security-risks-and-benefits-of-docker-application/\\n2.\nhttp://searchsdn.techtarget.com/feature/Docker-networking-How-Linuxcontainers-will-change-your-network\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"6.2\"\n  tag \"cis_control\": \"18 Application Software Security\\n\"\n  tag \"cis_level\": \"Level 1 - Linux Host OS\"\n  tag \"nist\": [\"SI-1\"]\n  tag \"audit\": \"Step 1 - Find the total number of containers you have on the\nhost:\\ndocker info --format '{{ .Containers }}'\\nStep 2 - Execute the below\ncommands to find the total number of containers that are\\nactually running or\nin the stopped state on the host.\\ndocker info --format '{{ .ContainersStopped\n}}'\\ndocker info --format '{{ .ContainersRunning }}'\\nIf the difference between\nthe number of containers that are stopped on the host and the\\nnumber of\ncontainers that are actually running on the host is large (say 25 or more),\nthen\\nperhaps, the containers are sprawled on the host.\\n\"\n  tag \"fix\": \"Periodically check your container inventory per host and clean up\nthe stopped containers\\nusing the below command:\\ndocker container prune\\n\"\n  tag \"Default Value\": \"By default, Docker does not restrict the number of\ncontainers you may have on a host.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-6.2.rb",
        "line": 1
      },
      "id": "M-6.2"
    },
    {
      "title": "7.1 Ensure swarm mode is not Enabled, if not needed (Scored)",
      "desc": "Do not enable swarm mode on a docker engine instance unless needed.\n    By default, a Docker engine instance will not listen on any network ports,\nwith all\n    communications with the client coming over the Unix socket. When Docker\nswarm mode is\n    enabled on a docker engine instance, multiple network ports are opened on\nthe system and\n    made available to other systems on the network for the purposes of cluster\nmanagement\n    and node communications.\n    Opening network ports on a system increase its attack surface and this\nshould be avoided\n    unless required.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://docs.docker.com/engine/reference/commandline/swarm_init/\n",
        "severity": "medium",
        "cis_id": "7.1",
        "cis_control": "9.1 Limit Open Ports, Protocols, and Services\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "CM-7 (1)"
        ],
        "audit": "Review the output of the docker info command. If the output\nincludes Swarm: active it\nindicates that swarm mode has been activated on the\nDocker engine. Confirm if swarm\nmode on the docker engine instance is actually\nneeded.\n",
        "fix": "If swarm mode has been enabled on a system in error, run\ndocker\nswarm leave\n",
        "Default Value": "By default, docker swarm mode is not enabled.\n"
      },
      "code": "control \"M-7.1\" do\n  title \"7.1 Ensure swarm mode is not Enabled, if not needed (Scored)\"\n  desc  \"\n    Do not enable swarm mode on a docker engine instance unless needed.\n    By default, a Docker engine instance will not listen on any network ports,\nwith all\n    communications with the client coming over the Unix socket. When Docker\nswarm mode is\n    enabled on a docker engine instance, multiple network ports are opened on\nthe system and\n    made available to other systems on the network for the purposes of cluster\nmanagement\n    and node communications.\n    Opening network ports on a system increase its attack surface and this\nshould be avoided\n    unless required.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://docs.docker.com/engine/reference/commandline/swarm_init/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"7.1\"\n  tag \"cis_control\": \"9.1 Limit Open Ports, Protocols, and Services\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"CM-7 (1)\"]\n  tag \"audit\": \"Review the output of the docker info command. If the output\nincludes Swarm: active it\\nindicates that swarm mode has been activated on the\nDocker engine. Confirm if swarm\\nmode on the docker engine instance is actually\nneeded.\\n\"\n  tag \"fix\": \"If swarm mode has been enabled on a system in error, run\\ndocker\nswarm leave\\n\"\n  tag \"Default Value\": \"By default, docker swarm mode is not enabled.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-7.1.rb",
        "line": 1
      },
      "id": "M-7.1"
    },
    {
      "title": "7.10 Ensure management plane traffic has been separated from\ndata\nplane traffic (Not Scored)",
      "desc": "Separate management plane traffic from data plane traffic.\n    Separating the management plane traffic from data plane traffic ensures\nthat these traffics\n    are on their respective paths. These paths could then be individually\nmonitored and could\n    be tied to different traffic control policies and monitoring. It also\nensures that management\n    plane is always reachable despite the huge volume of data flow.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://docs.docker.com/engine/reference/commandline/swarm_init/#--datapath-addr\n2.\nhttps://github.com/moby/moby/issues/33938\n3.\nhttps://github.com/moby/moby/pull/32717\n",
        "severity": "medium",
        "cis_id": "7.10",
        "cis_control": "18 Application Software Security\n",
        "cis_level": "Level 2 - Docker",
        "nist": [
          "SI-1"
        ],
        "audit": "Run the below command on each swarm node and ensure that the\nmanagement plane\naddress is different from data plane address.\ndocker node\ninspect\n--format '{{ .Status.Addr }}' self\nNote: At the time of writing of\nthis benchmark, there is no way to inspect data plane\naddress. An issue has\nbeen raised and is in the reference link.\n",
        "fix": "Initialize Swarm with dedicated interfaces for management and\ndata planes respectively.\nFor example,\ndocker swarm init\n--advertise-addr=192.168.0.1 --data-path-addr=17.1.0.3\n",
        "Default Value": "By default, the data plane traffic is not separated\nfrom management plane traffic.\n"
      },
      "code": "control \"M-7.10\" do\n  title \"7.10 Ensure management plane traffic has been separated from\ndata\\nplane traffic (Not Scored)\"\n  desc  \"\n    Separate management plane traffic from data plane traffic.\n    Separating the management plane traffic from data plane traffic ensures\nthat these traffics\n    are on their respective paths. These paths could then be individually\nmonitored and could\n    be tied to different traffic control policies and monitoring. It also\nensures that management\n    plane is always reachable despite the huge volume of data flow.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://docs.docker.com/engine/reference/commandline/swarm_init/#--datapath-addr\\n2.\nhttps://github.com/moby/moby/issues/33938\\n3.\nhttps://github.com/moby/moby/pull/32717\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"7.10\"\n  tag \"cis_control\": \"18 Application Software Security\\n\"\n  tag \"cis_level\": \"Level 2 - Docker\"\n  tag \"nist\": [\"SI-1\"]\n  tag \"audit\": \"Run the below command on each swarm node and ensure that the\nmanagement plane\\naddress is different from data plane address.\\ndocker node\ninspect\\n--format '{{ .Status.Addr }}' self\\nNote: At the time of writing of\nthis benchmark, there is no way to inspect data plane\\naddress. An issue has\nbeen raised and is in the reference link.\\n\"\n  tag \"fix\": \"Initialize Swarm with dedicated interfaces for management and\ndata planes respectively.\\nFor example,\\ndocker swarm init\n--advertise-addr=192.168.0.1 --data-path-addr=17.1.0.3\\n\"\n  tag \"Default Value\": \"By default, the data plane traffic is not separated\nfrom management plane traffic.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-7.10.rb",
        "line": 1
      },
      "id": "M-7.10"
    },
    {
      "title": "7.2 Ensure the minimum number of manager nodes have been created\nin a\nswarm (Scored)",
      "desc": "Ensure that the minimum number of required manager nodes is created in a\nswarm.\n    Manager nodes within a swarm have control over the swarm and change its\nconfiguration\n    modifying security parameters. Having excessive manager nodes could render\nthe swarm\n    more susceptible to compromise.\n    If fault tolerance is not required in the manager nodes, a single node\nshould be elected as a\n    manger. If fault tolerance is required then the smallest practical odd\nnumber to achieve the\n    appropriate level of tolerance should be configured.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://docs.docker.com/engine/swarm/manage-nodes/\n2.\nhttps://docs.docker.com/engine/swarm/admin_guide/#/add-manager-nodes-forfault-tolerance\n",
        "severity": "medium",
        "cis_id": "7.2",
        "cis_control": "5 Controlled Use of Administration Privileges\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "AC-6"
        ],
        "audit": "Run docker info and verify the number of managers.\ndocker info\n--format '{{ .Swarm.Managers }}'\nAlternatively run the below command.\ndocker\nnode ls | grep 'Leader'\n",
        "fix": "If an excessive number of managers is configured, the excess can\nbe demoted as worker\nusing the following command:\ndocker node demote\n<ID>\nWhere is the node ID value of the manager to be demoted.\n",
        "Default Value": "A single manager is all that is required to start a\ngiven cluster.\n"
      },
      "code": "control \"M-7.2\" do\n  title \"7.2 Ensure the minimum number of manager nodes have been created\\nin a\nswarm (Scored)\"\n  desc  \"\n    Ensure that the minimum number of required manager nodes is created in a\nswarm.\n    Manager nodes within a swarm have control over the swarm and change its\nconfiguration\n    modifying security parameters. Having excessive manager nodes could render\nthe swarm\n    more susceptible to compromise.\n    If fault tolerance is not required in the manager nodes, a single node\nshould be elected as a\n    manger. If fault tolerance is required then the smallest practical odd\nnumber to achieve the\n    appropriate level of tolerance should be configured.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://docs.docker.com/engine/swarm/manage-nodes/\\n2.\nhttps://docs.docker.com/engine/swarm/admin_guide/#/add-manager-nodes-forfault-tolerance\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"7.2\"\n  tag \"cis_control\": \"5 Controlled Use of Administration Privileges\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"AC-6\"]\n  tag \"audit\": \"Run docker info and verify the number of managers.\\ndocker info\n--format '{{ .Swarm.Managers }}'\\nAlternatively run the below command.\\ndocker\nnode ls | grep 'Leader'\\n\"\n  tag \"fix\": \"If an excessive number of managers is configured, the excess can\nbe demoted as worker\\nusing the following command:\\ndocker node demote\n<ID>\\nWhere is the node ID value of the manager to be demoted.\\n\"\n  tag \"Default Value\": \"A single manager is all that is required to start a\ngiven cluster.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-7.2.rb",
        "line": 1
      },
      "id": "M-7.2"
    },
    {
      "title": "7.3 Ensure swarm services are binded to a specific host\ninterface(Scored)",
      "desc": "By default, the docker swarm services will listen to all interfaces on the\nhost, which may\n    not be necessary for the operation of the swarm where the host has multiple\nnetwork\n    interfaces.\n    When a swarm is initialized the default value for the --listen-addr flag is\n0.0.0.0:2377\n    which means that the swarm services will listen on all interfaces on the\nhost. If a host has\n    multiple network interfaces this may be undesirable as it may expose the\ndocker swarm\n    services to networks which are not involved in the operation of the swarm.\n    By passing a specific IP address to the --listen-addr, a specific network\ninterface can be\n    specified limiting this exposure.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://docs.docker.com/engine/reference/commandline/swarm_init/#--listenaddr\n2.\nhttps://docs.docker.com/engine/swarm/admin_guide/#recover-from-disaster\nNotes:\nA\ncouple of points I noted looking at this one. there doesn't seem to be a\nparameter for\ndocker swarm update to change the listen-addr. For the\nremediation I did wonder if -force-new-swarm could be used to change this, but\nI'm not sure what other effects that\nwould have on the swarm so just left with\na general requirement to re-initialize the swarm.\nAlso interestingly the node\ncommunication service running on 7946/TCP doesn't respect\nthe --listen-addr\nparameter. this seems like a bug to me, I'll likely file an issue on github\nfor\nit after a bit more exploration.\n",
        "severity": "medium",
        "cis_id": "7.3",
        "cis_control": "9 Limitation and Control of Network Ports, Protocols, and\nServices\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "SC-7"
        ],
        "audit": "List the network listener on port 2377/TCP (the default for\ndocker swarm) and confirm\nthat it is only listening on specific interfaces.\nFor example, using ubuntu this could be done\nwith the following\ncommand:\nnetstat -lt | grep -i 2377\n",
        "fix": "Remediation of this requires re-initialization of the swarm\nspecifying a specific interface\nfor the --listen-addr parameter.\n",
        "Default Value": "By default, docker swarm services listen on all\navailable host interfaces.\n"
      },
      "code": "control \"M-7.3\" do\n  title \"7.3 Ensure swarm services are binded to a specific host\ninterface(Scored)\"\n  desc  \"\n    By default, the docker swarm services will listen to all interfaces on the\nhost, which may\n    not be necessary for the operation of the swarm where the host has multiple\nnetwork\n    interfaces.\n    When a swarm is initialized the default value for the --listen-addr flag is\n0.0.0.0:2377\n    which means that the swarm services will listen on all interfaces on the\nhost. If a host has\n    multiple network interfaces this may be undesirable as it may expose the\ndocker swarm\n    services to networks which are not involved in the operation of the swarm.\n    By passing a specific IP address to the --listen-addr, a specific network\ninterface can be\n    specified limiting this exposure.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://docs.docker.com/engine/reference/commandline/swarm_init/#--listenaddr\\n2.\nhttps://docs.docker.com/engine/swarm/admin_guide/#recover-from-disaster\\nNotes:\\nA\ncouple of points I noted looking at this one. there doesn't seem to be a\nparameter for\\ndocker swarm update to change the listen-addr. For the\nremediation I did wonder if -force-new-swarm could be used to change this, but\nI'm not sure what other effects that\\nwould have on the swarm so just left with\na general requirement to re-initialize the swarm.\\nAlso interestingly the node\ncommunication service running on 7946/TCP doesn't respect\\nthe --listen-addr\nparameter. this seems like a bug to me, I'll likely file an issue on github\nfor\\nit after a bit more exploration.\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"7.3\"\n  tag \"cis_control\": \"9 Limitation and Control of Network Ports, Protocols, and\nServices\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"SC-7\"]\n  tag \"audit\": \"List the network listener on port 2377/TCP (the default for\ndocker swarm) and confirm\\nthat it is only listening on specific interfaces.\nFor example, using ubuntu this could be done\\nwith the following\ncommand:\\nnetstat -lt | grep -i 2377\\n\"\n  tag \"fix\": \"Remediation of this requires re-initialization of the swarm\nspecifying a specific interface\\nfor the --listen-addr parameter.\\n\"\n  tag \"Default Value\": \"By default, docker swarm services listen on all\navailable host interfaces.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-7.3.rb",
        "line": 1
      },
      "id": "M-7.3"
    },
    {
      "title": "7.4 Ensure data exchanged between containers are encrypted\non\ndifferent nodes on the overlay network (Scored)",
      "desc": "Encrypt data exchanged between containers on different nodes on the overlay\nnetwork.\n    By default, data exchanged between containers on different nodes on the\noverlay network\n    is not encrypted. This could potentially expose traffic between the\ncontainer nodes.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://docs.docker.com/engine/userguide/networking/overlay-security-model/\n2.\nhttps://github.com/docker/docker/issues/24253\n",
        "severity": "medium",
        "cis_id": "7.4",
        "cis_control": "14.2 Encrypt All Sensitive Information Over Less-trusted\nNetworks\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "SC-8"
        ],
        "audit": "Run the below command and ensure that each overlay network has\nbeen encrypted.\ndocker network ls --filter driver=overlay --quiet | xargs\ndocker network\ninspect --format '{{.Name}} {{ .Options }}'\n",
        "fix": "Create overlay network with --opt encrypted flag.\n",
        "Default Value": "By default, data exchanged between containers on\ndifferent nodes on the overlay network\nare not encrypted in the Docker swarm\nmode.\n"
      },
      "code": "control \"M-7.4\" do\n  title \"7.4 Ensure data exchanged between containers are encrypted\non\\ndifferent nodes on the overlay network (Scored)\"\n  desc  \"\n    Encrypt data exchanged between containers on different nodes on the overlay\nnetwork.\n    By default, data exchanged between containers on different nodes on the\noverlay network\n    is not encrypted. This could potentially expose traffic between the\ncontainer nodes.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://docs.docker.com/engine/userguide/networking/overlay-security-model/\\n2.\nhttps://github.com/docker/docker/issues/24253\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"7.4\"\n  tag \"cis_control\": \"14.2 Encrypt All Sensitive Information Over Less-trusted\nNetworks\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"SC-8\"]\n  tag \"audit\": \"Run the below command and ensure that each overlay network has\nbeen encrypted.\\ndocker network ls --filter driver=overlay --quiet | xargs\ndocker network\\ninspect --format '{{.Name}} {{ .Options }}'\\n\"\n  tag \"fix\": \"Create overlay network with --opt encrypted flag.\\n\"\n  tag \"Default Value\": \"By default, data exchanged between containers on\ndifferent nodes on the overlay network\\nare not encrypted in the Docker swarm\nmode.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-7.4.rb",
        "line": 1
      },
      "id": "M-7.4"
    },
    {
      "title": "7.5 Ensure Docker's secret management commands are used for\nmanaging\nsecrets in a Swarm cluster (Not Scored)",
      "desc": "Use Docker's in-built secret management command.\n    Docker has various commands for managing secrets in a Swarm cluster. This\nis the\n    foundation for future secret support in Docker with potential improvements\nsuch as\n    Windows support, different backing stores, etc.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://docs.docker.com/engine/reference/commandline/secret/\n",
        "severity": "medium",
        "cis_id": "7.5",
        "cis_control": "18 Application Software Security\n",
        "cis_level": "Level 2 - Docker",
        "nist": [
          "SI-1"
        ],
        "audit": "On a swarm manager node, run the below command and ensure\ndocker secret\nmanagement is used in your environment, if applicable.\ndocker\nsecret ls\n",
        "fix": "Follow docker secret documentation and use it to manage secrets\neffectively.\n",
        "Default Value": "Not Applicable\n"
      },
      "code": "control \"M-7.5\" do\n  title \"7.5 Ensure Docker's secret management commands are used for\\nmanaging\nsecrets in a Swarm cluster (Not Scored)\"\n  desc  \"\n    Use Docker's in-built secret management command.\n    Docker has various commands for managing secrets in a Swarm cluster. This\nis the\n    foundation for future secret support in Docker with potential improvements\nsuch as\n    Windows support, different backing stores, etc.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://docs.docker.com/engine/reference/commandline/secret/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"7.5\"\n  tag \"cis_control\": \"18 Application Software Security\\n\"\n  tag \"cis_level\": \"Level 2 - Docker\"\n  tag \"nist\": [\"SI-1\"]\n  tag \"audit\": \"On a swarm manager node, run the below command and ensure\ndocker secret\\nmanagement is used in your environment, if applicable.\\ndocker\nsecret ls\\n\"\n  tag \"fix\": \"Follow docker secret documentation and use it to manage secrets\neffectively.\\n\"\n  tag \"Default Value\": \"Not Applicable\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-7.5.rb",
        "line": 1
      },
      "id": "M-7.5"
    },
    {
      "title": "7.6 Ensure swarm manager is run in auto-lock mode (Scored)",
      "desc": "Run Docker swarm manager in auto-lock mode.\n    When Docker restarts, both the TLS key used to encrypt communication among\nswarm\n    nodes, and the key used to encrypt and decrypt Raft logs on disk, are\nloaded into each\n    manager node's memory. You should protect the mutual TLS encryption key and\nthe key\n    used to encrypt and decrypt Raft logs at rest. This protection could be\nenabled by\n    initializing swarm with --autolock flag.\n    With --autolockenabled, when Docker restarts, you must unlock the swarm\nfirst, using a\n    key encryption key generated by Docker when the swarm was initialized.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1. https://docs.docker.com/engine/swarm/swarm_manager_locking/\n",
        "severity": "medium",
        "cis_id": "7.6",
        "cis_control": "14.2 Encrypt All Sensitive Information Over Less-trusted\nNetworks\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "SC-8"
        ],
        "audit": "Run the below command. If it outputs the key, it means swarm\nwas initialized with the -autolock flag. If the output is no unlock key is set,\nit means that swarm was NOT\ninitialized with the --autolock flag and is\nnon-compliant with respect to this\nrecommendation.\ndocker swarm unlock-key\n",
        "fix": "If you are initializing swarm, use the below command.\ndocker\nswarm init --autolock\nIf you want to set --autolock on an existing swarm\nmanager node, use the below\ncommand.\ndocker swarm update --autolock\n",
        "Default Value": "By default, swarm manager does not run in auto-lock\nmode.\n"
      },
      "code": "control \"M-7.6\" do\n  title \"7.6 Ensure swarm manager is run in auto-lock mode (Scored)\"\n  desc  \"\n    Run Docker swarm manager in auto-lock mode.\n    When Docker restarts, both the TLS key used to encrypt communication among\nswarm\n    nodes, and the key used to encrypt and decrypt Raft logs on disk, are\nloaded into each\n    manager node's memory. You should protect the mutual TLS encryption key and\nthe key\n    used to encrypt and decrypt Raft logs at rest. This protection could be\nenabled by\n    initializing swarm with --autolock flag.\n    With --autolockenabled, when Docker restarts, you must unlock the swarm\nfirst, using a\n    key encryption key generated by Docker when the swarm was initialized.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1. https://docs.docker.com/engine/swarm/swarm_manager_locking/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"7.6\"\n  tag \"cis_control\": \"14.2 Encrypt All Sensitive Information Over Less-trusted\nNetworks\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"SC-8\"]\n  tag \"audit\": \"Run the below command. If it outputs the key, it means swarm\nwas initialized with the -autolock flag. If the output is no unlock key is set,\nit means that swarm was NOT\\ninitialized with the --autolock flag and is\nnon-compliant with respect to this\\nrecommendation.\\ndocker swarm unlock-key\\n\"\n  tag \"fix\": \"If you are initializing swarm, use the below command.\\ndocker\nswarm init --autolock\\nIf you want to set --autolock on an existing swarm\nmanager node, use the below\\ncommand.\\ndocker swarm update --autolock\\n\"\n  tag \"Default Value\": \"By default, swarm manager does not run in auto-lock\nmode.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-7.6.rb",
        "line": 1
      },
      "id": "M-7.6"
    },
    {
      "title": "7.7 Ensure swarm manager auto-lock key is rotated periodically\n(Not\nScored)",
      "desc": "Rotate swarm manager auto-lock key periodically.\n    Swarm manager auto-lock key is not automatically rotated. You should rotate\nthem\n    periodically as a best practice.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://docs.docker.com/engine/reference/commandline/swarm_unlock-key/\n",
        "severity": "medium",
        "cis_id": "7.7",
        "cis_control": "14.2 Encrypt All Sensitive Information Over Less-trusted\nNetworks\n",
        "cis_level": "Level 1 - Docker",
        "nist": [
          "SC-8"
        ],
        "audit": "Currently, there is no mechanism to find out when the key was\nlast rotated on a swarm\nmanager node. You should check with the system\nadministrator if there is a key rotation\nrecord and the keys were rotated at a\npre-defined frequency.\n",
        "fix": "Run the below command to rotate the keys.\ndocker swarm\nunlock-key --rotate\nAdditionally, to facilitate audit for this recommendation,\nmaintain key rotation records and\nensure that you establish a pre-defined\nfrequency for key rotation.\n",
        "Default Value": "By default, keys are not rotated automatically.\n"
      },
      "code": "control \"M-7.7\" do\n  title \"7.7 Ensure swarm manager auto-lock key is rotated periodically\n(Not\\nScored)\"\n  desc  \"\n    Rotate swarm manager auto-lock key periodically.\n    Swarm manager auto-lock key is not automatically rotated. You should rotate\nthem\n    periodically as a best practice.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://docs.docker.com/engine/reference/commandline/swarm_unlock-key/\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"7.7\"\n  tag \"cis_control\": \"14.2 Encrypt All Sensitive Information Over Less-trusted\nNetworks\\n\"\n  tag \"cis_level\": \"Level 1 - Docker\"\n  tag \"nist\": [\"SC-8\"]\n  tag \"audit\": \"Currently, there is no mechanism to find out when the key was\nlast rotated on a swarm\\nmanager node. You should check with the system\nadministrator if there is a key rotation\\nrecord and the keys were rotated at a\npre-defined frequency.\\n\"\n  tag \"fix\": \"Run the below command to rotate the keys.\\ndocker swarm\nunlock-key --rotate\\nAdditionally, to facilitate audit for this recommendation,\nmaintain key rotation records and\\nensure that you establish a pre-defined\nfrequency for key rotation.\\n\"\n  tag \"Default Value\": \"By default, keys are not rotated automatically.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-7.7.rb",
        "line": 1
      },
      "id": "M-7.7"
    },
    {
      "title": "7.8 Ensure node certificates are rotated as appropriate (Not Scored)",
      "desc": "Rotate swarm node certificates as appropriate.\n    Docker Swarm uses mutual TLS for clustering operations amongst its nodes.\nCertificate\n    rotation ensures that in an event such as compromised node or key, it is\ndifficult to\n    impersonate a node. By default, node certificates are rotated every 90\ndays. You should\n    rotate it more often or as appropriate in your environment.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://docs.docker.com/engine/reference/commandline/swarm_update/#exampl\nes\n",
        "severity": "medium",
        "cis_id": "7.8",
        "cis_control": "14.2 Encrypt All Sensitive Information Over Less-trusted\nNetworks\n",
        "cis_level": "Level 2 - Docker",
        "nist": [
          "SC-8"
        ],
        "audit": "Run the below command and ensure that the node certificate\nExpiry Duration is set as\nappropriate.\ndocker info | grep \"Expiry\nDuration\"\n",
        "fix": "Run the below command to set the desired expiry time.\nFor\nexample,\ndocker swarm update --cert-expiry 48h\n",
        "Default Value": "By default, node certificates are rotated automatically\nevery 90 days.\n"
      },
      "code": "control \"M-7.8\" do\n  title \"7.8 Ensure node certificates are rotated as appropriate (Not Scored)\"\n  desc  \"\n    Rotate swarm node certificates as appropriate.\n    Docker Swarm uses mutual TLS for clustering operations amongst its nodes.\nCertificate\n    rotation ensures that in an event such as compromised node or key, it is\ndifficult to\n    impersonate a node. By default, node certificates are rotated every 90\ndays. You should\n    rotate it more often or as appropriate in your environment.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://docs.docker.com/engine/reference/commandline/swarm_update/#exampl\\nes\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"7.8\"\n  tag \"cis_control\": \"14.2 Encrypt All Sensitive Information Over Less-trusted\nNetworks\\n\"\n  tag \"cis_level\": \"Level 2 - Docker\"\n  tag \"nist\": [\"SC-8\"]\n  tag \"audit\": \"Run the below command and ensure that the node certificate\nExpiry Duration is set as\\nappropriate.\\ndocker info | grep \\\"Expiry\nDuration\\\"\\n\"\n  tag \"fix\": \"Run the below command to set the desired expiry time.\\nFor\nexample,\\ndocker swarm update --cert-expiry 48h\\n\"\n  tag \"Default Value\": \"By default, node certificates are rotated automatically\nevery 90 days.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-7.8.rb",
        "line": 1
      },
      "id": "M-7.8"
    },
    {
      "title": "7.9 Ensure CA certificates are rotated as appropriate (Not Scored)",
      "desc": "Rotate root CA certificates as appropriate.\n    Docker Swarm uses mutual TLS for clustering operations amongst its nodes.\nCertificate\n    rotation ensures that in an event such as compromised node or key, it is\ndifficult to\n    impersonate a node. Node certificates depend upon root CA certificates. For\noperational\n    security, it is important to rotate these frequently. Currently, root CA\ncertificates are not\n    rotated automatically. You should thus establish a process to rotate it at\nthe desired\n    frequency.",
      "impact": 0.5,
      "refs": [],
      "tags": {
        "ref": "1.\nhttps://docs.docker.com/engine/swarm/how-swarm-mode-works/pki/#rotatingthe-ca-certificate\n",
        "severity": "medium",
        "cis_id": "7.9",
        "cis_control": "14.2 Encrypt All Sensitive Information Over Less-trusted\nNetworks\n",
        "cis_level": "Level 2 - Docker",
        "nist": [
          "SC-8"
        ],
        "audit": "Based on your installation path, check the time stamp on the\nroot CA certificate file.\nFor example,\nls -l\n/var/lib/docker/swarm/certificates/swarm-root-ca.crt\nThe certificate should\nhave been rotated at the established frequency.\n",
        "fix": "Run the below command to rotate the certificate.\ndocker swarm ca\n--rotate\n",
        "Default Value": "By default, root CA certificates are not rotated.\n"
      },
      "code": "control \"M-7.9\" do\n  title \"7.9 Ensure CA certificates are rotated as appropriate (Not Scored)\"\n  desc  \"\n    Rotate root CA certificates as appropriate.\n    Docker Swarm uses mutual TLS for clustering operations amongst its nodes.\nCertificate\n    rotation ensures that in an event such as compromised node or key, it is\ndifficult to\n    impersonate a node. Node certificates depend upon root CA certificates. For\noperational\n    security, it is important to rotate these frequently. Currently, root CA\ncertificates are not\n    rotated automatically. You should thus establish a process to rotate it at\nthe desired\n    frequency.\n\n  \"\n  impact 0.5\n  tag \"ref\": \"1.\nhttps://docs.docker.com/engine/swarm/how-swarm-mode-works/pki/#rotatingthe-ca-certificate\\n\"\n  tag \"severity\": \"medium\"\n  tag \"cis_id\": \"7.9\"\n  tag \"cis_control\": \"14.2 Encrypt All Sensitive Information Over Less-trusted\nNetworks\\n\"\n  tag \"cis_level\": \"Level 2 - Docker\"\n  tag \"nist\": [\"SC-8\"]\n  tag \"audit\": \"Based on your installation path, check the time stamp on the\nroot CA certificate file.\\nFor example,\\nls -l\n/var/lib/docker/swarm/certificates/swarm-root-ca.crt\\nThe certificate should\nhave been rotated at the established frequency.\\n\"\n  tag \"fix\": \"Run the below command to rotate the certificate.\\ndocker swarm ca\n--rotate\\n\"\n  tag \"Default Value\": \"By default, root CA certificates are not rotated.\\n\"\nend\n",
      "source_location": {
        "ref": "ubuntu/controls/M-7.9.rb",
        "line": 1
      },
      "id": "M-7.9"
    }
  ],
  "groups": [
    {
      "title": null,
      "controls": [
        "M-1.1"
      ],
      "id": "controls/M-1.1.rb"
    },
    {
      "title": null,
      "controls": [
        "M-1.10"
      ],
      "id": "controls/M-1.10.rb"
    },
    {
      "title": null,
      "controls": [
        "M-1.11"
      ],
      "id": "controls/M-1.11.rb"
    },
    {
      "title": null,
      "controls": [
        "M-1.12"
      ],
      "id": "controls/M-1.12.rb"
    },
    {
      "title": null,
      "controls": [
        "M-1.13"
      ],
      "id": "controls/M-1.13.rb"
    },
    {
      "title": null,
      "controls": [
        "M-1.2"
      ],
      "id": "controls/M-1.2.rb"
    },
    {
      "title": null,
      "controls": [
        "M-1.3"
      ],
      "id": "controls/M-1.3.rb"
    },
    {
      "title": null,
      "controls": [
        "M-1.4"
      ],
      "id": "controls/M-1.4.rb"
    },
    {
      "title": null,
      "controls": [
        "M-1.5"
      ],
      "id": "controls/M-1.5.rb"
    },
    {
      "title": null,
      "controls": [
        "M-1.6"
      ],
      "id": "controls/M-1.6.rb"
    },
    {
      "title": null,
      "controls": [
        "M-1.7"
      ],
      "id": "controls/M-1.7.rb"
    },
    {
      "title": null,
      "controls": [
        "M-1.8"
      ],
      "id": "controls/M-1.8.rb"
    },
    {
      "title": null,
      "controls": [
        "M-1.9"
      ],
      "id": "controls/M-1.9.rb"
    },
    {
      "title": null,
      "controls": [
        "M-2.1"
      ],
      "id": "controls/M-2.1.rb"
    },
    {
      "title": null,
      "controls": [
        "M-2.10"
      ],
      "id": "controls/M-2.10.rb"
    },
    {
      "title": null,
      "controls": [
        "M-2.11"
      ],
      "id": "controls/M-2.11.rb"
    },
    {
      "title": null,
      "controls": [
        "M-2.12"
      ],
      "id": "controls/M-2.12.rb"
    },
    {
      "title": null,
      "controls": [
        "M-2.13"
      ],
      "id": "controls/M-2.13.rb"
    },
    {
      "title": null,
      "controls": [
        "M-2.14"
      ],
      "id": "controls/M-2.14.rb"
    },
    {
      "title": null,
      "controls": [
        "M-2.15"
      ],
      "id": "controls/M-2.15.rb"
    },
    {
      "title": null,
      "controls": [
        "M-2.16"
      ],
      "id": "controls/M-2.16.rb"
    },
    {
      "title": null,
      "controls": [
        "M-2.17"
      ],
      "id": "controls/M-2.17.rb"
    },
    {
      "title": null,
      "controls": [
        "M-2.18"
      ],
      "id": "controls/M-2.18.rb"
    },
    {
      "title": null,
      "controls": [
        "M-2.3"
      ],
      "id": "controls/M-2.3.rb"
    },
    {
      "title": null,
      "controls": [
        "M-2.4"
      ],
      "id": "controls/M-2.4.rb"
    },
    {
      "title": null,
      "controls": [
        "M-2.5"
      ],
      "id": "controls/M-2.5.rb"
    },
    {
      "title": null,
      "controls": [
        "M-2.6"
      ],
      "id": "controls/M-2.6.rb"
    },
    {
      "title": null,
      "controls": [
        "M-2.7"
      ],
      "id": "controls/M-2.7.rb"
    },
    {
      "title": null,
      "controls": [
        "M-2.8"
      ],
      "id": "controls/M-2.8.rb"
    },
    {
      "title": null,
      "controls": [
        "M-2.9"
      ],
      "id": "controls/M-2.9.rb"
    },
    {
      "title": null,
      "controls": [
        "M-3.1"
      ],
      "id": "controls/M-3.1.rb"
    },
    {
      "title": null,
      "controls": [
        "M-3.10"
      ],
      "id": "controls/M-3.10.rb"
    },
    {
      "title": null,
      "controls": [
        "M-3.11"
      ],
      "id": "controls/M-3.11.rb"
    },
    {
      "title": null,
      "controls": [
        "M-3.12"
      ],
      "id": "controls/M-3.12.rb"
    },
    {
      "title": null,
      "controls": [
        "M-3.13"
      ],
      "id": "controls/M-3.13.rb"
    },
    {
      "title": null,
      "controls": [
        "M-3.14"
      ],
      "id": "controls/M-3.14.rb"
    },
    {
      "title": null,
      "controls": [
        "M-3.15"
      ],
      "id": "controls/M-3.15.rb"
    },
    {
      "title": null,
      "controls": [
        "M-3.16"
      ],
      "id": "controls/M-3.16.rb"
    },
    {
      "title": null,
      "controls": [
        "M-3.17"
      ],
      "id": "controls/M-3.17.rb"
    },
    {
      "title": null,
      "controls": [
        "M-3.18"
      ],
      "id": "controls/M-3.18.rb"
    },
    {
      "title": null,
      "controls": [
        "M-3.19"
      ],
      "id": "controls/M-3.19.rb"
    },
    {
      "title": null,
      "controls": [
        "M-3.2"
      ],
      "id": "controls/M-3.2.rb"
    },
    {
      "title": null,
      "controls": [
        "M-3.20"
      ],
      "id": "controls/M-3.20.rb"
    },
    {
      "title": null,
      "controls": [
        "M-3.3"
      ],
      "id": "controls/M-3.3.rb"
    },
    {
      "title": null,
      "controls": [
        "M-3.4"
      ],
      "id": "controls/M-3.4.rb"
    },
    {
      "title": null,
      "controls": [
        "M-3.5"
      ],
      "id": "controls/M-3.5.rb"
    },
    {
      "title": null,
      "controls": [
        "M-3.6"
      ],
      "id": "controls/M-3.6.rb"
    },
    {
      "title": null,
      "controls": [
        "M-3.7"
      ],
      "id": "controls/M-3.7.rb"
    },
    {
      "title": null,
      "controls": [
        "M-3.8"
      ],
      "id": "controls/M-3.8.rb"
    },
    {
      "title": null,
      "controls": [
        "M-3.9"
      ],
      "id": "controls/M-3.9.rb"
    },
    {
      "title": null,
      "controls": [
        "M-4.1"
      ],
      "id": "controls/M-4.1.rb"
    },
    {
      "title": null,
      "controls": [
        "M-4.10"
      ],
      "id": "controls/M-4.10.rb"
    },
    {
      "title": null,
      "controls": [
        "M-4.11"
      ],
      "id": "controls/M-4.11.rb"
    },
    {
      "title": null,
      "controls": [
        "M-4.2"
      ],
      "id": "controls/M-4.2.rb"
    },
    {
      "title": null,
      "controls": [
        "M-4.3"
      ],
      "id": "controls/M-4.3.rb"
    },
    {
      "title": null,
      "controls": [
        "M-4.4"
      ],
      "id": "controls/M-4.4.rb"
    },
    {
      "title": null,
      "controls": [
        "M-4.5"
      ],
      "id": "controls/M-4.5.rb"
    },
    {
      "title": null,
      "controls": [
        "M-4.6"
      ],
      "id": "controls/M-4.6.rb"
    },
    {
      "title": null,
      "controls": [
        "M-4.7"
      ],
      "id": "controls/M-4.7.rb"
    },
    {
      "title": null,
      "controls": [
        "M-4.8"
      ],
      "id": "controls/M-4.8.rb"
    },
    {
      "title": null,
      "controls": [
        "M-4.9"
      ],
      "id": "controls/M-4.9.rb"
    },
    {
      "title": null,
      "controls": [
        "M-5.1"
      ],
      "id": "controls/M-5.1.rb"
    },
    {
      "title": null,
      "controls": [
        "M-5.10"
      ],
      "id": "controls/M-5.10.rb"
    },
    {
      "title": null,
      "controls": [
        "M-5.11"
      ],
      "id": "controls/M-5.11.rb"
    },
    {
      "title": null,
      "controls": [
        "M-5.12"
      ],
      "id": "controls/M-5.12.rb"
    },
    {
      "title": null,
      "controls": [
        "M-5.13"
      ],
      "id": "controls/M-5.13.rb"
    },
    {
      "title": null,
      "controls": [
        "M-5.14"
      ],
      "id": "controls/M-5.14.rb"
    },
    {
      "title": null,
      "controls": [
        "M-5.15"
      ],
      "id": "controls/M-5.15.rb"
    },
    {
      "title": null,
      "controls": [
        "M-5.16"
      ],
      "id": "controls/M-5.16.rb"
    },
    {
      "title": null,
      "controls": [
        "M-5.17"
      ],
      "id": "controls/M-5.17.rb"
    },
    {
      "title": null,
      "controls": [
        "M-5.18"
      ],
      "id": "controls/M-5.18.rb"
    },
    {
      "title": null,
      "controls": [
        "M-5.19"
      ],
      "id": "controls/M-5.19.rb"
    },
    {
      "title": null,
      "controls": [
        "M-5.2"
      ],
      "id": "controls/M-5.2.rb"
    },
    {
      "title": null,
      "controls": [
        "M-5.20"
      ],
      "id": "controls/M-5.20.rb"
    },
    {
      "title": null,
      "controls": [
        "M-5.21"
      ],
      "id": "controls/M-5.21.rb"
    },
    {
      "title": null,
      "controls": [
        "M-5.22"
      ],
      "id": "controls/M-5.22.rb"
    },
    {
      "title": null,
      "controls": [
        "M-5.23"
      ],
      "id": "controls/M-5.23.rb"
    },
    {
      "title": null,
      "controls": [
        "M-5.24"
      ],
      "id": "controls/M-5.24.rb"
    },
    {
      "title": null,
      "controls": [
        "M-5.25"
      ],
      "id": "controls/M-5.25.rb"
    },
    {
      "title": null,
      "controls": [
        "M-5.26"
      ],
      "id": "controls/M-5.26.rb"
    },
    {
      "title": null,
      "controls": [
        "M-5.27"
      ],
      "id": "controls/M-5.27.rb"
    },
    {
      "title": null,
      "controls": [
        "M-5.28"
      ],
      "id": "controls/M-5.28.rb"
    },
    {
      "title": null,
      "controls": [
        "M-5.29"
      ],
      "id": "controls/M-5.29.rb"
    },
    {
      "title": null,
      "controls": [
        "M-5.3"
      ],
      "id": "controls/M-5.3.rb"
    },
    {
      "title": null,
      "controls": [
        "M-5.30"
      ],
      "id": "controls/M-5.30.rb"
    },
    {
      "title": null,
      "controls": [
        "M-5.31"
      ],
      "id": "controls/M-5.31.rb"
    },
    {
      "title": null,
      "controls": [
        "M-5.4"
      ],
      "id": "controls/M-5.4.rb"
    },
    {
      "title": null,
      "controls": [
        "M-5.5"
      ],
      "id": "controls/M-5.5.rb"
    },
    {
      "title": null,
      "controls": [
        "M-5.6"
      ],
      "id": "controls/M-5.6.rb"
    },
    {
      "title": null,
      "controls": [
        "M-5.7"
      ],
      "id": "controls/M-5.7.rb"
    },
    {
      "title": null,
      "controls": [
        "M-5.8"
      ],
      "id": "controls/M-5.8.rb"
    },
    {
      "title": null,
      "controls": [
        "M-5.9"
      ],
      "id": "controls/M-5.9.rb"
    },
    {
      "title": null,
      "controls": [
        "M-6.1"
      ],
      "id": "controls/M-6.1.rb"
    },
    {
      "title": null,
      "controls": [
        "M-6.2"
      ],
      "id": "controls/M-6.2.rb"
    },
    {
      "title": null,
      "controls": [
        "M-7.1"
      ],
      "id": "controls/M-7.1.rb"
    },
    {
      "title": null,
      "controls": [
        "M-7.10"
      ],
      "id": "controls/M-7.10.rb"
    },
    {
      "title": null,
      "controls": [
        "M-7.2"
      ],
      "id": "controls/M-7.2.rb"
    },
    {
      "title": null,
      "controls": [
        "M-7.3"
      ],
      "id": "controls/M-7.3.rb"
    },
    {
      "title": null,
      "controls": [
        "M-7.4"
      ],
      "id": "controls/M-7.4.rb"
    },
    {
      "title": null,
      "controls": [
        "M-7.5"
      ],
      "id": "controls/M-7.5.rb"
    },
    {
      "title": null,
      "controls": [
        "M-7.6"
      ],
      "id": "controls/M-7.6.rb"
    },
    {
      "title": null,
      "controls": [
        "M-7.7"
      ],
      "id": "controls/M-7.7.rb"
    },
    {
      "title": null,
      "controls": [
        "M-7.8"
      ],
      "id": "controls/M-7.8.rb"
    },
    {
      "title": null,
      "controls": [
        "M-7.9"
      ],
      "id": "controls/M-7.9.rb"
    }
  ],
  "attributes": [],
  "sha256": "5f3b052a76bf9555bbc617354f92f1c98a85ef272473e05b5d916ec91a32bc7d"
}