Recategorize the results into standard categories. (#434)

* Initial checkin for recategorizing checks * Fix tests * Fix tests * Update example output
FairwindsOps · Nov 4, 2020 · b3f1b3b · b3f1b3b
1 parent 4ff34de
commit b3f1b3b
Show file tree

Hide file tree

Showing 27 changed files with 498 additions and 181 deletions.
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -1,4 +1,5 @@
 # x.x.x (next release)
+* Standardize categories of checks into Security, Reliability, and Efficiency
 
 # 1.2.1
 * Update date on dashboard footer

diff --git a/checks/cpuLimitsMissing.yaml b/checks/cpuLimitsMissing.yaml
@@ -1,6 +1,6 @@
 successMessage: CPU limits are set
 failureMessage: CPU limits should be set
-category: Resources
+category: Efficiency
 target: Container
 containers:
   exclude:

diff --git a/checks/cpuRequestsMissing.yaml b/checks/cpuRequestsMissing.yaml
@@ -1,6 +1,6 @@
 successMessage: CPU requests are set
 failureMessage: CPU requests should be set
-category: Resources
+category: Efficiency
 target: Container
 containers:
   exclude:

diff --git a/checks/hostNetworkSet.yaml b/checks/hostNetworkSet.yaml
@@ -1,6 +1,6 @@
 successMessage: Host network is not configured
 failureMessage: Host network should not be configured
-category: Networking
+category: Security
 target: Pod
 schema:
   '$schema': http://json-schema.org/draft-07/schema

diff --git a/checks/hostPortSet.yaml b/checks/hostPortSet.yaml
@@ -1,6 +1,6 @@
 successMessage: Host port is not configured
 failureMessage: Host port should not be configured
-category: Networking
+category: Security
 target: Container
 schema:
   '$schema': http://json-schema.org/draft-07/schema

diff --git a/checks/livenessProbeMissing.yaml b/checks/livenessProbeMissing.yaml
@@ -1,6 +1,6 @@
 successMessage: Liveness probe is configured
 failureMessage: Liveness probe should be configured
-category: Health Checks
+category: Reliability
 controllers:
   exclude:
   - Job

diff --git a/checks/memoryLimitsMissing.yaml b/checks/memoryLimitsMissing.yaml
@@ -1,6 +1,6 @@
 successMessage: Memory limits are set
 failureMessage: Memory limits should be set
-category: Resources
+category: Efficiency
 target: Container
 containers:
   exclude:

diff --git a/checks/memoryRequestsMissing.yaml b/checks/memoryRequestsMissing.yaml
@@ -1,6 +1,6 @@
 successMessage: Memory requests are set
 failureMessage: Memory requests should be set
-category: Resources
+category: Efficiency
 target: Container
 containers:
   exclude:

diff --git a/checks/pullPolicyNotAlways.yaml b/checks/pullPolicyNotAlways.yaml
@@ -1,6 +1,6 @@
 successMessage: Image pull policy is "Always"
 failureMessage: Image pull policy should be "Always"
-category: Images
+category: Reliability
 target: Container
 schema:
   '$schema': http://json-schema.org/draft-07/schema

diff --git a/checks/readinessProbeMissing.yaml b/checks/readinessProbeMissing.yaml
@@ -1,6 +1,6 @@
 successMessage: Readiness probe is configured
 failureMessage: Readiness probe should be configured
-category: Health Checks
+category: Reliability
 controllers:
   exclude:
   - Job

diff --git a/checks/tagNotSpecified.yaml b/checks/tagNotSpecified.yaml
@@ -1,6 +1,6 @@
 successMessage: Image tag is specified
 failureMessage: Image tag should be specified
-category: Images
+category: Reliability
 target: Container
 schema:
   '$schema': http://json-schema.org/draft-07/schema

diff --git a/docs/check-documentation/resources.md → docs/check-documentation/efficiency.md b/docs/check-documentation/resources.md → docs/check-documentation/efficiency.md
@@ -1,4 +1,4 @@
-# Resources
+# Efficiency
 
 Polaris supports a number of checks related to CPU and Memory requests and limits.
 
@@ -8,10 +8,10 @@ To simplify ensure that these values have been set, the following attributes are
 
 key | default | description
 ----|---------|------------
-`resources.cpuRequestsMissing` | `danger` | Fails when `resources.requests.cpu` attribute is not configured.
-`resources.memoryRequestsMissing` | `danger` | Fails when `resources.requests.memory` attribute is not configured.
-`resources.cpuLimitsMissing` | `danger` | Fails when `resources.limits.cpu` attribute is not configured.
-`resources.memoryLimitsMissing` | `danger` | Fails when `resources.limits.memory` attribute is not configured.
+`resources.cpuRequestsMissing` | `warning` | Fails when `resources.requests.cpu` attribute is not configured.
+`resources.memoryRequestsMissing` | `warning` | Fails when `resources.requests.memory` attribute is not configured.
+`resources.cpuLimitsMissing` | `warning` | Fails when `resources.limits.cpu` attribute is not configured.
+`resources.memoryLimitsMissing` | `warning` | Fails when `resources.limits.memory` attribute is not configured.
 
 ## Background
 

diff --git a/docs/check-documentation/health-checks.md b/docs/check-documentation/health-checks.md
diff --git a/docs/check-documentation/images.md b/docs/check-documentation/images.md
diff --git a/docs/check-documentation/networking.md b/docs/check-documentation/networking.md
diff --git a/docs/check-documentation/reliability.md b/docs/check-documentation/reliability.md
@@ -0,0 +1,32 @@
+# Reliability
+
+Polaris supports a number of checks related to keeping workloads running in a reliabile and consistent manner.
+
+key | default | description
+----|---------|------------
+`reliability.readinessProbeMissing` | `warning` | Fails when a readiness probe is not configured for a pod.
+`reliability.livenessProbeMissing` | `warning` | Fails when a liveness probe is not configured for a pod.
+`reliability.tagNotSpecified` | `danger` | Fails when an image tag is either not specified or `latest`.
+`reliability.pullPolicyNotAlways` | `warning` | Fails when an image pull policy is not `always`.
+`reliability.priorityClassNotSet` | `ignore` | Fails when a priorityClassName is not set for a pod.
+`reliability.multipleReplicasForDeployment` | `ignore` | Fails when there is only one replica for a deployment.
+
+## Background
+
+Readiness and liveness probes can help maintain the health of applications running inside Kubernetes. By default, Kubernetes only knows whether or not a process is running, not if it's healthy. Properly configured readiness and liveness probes will also be able to ensure the health of an application.
+
+Readiness probes are designed to ensure that an application has reached a "ready" state. In many cases there is a period of time between when a webserver process starts and when it is ready to receive traffic. A readiness probe can ensure the traffic is not sent to a pod until it is actually ready to receive traffic.
+
+Liveness probes are designed to ensure that an application stays in a healthy state. When a liveness probe fails, the pod will be restarted.
+
+Docker's `latest` tag is applied by default to images where a tag hasn't been specified. Not specifying a specific version of an image can lead to a wide variety of problems. The underlying image could include unexpected breaking changes that break your application whenever the latest image is pulled. Reusing the same tag for multiple versions of an image can lead to different nodes in the same cluster having different versions of an image, even if the tag is identical.
+
+Related to that, relying on cached versions of a Docker image can become a security vulnerability. By default, an image will be pulled if it isn't already cached on the node attempting to run it. This can result in variations in images that are running per node, or potentially provide a way to gain access to an image without having direct access to the ImagePullSecret. With that in mind, it's often better to ensure the a pod has `pullPolicy: Always` specified, so images are always pulled directly from their source.
+
+## Further Reading
+
+- [What's Wrong With The Docker :latest Tag?](https://vsupalov.com/docker-latest-tag/)
+- [Kubernetes’ AlwaysPullImages Admission Control — the Importance, Implementation, and Security Vulnerability in its Absence](https://medium.com/@trstringer/kubernetes-alwayspullimages-admission-control-the-importance-implementation-and-security-d83ff3815840)
+- [Kubernetes Docs: Configure Liveness and Readiness Probes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)
+- [Utilizing Kubernetes Liveness and Readiness Probes to Automatically Recover From Failure](https://medium.com/spire-labs/utilizing-kubernetes-liveness-and-readiness-probes-to-automatically-recover-from-failure-2fe0314f2b2e)
+- [Kubernetes Liveness and Readiness Probes: How to Avoid Shooting Yourself in the Foot](https://blog.colinbreck.com/kubernetes-liveness-and-readiness-probes-how-to-avoid-shooting-yourself-in-the-foot/)
diff --git a/docs/check-documentation/security.md b/docs/check-documentation/security.md
@@ -8,14 +8,20 @@ key | default | description
 `security.hostPIDSet` | `danger` | Fails when `hostPID` attribute is configured.
 `security.notReadOnlyRootFilesystem` | `warning` | Fails when `securityContext.readOnlyRootFilesystem` is not true.
 `security.privilegeEscalationAllowed` | `danger` | Fails when `securityContext.allowPrivilegeEscalation` is true.
-`security.runAsRootAllowed` | `danger` | Fails when `securityContext.runAsNonRoot` is not true.
+`security.runAsRootAllowed` | `warning` | Fails when `securityContext.runAsNonRoot` is not true.
 `security.runAsPrivileged` | `danger` | Fails when `securityContext.privileged` is true.
 `security.insecureCapabilities` | `warning` | Fails when `securityContext.capabilities` includes one of the capabilities [listed here](/checks/insecureCapabilities.yaml)
 `security.dangerousCapabilities` | `danger` | Fails when `securityContext.capabilities` includes one of the capabilities [listed here](/checks/dangerousCapabilities.yaml)
+`security.hostNetworkSet` | `warning` | Fails when `hostNetwork` attribute is configured.
+`security.hostPortSet` | `warning` | Fails when `hostPort` attribute is configured.
 
 ## Background
 
-Securing workloads in Kubernetes is an important part of overall cluster security. The overall goal should be to ensure that containers are running with as minimal privileges as possible. This includes avoiding privilege escalation, not running containers with a root user, and using read only file systems wherever possible.
+Securing workloads in Kubernetes is an important part of overall cluster security. The overall goal should be to ensure that containers are running with as minimal privileges as possible. This includes avoiding privilege escalation, not running containers with a root user, not giving excessive access to the host network, and using read only file systems wherever possible.
+
+A pod running with the `hostNetwork` attribute enabled will have access to the loopback device, services listening on localhost, and could be used to snoop on network activity of other pods on the same node. There are certain examples where setting `hostNetwork` to true is required, such as deploying a networking plugin like Flannel.
+
+Setting the `hostPort` attribute on a container will ensure that it is accessible on that specific port on each node it is deployed to. Unfortunately when this is specified, it limits where a pod can actually be scheduled in a cluster.
 
 Much of this configuration can be found in the `securityContext` attribute for both Kubernetes pods and containers. Where configuration is available at both a pod and container level, Polaris validates both.
 
@@ -25,3 +31,5 @@ Much of this configuration can be found in the `securityContext` attribute for b
 - [Kubernetes Security Book](https://kubernetes-security.info/)
 - [Kubernetes Docs: Set capabilities for a Container](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container)
 - [Linux Programmer's Manual: Capabilities](http://man7.org/linux/man-pages/man7/capabilities.7.html)
+- [Kubernetes Docs: Configuration Best Practices](https://kubernetes.io/docs/concepts/configuration/overview/#services)
+- [Accessing Kubernetes Pods from Outside of the Cluster](http://alesnosek.com/blog/2017/02/14/accessing-kubernetes-pods-from-outside-of-the-cluster/)
diff --git a/docs/usage.md b/docs/usage.md
@@ -14,11 +14,9 @@ Each check can be assigned a `severity`. Only checks with a severity of `danger`
 
 Polaris validation checks fall into several different categories:
 
-- [Health Checks](check-documentation/health-checks.md)
-- [Images](check-documentation/images.md)
-- [Networking](check-documentation/networking.md)
-- [Resources](check-documentation/resources.md)
 - [Security](check-documentation/security.md)
+- [Reliability](check-documentation/reliability.md)
+- [Efficiency](check-documentation/efficiency.md)
 
 #### Custom Checks
 If you'd like to create your own checks, you can use [JSON Schema](https://json-schema.org/). For example,

diff --git a/examples/config-full.yaml b/examples/config-full.yaml
@@ -2,20 +2,15 @@ checks:
   # reliability
   multipleReplicasForDeployment: warning
   priorityClassNotSet: warning
-  # resources
-  cpuRequestsMissing: warning
-  cpuLimitsMissing: warning
-  memoryRequestsMissing: warning
-  memoryLimitsMissing: warning
-  # images
   tagNotSpecified: danger
   pullPolicyNotAlways: warning
-  # healthChecks
   readinessProbeMissing: warning
   livenessProbeMissing: warning
-  # networking
-  hostNetworkSet: warning
-  hostPortSet: warning
+  # efficiency
+  cpuRequestsMissing: warning
+  cpuLimitsMissing: warning
+  memoryRequestsMissing: warning
+  memoryLimitsMissing: warning
   # security
   hostIPCSet: danger
   hostPIDSet: danger
@@ -25,6 +20,8 @@ checks:
   runAsPrivileged: danger
   dangerousCapabilities: danger
   insecureCapabilities: warning
+  hostNetworkSet: warning
+  hostPortSet: warning
   # custom
   resourceLimits: warning
   imageRegistry: danger

diff --git a/examples/config.yaml b/examples/config.yaml
@@ -2,20 +2,15 @@ checks:
   # reliability
   multipleReplicasForDeployment: ignore
   priorityClassNotSet: ignore
-  # resources
-  cpuRequestsMissing: warning
-  cpuLimitsMissing: warning
-  memoryRequestsMissing: warning
-  memoryLimitsMissing: warning
-  # images
   tagNotSpecified: danger
   pullPolicyNotAlways: warning
-  # healthChecks
   readinessProbeMissing: warning
   livenessProbeMissing: warning
-  # networking
-  hostNetworkSet: warning
-  hostPortSet: warning
+  # efficiency
+  cpuRequestsMissing: warning
+  cpuLimitsMissing: warning
+  memoryRequestsMissing: warning
+  memoryLimitsMissing: warning
   # security
   hostIPCSet: danger
   hostPIDSet: danger
@@ -25,6 +20,8 @@ checks:
   runAsPrivileged: danger
   dangerousCapabilities: danger
   insecureCapabilities: warning
+  hostNetworkSet: warning
+  hostPortSet: warning
 
 exemptions:
   - namespace: kube-system