Security policies
In the Security section, pages for managing cluster security policies based on Kyverno are available:
- Security Policy Manager;
- Security policy report.
Security Policy Manager
The page is a table listing security policies with the following columns:
- Name (filtering available)
- Creation date (sorting available)
On this page, you can create, view, edit, and delete security policies.
Screenshot
To add a policy, use manifest import. Click + Add security policy.
Screenshot
The policy view page has four tabs: policy, labels and annotations, events, and manifest.
Screenshot
You can edit a security policy using a YAML manifest. Go to the Manifest tab and make changes. After editing the manifest, click Verify. The verification result appears on the right side of the screen. Expand the verification result block to view the full manifest.
Screenshot
For more information about policies, see the official Kyverno website.
Security policy report
The page shows security policy analysis results. You can view results:
- by policy;
Screenshot
- by namespace.
Screenshot
The security policy report also supports filtering by system or user namespaces. By default, the report shows all namespaces. To filter namespaces, select the required filter from the drop-down list in the upper-right corner.
Screenshot
Exporting the report
You can download the report in CSV or PDF format.
MS Excel 2019 and later
To import a CSV report into MS Excel 2019 and later:
- Create a new MS Excel file and go to the Data section.
Screenshot
Screenshot
Screenshot
MS Excel 2018 and earlier
To import a CSV report into MS Excel 2018 and earlier:
- Create a new MS Excel file and go to the Data section.
Screenshot
Screenshot
Screenshot
Screenshot
Screenshot
Screenshot
Recommended policies
To add a policy, go to the manifest import interface, paste the required policies, and click Verify. After successful verification, click Upload.
absence-of-cpu-requests
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
annotations:
meta.helm.sh/release-name: shturval-policies
meta.helm.sh/release-namespace: kyverno
policies.kyverno.io/category: infosec
policies.kyverno.io/description: Kubernetes can set and limit CPU consumption
for running containers. If limits are missing, Denial of Service (DoS) may occur
because a pod (container) can use all node resources available to it. Therefore,
setting CPU resource requests is considered a best practice.
policies.kyverno.io/severity: High
policies.kyverno.io/title: CPU Requests checker
labels:
app.kubernetes.io/managed-by: Helm
name: absence-of-cpu-requests
spec:
admission: true
background: true
failurePolicy: Ignore
rules:
- match:
any:
- resources:
kinds:
- Pod
name: check-for-cpu-requests
skipBackgroundRequests: true
validate:
foreach:
- list: request.object.spec.[initContainers, containers][]
pattern:
resources:
requests:
cpu: ?*
message: CPU requests are not set for Container/InitContainer
schemaValidation: true
validationFailureAction: Audit
webhookTimeoutSeconds: 10
absence-of-ram-requests-limits
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
annotations:
meta.helm.sh/release-name: shturval-policies
meta.helm.sh/release-namespace: kyverno
policies.kyverno.io/category: infosec
policies.kyverno.io/description: Kubernetes can limit RAM consumption for running
containers. If these parameters are not set, Denial of Service (DoS) may occur
because a pod (container) can use all node resources available to it. Therefore,
setting RAM resource requests and limits is considered a best practice.
policies.kyverno.io/severity: High
policies.kyverno.io/title: RAM Requests and Limits checker
generation: 1
labels:
app.kubernetes.io/managed-by: Helm
name: absence-of-ram-requests-limits
spec:
admission: true
background: true
failurePolicy: Ignore
rules:
- match:
any:
- resources:
kinds:
- Pod
name: check-for-ram-requests
skipBackgroundRequests: true
validate:
foreach:
- list: request.object.spec.[initContainers, containers][]
pattern:
resources:
requests:
memory: ?*
message: RAM requests are not set for Container/InitContainer
- match:
any:
- resources:
kinds:
- Pod
name: check-for-ram-limits
skipBackgroundRequests: true
validate:
foreach:
- list: request.object.spec.[initContainers, containers][]
pattern:
resources:
limits:
memory: ?*
message: RAM limits are not set for Container/InitContainer
schemaValidation: true
validationFailureAction: Audit
webhookTimeoutSeconds: 10
automated-satoken-mount-used
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
annotations:
meta.helm.sh/release-name: shturval-policies
meta.helm.sh/release-namespace: kyverno
policies.kyverno.io/category: infosec
policies.kyverno.io/description: 'By default, Kubernetes mounts a ServiceAccount
token into pods. This token can be used to interact with the API server, which
most pods do not require. It is recommended to disable this behavior and enable
it only where truly needed. '
policies.kyverno.io/severity: High
policies.kyverno.io/title: automountServiceAccountToken is set to true
generation: 1
labels:
app.kubernetes.io/managed-by: Helm
name: automated-satoken-mount-used
spec:
admission: true
background: true
failurePolicy: Ignore
rules:
- match:
any:
- resources:
kinds:
- Pod
name: check-for-automount-serviceaccount-token
skipBackgroundRequests: true
validate:
message: Automatic ServiceAccount token mounting is enabled in Pod
pattern:
spec:
automountServiceAccountToken: "false"
schemaValidation: true
validationFailureAction: Audit
webhookTimeoutSeconds: 10
container-is-privileged
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
annotations:
meta.helm.sh/release-name: shturval-policies
meta.helm.sh/release-namespace: kyverno
policies.kyverno.io/category: infosec
policies.kyverno.io/description: 'This flag runs a container in privileged mode,
which an attacker can abuse. For example, to escalate privileges and expand an
attack against the cluster. Most containers do not require this flag, so it is
recommended not to use it. '
policies.kyverno.io/severity: High
policies.kyverno.io/title: privileged flag in spec.containers is set to true
generation: 1
labels:
app.kubernetes.io/managed-by: Helm
name: container-is-privileged
spec:
admission: true
background: true
failurePolicy: Ignore
rules:
- match:
any:
- resources:
kinds:
- Pod
name: check-for-privileged
skipBackgroundRequests: true
validate:
message: Container with privileged flag detected
pattern:
spec:
containers:
- =(securityContext):
=(privileged): "false"
schemaValidation: true
validationFailureAction: Audit
webhookTimeoutSeconds: 10
default-ns-is-used
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
annotations:
meta.helm.sh/release-name: shturval-policies
meta.helm.sh/release-namespace: kyverno
pod-policies.kyverno.io/autogen-controllers: none
policies.kyverno.io/category: infosec
policies.kyverno.io/description: 'Using the namespace named "default" is not
recommended. It is considered best practice to use dedicated namespaces for
teams and/or applications. '
policies.kyverno.io/severity: High
policies.kyverno.io/title: deployment to default namespace
generation: 1
labels:
app.kubernetes.io/managed-by: Helm
name: default-ns-is-used
spec:
admission: true
background: true
failurePolicy: Ignore
rules:
- match:
resources:
kinds:
- Pod
name: check-for-default-ns
skipBackgroundRequests: true
validate:
message: Resource detected in the default namespace
pattern:
metadata:
namespace: '!default'
- match:
resources:
kinds:
- DaemonSet
- Deployment
- Job
- CronJob
- StatefulSet
name: check-for-default-ns-pod-controller
skipBackgroundRequests: true
validate:
message: Resource detected in the default namespace
pattern:
metadata:
namespace: '!default'
schemaValidation: true
validationFailureAction: Audit
webhookTimeoutSeconds: 10
hostnetwork-is-used
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
annotations:
meta.helm.sh/release-name: shturval-policies
meta.helm.sh/release-namespace: kyverno
policies.kyverno.io/category: infosec
policies.kyverno.io/description: 'Using hostNetwork bypasses network policy requirements
because, from the network plugin perspective, the pod is on a different network
(the node network). '
policies.kyverno.io/severity: medium
policies.kyverno.io/title: hostNetwork is set to `true`
generation: 1
labels:
app.kubernetes.io/managed-by: Helm
managedFields:
- apiVersion: kyverno.io/v1
name: hostnetwork-is-used
spec:
admission: true
background: true
failurePolicy: Ignore
rules:
- match:
any:
- resources:
kinds:
- Pod
name: check-for-hostnetwork
skipBackgroundRequests: true
validate:
message: 'Pod uses the node network. It is recommended to remove or disable
the hostNetwork parameter '
pattern:
spec:
=(hostNetwork): "false"
schemaValidation: true
validationFailureAction: Audit
webhookTimeoutSeconds: 10
master-tolerations-are-set
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
annotations:
meta.helm.sh/release-name: shturval-policies
meta.helm.sh/release-namespace: kyverno
policies.kyverno.io/category: infosec
policies.kyverno.io/description: 'Using tolerations allows pods to run on nodes
with matching taints. It is considered best practice not to run pods on control
plane nodes, which by default have the taint node-role.kubernetes.io/master:NoSchedule '
policies.kyverno.io/severity: Medium
policies.kyverno.io/title: Tolerations for scheduling on ControlPlane Nodes
generation: 1
labels:
app.kubernetes.io/managed-by: Helm
name: master-tolerations-are-set
spec:
admission: true
background: true
failurePolicy: Ignore
rules:
- match:
resources:
kinds:
- Pod
name: check-for-tolerations
skipBackgroundRequests: true
validate:
message: Tolerations detected that schedule a Pod on a control plane node with taints
`node-role.kubernetes.io/control-plane:NoSchedule`
pattern:
spec:
=(tolerations):
- key: '!node-role.kubernetes.io/control-plane'
schemaValidation: true
validationFailureAction: Audit
webhookTimeoutSeconds: 10
secrets-in-env-var
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
annotations:
meta.helm.sh/release-name: shturval-policies
meta.helm.sh/release-namespace: kyverno
policies.kyverno.io/category: infosec
policies.kyverno.io/description: 'Secrets specified as environment variables
can be compromised. It is recommended to use external secret management systems. '
policies.kyverno.io/severity: High
policies.kyverno.io/title: secrets are stored in env vars
generation: 1
name: secrets-in-env-var
spec:
admission: true
background: true
failurePolicy: Ignore
rules:
- match:
any:
- resources:
kinds:
- Pod
name: check-for-secrets-in-env
skipBackgroundRequests: true
validate:
foreach:
- list: request.object.spec.[initContainers, containers][]
pattern:
=(env):
- =(valueFrom):
X(secretKeyRef): "null"
message: Secrets detected in environment variables
schemaValidation: true
validationFailureAction: Audit
webhookTimeoutSeconds: 10
service-nodeport-used
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
annotations:
meta.helm.sh/release-name: shturval-policies
meta.helm.sh/release-namespace: kyverno
policies.kyverno.io/category: infosec
policies.kyverno.io/description: 'NodePort can be used to expose cluster applications
externally. However, this approach is not a best practice and cannot be controlled
with NetworkPolicy. It is recommended to use alternatives such as Ingress for
external access to cluster applications. '
policies.kyverno.io/severity: High
policies.kyverno.io/title: service type is set to NodePort
generation: 1
labels:
app.kubernetes.io/managed-by: Helm
name: service-nodeport-used
spec:
admission: true
background: true
failurePolicy: Ignore
rules:
- match:
any:
- resources:
kinds:
- Service
name: check-for-nodeport
skipBackgroundRequests: true
validate:
message: Service type NodePort detected. It is recommended to use Ingress
pattern:
spec:
type: '!NodePort'
schemaValidation: true
validationFailureAction: Audit
webhookTimeoutSeconds: 10
sysadmin-capabilities-used
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
annotations:
meta.helm.sh/release-name: shturval-policies
meta.helm.sh/release-namespace: kyverno
policies.kyverno.io/category: infosec
policies.kyverno.io/description: 'This Linux capability has extremely broad privileges
(according to Linux Capabilities documentation: CAP_SYS_ADMIN - this capability
is overloaded, Don''t choose CAP_SYS_ADMIN if you can possibly avoid it!). Most
applications do not require it. Therefore, this capability should appear as
rarely as possible. Using it can lead to security issues, including container
escape from a pod (container). '
policies.kyverno.io/severity: High
policies.kyverno.io/title: SYS_ADMIN capability added to container
generation: 1
labels:
app.kubernetes.io/managed-by: Helm
name: sysadmin-capabilities-used
spec:
admission: true
background: true
failurePolicy: Ignore
rules:
- match:
any:
- resources:
kinds:
- Pod
name: check-for-sysadmin-capabilities-enabled
skipBackgroundRequests: true
validate:
foreach:
- deny:
conditions:
any:
- key: SYS_ADMIN
operator: AnyIn
value: '{{ element.securityContext.capabilities.add || '''' }}'
list: request.object.spec.[initContainers, containers][]
message: SYS_ADMIN is set in Capabilities for Container/InitContainer
schemaValidation: true
validationFailureAction: Audit
webhookTimeoutSeconds: 10