Views:
Profile applicability: Level 1
The Kubernetes API stores secrets, which may be service account tokens for the Kubernetes API or credentials used by workloads in the cluster. Access to these secrets should be restricted to the smallest possible group of users to reduce the risk of privilege escalation.
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.
Note
Note
By default, the following list of principals have get privileges on secret objects: 
CLUSTERROLEBINDING                                          SUBJECT
TYPE                   SA-NAMESPACE
cluster-admin                                                        system:masters
Group
system:controller:clusterrole-aggregation-controller                 clusterroleaggregation-
controller ServiceAccount kube-system
system:controller:expand-controller                                  expand-controller
ServiceAccount kube-system
system:controller:generic-garbage-collector                          generic-garbagecollector
ServiceAccount kube-system
system:controller:namespace-controller                               namespace-controller
ServiceAccount kube-system
system:controller:persistent-volume-binder                           persistent-volumebinder
ServiceAccount kube-system
system:kube-controller-manager                                       system:kube-controllermanager
User

Impact

Care should be taken not to remove access to secrets to system components which require this for their operation.

Audit

Review the users who have get, list or watch access to secrets objects in the Kubernetes API.

Remediation

Where possible, remove get, list and watch access to secret objects in the cluster.