Security

These checks are related to security concerns. Workloads that fail these checks may make your cluster more vulnerable, often by introducing a path for privilege escalation.

key	default	description
`hostIPCSet`	`danger`	Fails when `hostIPC` attribute is configured.
`hostPIDSet`	`danger`	Fails when `hostPID` attribute is configured.
`notReadOnlyRootFilesystem`	`warning`	Fails when `securityContext.readOnlyRootFilesystem` is not true.
`privilegeEscalationAllowed`	`danger`	Fails when `securityContext.allowPrivilegeEscalation` is true.
`runAsRootAllowed`	`warning`	Fails when `securityContext.runAsNonRoot` is not true.
`runAsPrivileged`	`danger`	Fails when `securityContext.privileged` is true.
`insecureCapabilities`	`warning`	Fails when `securityContext.capabilities` includes one of the capabilities listed here
`dangerousCapabilities`	`danger`	Fails when `securityContext.capabilities` includes one of the capabilities listed here
`hostNetworkSet`	`warning`	Fails when `hostNetwork` attribute is configured.
`hostPortSet`	`warning`	Fails when `hostPort` attribute is configured.
`tlsSettingsMissing`	`warning`	Fails when an Ingress lacks TLS settings.
`automountServiceAccountToken`	`ignore`	Fails if service account tokens are automounted to pods
`clusterrolePodExecAttach`	`warning`	Fails if a ClusterRole is able to exec into pods
`clusterrolebindingClusterAdmin`	`warning`	Fails if a ClusterRoleBinding is attached to the admin role
`clusterrolebindingPodExecAttach`	`warning`	Fails if a ClusterRoleBinding is able to exec into pods
`rolePodExecAttach`	`warning`	Fails if a Role is able to exec into pods
`rolebindingClusterAdminClusterRole`	`warning`	Fails if a RoleBinding is attached to the cluster admin role
`rolebindingClusterAdminRole`	`warning`	Fails if a RoleBinding is attached to the admin role
`rolebindingClusterRolePodExecAttach`	`warning`	Fails if a RoleBinding is able to exec into pods in any namespace
`rolebindingRolePodExecAttach`	`warning`	Fails if a RoleBinding is able to exec into pods in its namespace
`linuxHardening`	`warning`	Fails if one of AppArmor, Seccomp, SELinux, or dropping Linux Capabilities are not used to limit unwanted privileges
`missingNetworkPolicy`	`warning`	Fails if a controller lacks a corresponding NetworkPolicy
`sensitiveConfigmapContent`	`warning`	Fails if a ConfigMap contains a likely password or secret
`sensitiveContainerEnvVar`	`warning`	Fails if a controller has an environment variable hard-coded to a likely password or secret

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, 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.

4.8 KiB Raw Permalink Blame History

Security

Background

Further Reading

4.8 KiB

Raw Permalink Blame History