You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As per CIS benchmark for “CIS Kubernetes benchmark v1.6” ,
we have following rules to be verified or justified for cert-manager. With
respect to cert-manager we are seeing below rules is not compliant with the CIS
Benchmark rules. Can you please check if these are security issues which need
to be addressed or can we get the justifications why these access are required
for cert-manager.
Rule ID
Rule Name
Rationale
Remediation
Impact
Non-compliant resources in cert-manager
5.1.4
Minimize access to create pods
The ability to create pods in a cluster opens up possibilities for privilege escalation and should be restricted, where possible.
Where possible, remove create access to pod objects in the cluster
Care should be taken not to remove access to pods to system components which require this for their operation.
Cluster Role “cert-manager-controller-challenges” having create pod access
5.1.2
Minimize access to secret
Inappropriate access to secrets stored within the Kubernetes cluster can allow for an attacker to gain additional access to the Kubernetes cluster or external resources whose credentials are stored as secrets.
Where possible, remove get, list and watch access to secret objects in the cluster
Care should be taken not to remove access to secrets to system components which require this for their operation
Cluster Roles cert-manager-cainjector, cert-manager-controller-issuers, cert-manager-controller-clusterissuers, cert-manager-controller-certificates, cert-manager-controller-orders, cert-manager-controller-challenges are having get, list, watch access to secrets
5.1.6
Ensure that Service Account Tokens are only mounted where necessary
Mounting service account tokens inside pods can provide an avenue for privilege escalation attacks where an attacker is able to compromise a single pod in the cluster. Avoiding mounting these tokens removes this attack avenue.
Modify the definition of pods and service accounts which do not need to mount service account tokens to disable it.
Pods mounted without service account tokens will not be able to communicate with the API server, except where the resource is available to unauthenticated principals
cert-manager pods(cert-manager-, cert-manager-cainjector-, cert-manager-webhook-) are not having "automountServiceAccountToken" set to false.
5.6.2
Ensure that the seccomp profile is set to docker/default in your pod definitions
Seccomp (secure computing mode) is used to restrict the set of system calls applications can make, allowing cluster administrators greater control over the security of workloads running in the cluster. Kubernetes disables seccomp profiles by default for historical reasons. You should enable it to ensure that the workloads have restricted actions available within the container.
To enable the default seccomp profile, use the reserved value /runtime/default that will make sure that the pod uses the default policy available on the host.
If the default seccomp profile is too restrictive for you, you will need to create and manage your own seccomp profiles.
cert-manager pods are not having seccomp profile defined.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi Team,
As per CIS benchmark for “CIS Kubernetes benchmark v1.6” , we have following rules to be verified or justified for cert-manager. With respect to cert-manager we are seeing below rules is not compliant with the CIS Benchmark rules. Can you please check if these are security issues which need to be addressed or can we get the justifications why these access are required for cert-manager.
Beta Was this translation helpful? Give feedback.
All reactions