Restrict Wildcard Resources

Description

Wildcards (*) in resources grant access to all of the resources referenced by the given API group and does not follow the principal of least privilege. As much as possible, avoid such open resources unless scoped to perhaps a custom API group. This policy blocks any Role or ClusterRole that contains a wildcard entry in the resources list found in any rule.

Risks

Risks associated with using wildcard (*) in resources:

• Privilege Escalation: If a user or service account with wildcard permissions is compromised, an attacker can gain unrestricted access to all resources in the namespace (or across the cluster if it’s a ClusterRole). This can cause the attacker to perform critical actions such as creating, modifying, or deleting resources based on the verbs set in the Role or ClusterRole, thereby escalating privileges and causing widespread damage.

Kyverno Policy

Refer to the Nirmata curated policies - restrict-wildcard-resources.

Resource Example

Below is an example of a ClusterRole resource that does not include any wildcards for resources.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: goodcr01
rules:
- apiGroups: [""]
  resources: ["pods", "namespaces"]
  verbs: ["get", "watch", "list"]
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "watch", "list"]

Below is an example of a Role resource that does not include any wildcards for resources.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: goodcr03
rules:
- apiGroups: ["batch"]
  resources: ["secrets"]
  verbs: ["create", "update", "patch"]