This module enforces the security policies in the cluster according to the Kubernetes Pod Security Standards using the Gatekeeper solution.
The Pod Security Standards define three different policies to broadly cover the security spectrum. These policies are cumulative and range from highly-permissive to highly-restrictive:
Privileged
— Unrestricted policy. Provides the widest possible permission level (used by default).Baseline
— Minimally restrictive policy which prevents known privilege escalations. Allows for the default (minimally specified) Pod configuration.Restricted
— Heavily restricted policy. Follows the most current Pod hardening best practices.
You can read more about each policy variety in the Kubernetes documentation.
To apply a policy set the label security.deckhouse.io/pod-policy =<POLICY_NAME>
to the corresponding namespace.
Example of the command to set the Restricted
policy for all Pods in the my-namespace
Namespace.
kubectl label ns my-namespace security.deckhouse.io/pod-policy=restricted
The policies define by the module can be expanded. Examples of policy extensions can be found in the FAQ.
Operation policies
The module provides a set of operating policies and best practices for the secure operation of your applications. We recommend you deploy the following minimum set of operating policies:
---
apiVersion: deckhouse.io/v1alpha1
kind: OperationPolicy
metadata:
name: common
spec:
policies:
allowedRepos:
- myrepo.example.com
- registry.deckhouse.io
requiredResources:
limits:
- memory
requests:
- cpu
- memory
disallowedImageTags:
- latest
requiredProbes:
- livenessProbe
- readinessProbe
maxRevisionHistoryLimit: 3
imagePullPolicy: Always
priorityClassNames:
- production-high
- production-low
checkHostNetworkDNSPolicy: true
checkContainerDuplicates: true
match:
namespaceSelector:
labelSelector:
matchLabels:
operation-policy.deckhouse.io/enabled: "true"
To apply the policy, it will be sufficient to set the label operation-policy.deckhouse.io/enabled: "true"
on the desired namespace.
The above policy is generic and recommended by Deckhouse team. Similarly, you can configure your own policy with the necessary settings.
Security policies
The module allows defining security policies for making sure the workload running in the cluster meets certain security requirements.
An example of a security policy:
---
---
apiVersion: deckhouse.io/v1alpha1
kind: SecurityPolicy
metadata:
name: mypolicy
spec:
enforcementAction: Deny
policies:
allowHostIPC: true
allowHostNetwork: true
allowHostPID: false
allowPrivileged: false
allowedFlexVolumes:
- driver: vmware
allowedHostPorts:
- max: 4000
min: 2000
allowedProcMount: Unmasked
allowedAppArmor:
- unconfined
allowedUnsafeSysctls:
- kernel.*
allowedVolumes:
- hostPath
- projected
fsGroup:
ranges:
- max: 200
min: 100
rule: MustRunAs
readOnlyRootFilesystem: true
requiredDropCapabilities:
- ALL
runAsGroup:
ranges:
- max: 500
min: 300
rule: RunAsAny
runAsUser:
ranges:
- max: 200
min: 100
rule: MustRunAs
seccompProfiles:
allowedLocalhostFiles:
- my_profile.json
allowedProfiles:
- Localhost
supplementalGroups:
ranges:
- max: 133
min: 129
rule: MustRunAs
match:
namespaceSelector:
labelSelector:
matchLabels:
enforce: mypolicy
To apply the policy, it will be sufficient to set the label enforce: "mypolicy"
on the desired namespace.
Modifying Kubernetes resources
The module also allows you to use the Gatekeeper’s Custom Resources to easily modify objects in the cluster, such as
AssignMetadata
— defines changes to the metadata section of a resource.Assign
— any change outside the metadata section.ModifySet
— adds or removes entries from a list, such as the arguments to a container.
Example:
apiVersion: mutations.gatekeeper.sh/v1
kind: AssignMetadata
metadata:
name: demo-annotation-owner
spec:
match:
scope: Namespaced
namespaces: ["default"]
kinds:
- apiGroups: [""]
kinds: ["Pod"]
location: "metadata.annotations.foo"
parameters:
assign:
value: "bar"
You can read more about the available options in the gatekeeper documentation.