Integration Security tests

The main of this page is to compare the existing k8S security tests versus the Kubescape tool developed according to NSA recommendations.

Security Tests

 Integration Security tests are deployed (some tests are developped internally) by integration Teams. 

Security Tests

Example of a scorecard:

The outcome includes the possibility to accept somes failures and to increase the outcome (main 100%).

Kubescape is the first open-source tool for testing if Kubernetes is deployed securely according to multiple frameworks: regulatory, customized company policies and DevSecOps best practices, such as the NSA-CISA and the MITRE ATT&CK® .
Kubescape scans K8s clusters, YAML files, and HELM charts, and detect misconfigurations and software vulnerabilities at early stages of the CI/CD pipeline and provides a risk score instantly and risk trends over time. Kubescape integrates natively with other DevOps tools, including Jenkins, CircleCI and Github workflows.

https://github.com/armosec/kubescape

Control name and description:

1) Allow privilege escalation:
Attackers may gain access to a container and uplift its privilege to enable excessive capabilities.

2)Allowed hostPath:
Mounting host directory to the container can be abused to get access to sensitive data and gain persistence on the host machine.

3) Applications credentials in configuration files:
Attackers who have access to configuration files can steal the stored secrets and use them. Checks if ConfigMaps or pods have sensitive information in configuration.

4) Automatic mapping of service account:
Potential attacker may gain access to a POD and steal its service account token. Therefore, it is recommended to disable automatic mapping of the service account tokens in service account configuration and enable it only for PODs that need to use them. 

5) CVE-2021-25741 - Using symlink for arbitrary host file system access:
A user may be able to create a container with subPath volume mounts to access files & directories outside of the volume, including on the host filesystem.
This was affected at the following versions: v1.22.0 - v1.22.1, v1.21.0 - v1.21.4, v1.20.0 - v1.20.10, version v1.19.14 and lower.

6) Cluster-admin binding:
Attackers who have Cluster-admin permissions (can perform any action on any resource), can take advantage of their high privileges for malicious intentions. Determines which subjects have cluster admin permissions.

7) Container hostPort:
Configuring hostPort limits you to a particular port, and if any two workloads that specify the same HostPort cannot be deployed to the same node. And if the scale of your workload is larger than the number of nodes in your Kubernetes cluster, the deployment fails.

8) Control plane hardening:
Kubernetes control plane API is running with non-secure port enabled which allows attackers to gain unprotected access to the cluster.

9) Dangerous capabilities:
Giving dangerous and unnecessary capabilities for a container can increase the impact of a container compromise.

10) Exec into container:
Attackers who have permissions, can run malicious commands in containers in the cluster using exec command (“kubectl exec”). Determines which subjects have permissions to exec into containers. 

11) Exposed dashboard:
If Kubernetes dashboard is exposed externally in Dashboard versions before 2.01, it will allow unauthenticated remote management of the cluster.

12) Host PID/IPC privileges: 
Containers should be as isolated as possible from the host machine. The hostPID and hostIPC fields in Kubernetes may excessively expose the host for potentially malicious actions. 

13) Immutable container files:
Mutable container filesystem can be abused to gain malicious code and data injection into containers. Use immutable (read-only) filesystem to limit potential attacks.
Deployment - nginx-deployment
Remediation: Set the filesystem of the container to read-only when possible. If the containers application needs to write into the filesystem, it is possible to mount secondary filesystems for specific directories where application require write access. 

14) Ingress and Egress blocked:
By default, you should disable Ingress and Egress traffic on all pods.
Deployment - nginx-deployment
Remediation: Define a network policy that restricts ingress and egress connections. 

15) Insecure capabilities:
Giving insecure and unnecessary capabilities for a container can increase the impact of a container compromise. 

16) Linux hardening: 
Often, containers are given more privileges than actually needed. This behavior can increase the impact of a container compromise. 
Deployment - nginx-deployment
Remediation: Make sure you define at least one linux security hardening property out of AppArmor, Seccomp, SELinux or Capabilities.

17) Network policies: If no network policy is defined, attackers who gain access to a single container may use it to probe the network. Lists namespaces in which no network policies are defined. 

18) Non-root containers:
Potential attackers may gain access to a container and leverage its privileges to conduct an attack. Hence it is not recommended to deploy containers with root privileges unless it is absolutely necessary. 

19) Privileged container:
Potential attackers may gain access to privileged containers and inherit access to the host resources. Therefore, it is not recommended to deploy privileged containers unless it is absolutely necessary. 

20) Resource policies:
CPU and memory resources should have a limit set for every container to prevent resource exhaustion.

21) hostNetwork access:
Potential attackers may gain access to a POD and inherit access to the entire host network. For example, in AWS case, they will have access to the entire VPC.

Example of a scorecard:

+-----------------------------------------------------------------------+------------------+-------------------+---------------+-----------+
|                             CONTROL NAME                              | FAILED RESOURCES | WARNING RESOURCES | ALL RESOURCES | % SUCCESS |
+-----------------------------------------------------------------------+------------------+-------------------+---------------+-----------+
| Allow privilege escalation                                            | 0                | 0                 | 1             | 100%      |
| Allowed hostPath                                                      | 0                | 0                 | 1             | 100%      |
| Applications credentials in configuration files                       | 0                | 0                 | 1             | 100%      |
| Automatic mapping of service account                                  | 0                | 0                 | 0             | NaN       |
| CVE-2021-25741 - Using symlink for arbitrary host file system access. | 0                | 0                 | 1             | 100%      |
| Cluster-admin binding                                                 | 0                | 0                 | 0             | NaN       |
| Container hostPort                                                    | 0                | 0                 | 1             | 100%      |
| Control plane hardening                                               | 0                | 0                 | 1             | 100%      |
| Dangerous capabilities                                                | 0                | 0                 | 1             | 100%      |
| Exec into container                                                   | 0                | 0                 | 0             | NaN       |
| Exposed dashboard                                                     | 0                | 0                 | 1             | 100%      |
| Host PID/IPC privileges                                               | 0                | 0                 | 1             | 100%      |
| Immutable container filesystem                                        | 1                | 0                 | 1             | 0%        |
| Ingress and Egress blocked                                            | 1                | 0                 | 1             | 0%        |
| Insecure capabilities                                                 | 0                | 0                 | 1             | 100%      |
| Linux hardening                                                       | 1                | 0                 | 1             | 0%        |
| Network policies                                                      | 0                | 0                 | 0             | NaN       |
| Non-root containers                                                   | 0                | 0                 | 1             | 100%      |
| Privileged container                                                  | 0                | 0                 | 1             | 100%      |
| Resource policies                                                     | 0                | 0                 | 1             | 100%      |
| hostNetwork access                                                    | 0                | 0                 | 1             | 100%      |
+-----------------------------------------------------------------------+------------------+-------------------+---------------+-----------+
|                                  21                                   |        3         |         0         |      17       |    82%    |
+-----------------------------------------------------------------------+------------------+-------------------+---------------+-----------+