Restrict Access to Secrets

Risk Level: High (not acceptable risk)

Ensure that access to secrets is restricted across your OCI Kubernetes Engine (OKE) clusters as the Kubernetes API stores sensitive data, such as service account tokens or workload credentials. Restricting access to secrets is vital for reducing privilege escalation risk.

Security

Unauthorized access to Kubernetes secrets enables an attacker to gain further access to the OKE cluster or exploit external resources whose credentials are exposed, thus leading to potential data theft, service disruption, or system compromise.

Audit

To determine if the access to secrets is restricted across your OCI Kubernetes Engine (OKE) clusters, perform the following operations:

Using OCI CLI

Run iam compartment list command (Windows/macOS/Linux) with output query filters to list the ID of each compartment available in your Oracle Cloud Infrastructure (OCI) account:
```
oci iam compartment list
	--all
	--include-root
	--query 'data[]."id"'
```

The command output should return the requested OCI compartment identifiers (OCIDs):

[
	"ocid1.tenancy.oc1..aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd",
	"ocid1.compartment.oc1..abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234abcd"
]

Run ce cluster list command (Windows/macOS/Linux) with the ID of the OCI compartment that you want to examine as the identifier parameter, to list the ID of each OCI Kubernetes Engine (OKE) cluster available in the selected OCI compartment:
```
oci ce cluster list
	--compartment-id 'ocid1.tenancy.oc1..aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd'
	--all
	--query 'data[]."id"'
```

The command output should return the requested OKE cluster IDs:

[
	"ocid1.cluster.oc1.ap-sydney-1.aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd",
	"ocid1.cluster.oc1.ap-sydney-1.abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234abcd"
]

Run ce cluster create-kubeconfig command (Windows/macOS/Linux) with the ID of the OCI Kubernetes Engine (OKE) cluster that you want to access as the identifier parameter, to generate and configure the Kubernetes configuration file (kubeconfig) that the kubectl tool needs to securely communicate with and manage the selected OKE cluster:
```
oci ce cluster create-kubeconfig
	--cluster-id 'ocid1.cluster.oc1.ap-sydney-1.aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd'
	--file $HOME/.kube/config
	--kube-endpoint PUBLIC_ENDPOINT
	--region 'ap-sydney-1'
	--token-version 2.0.0
```
The command output should return the path to the new Kubeconfig file:
```
New config written to the Kubeconfig file /home/user/.kube/config
```
Run the kubectl auth command to check the Kubernetes API server's authorization layer in order to determine if any authenticated user (anyone who can successfully log in to the cluster) has the permissions to read (get, list, or watch) secrets across all cluster namespaces:
```
kubectl auth can-i get,list,watch secrets --all-namespaces --as=system:authenticated
```
The command output should return yes or no. If the command output is yes, it indicates a critical security vulnerability. This means anyone who can log in to your cluster (any user or service account) has the ability to read all secret data (passwords, tokens, keys) in the cluster namespaces. If the command output is no (recommended), it confirms that general authenticated users do not automatically receive broad permissions to read secret data:
```
yes
```
If the command output returns yes, any user or service account that successfully authenticates to the selected OKE cluster has the ability to read all secrets across all namespaces, indicating a severe security vulnerability.

Remediation / Resolution

To implement the Principle of Least Privilege (POLP), ensure that access to secrets is restricted across your OCI Kubernetes Engine (OKE) clusters. This can be achieved by removing or preventing the get, list, and watch permissions on secret objects for non-privileged users and service accounts:

Using OCI CLI

Run iam compartment list command (Windows/macOS/Linux) with output query filters to list the ID of each compartment available in your Oracle Cloud Infrastructure (OCI) account:
```
oci iam compartment list
	--all
	--include-root
	--query 'data[]."id"'
```

The command output should return the requested OCI compartment identifiers (OCIDs):

[
	"ocid1.tenancy.oc1..aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd",
	"ocid1.compartment.oc1..abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234abcd"
]

Run ce cluster list command (Windows/macOS/Linux) with the ID of the OCI compartment that you want to examine as the identifier parameter, to list the ID of each OCI Kubernetes Engine (OKE) cluster available in the selected OCI compartment:
```
oci ce cluster list
	--compartment-id 'ocid1.tenancy.oc1..aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd'
	--all
	--query 'data[]."id"'
```

The command output should return the requested OKE cluster IDs:

[
	"ocid1.cluster.oc1.ap-sydney-1.aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd",
	"ocid1.cluster.oc1.ap-sydney-1.abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234abcd"
]

Run ce cluster create-kubeconfig command (Windows/macOS/Linux) with the ID of the OCI Kubernetes Engine (OKE) cluster that you want to access as the identifier parameter, to generate and configure the Kubernetes configuration file (kubeconfig) that the kubectl tool needs to securely communicate with and manage the selected OKE cluster:
```
oci ce cluster create-kubeconfig
	--cluster-id 'ocid1.cluster.oc1.ap-sydney-1.aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd'
	--file $HOME/.kube/config
	--kube-endpoint PUBLIC_ENDPOINT
	--region 'ap-sydney-1'
	--token-version 2.0.0
```
The command output should return the path to the new Kubeconfig file:
```
New config written to the Kubeconfig file /home/user/.kube/config
```
Run the kubectl get clusterrolebindings command to list all cluster role bindings in your OCI Kubernetes Engine (OKE) cluster. This action is necessary to identify which principals have been granted the highly privileged "cluster-admin" role across the entire OKE cluster. Since the "cluster-admin" role provides unrestricted access, identifying these role bindings is critical for auditing access to sensitive resources like secrets:
```
kubectl get clusterrolebindings -o=custom-columns=NAME:.metadata.name,ROLE:.roleRef.name,SUBJECT:.subjects[*].name
```

The command output should return a list where the ROLE column describes the "cluster-admin" role for any resource listed, identifying the specific SUBJECT (principal) that possesses full, unrestricted administrative permissions across the OKE cluster. Review each principal listed in the command output and ensure that "cluster-admin" role is required for it. When auditing for privileged access, focus on role bindings that don't have the system: prefix, as those are usually created by OKE cluster operators or users and are safe to modify or delete. These bindings must be audited to ensure the principal requires access to secrets:

NAME                                                   ROLE                                                      SUBJECT
admin-user-binding                                     cluster-admin                                             project5-dev-group
security-group-binding                                 cluster-admin                                             security-admins-group
external-audit-binding                                 cluster-admin                                             external-auditor-sa
cluster-admin                                          cluster-admin                                             system:masters

...                                                    ...                                                       ...

cluster-admin                                          cluster-admin                                             system:masters
system:node-proxier                                    system:node-proxier                                       system:kube-proxy
system:service-account-issuer-discovery                system:service-account-issuer-discovery                   system:serviceaccounts
system:volume-scheduler                                system:volume-scheduler                                   ystem:kube-scheduler

To enforce the Principle of Least Privilege, remove the "cluster-admin" cluster role binding for all principals that don't require access to secrets. Ensure that the role binding that you want to remove don't have the system: prefix as this is required for the operation of system components. Replace \<cluster-role-binding-name\> with your own role binding:
```
kubectl delete clusterrolebinding <cluster-role-binding-name>
```
The command output should return the role binding removal confirmation, as shown in the example below:
```
clusterrolebinding.rbac.authorization.k8s.io "<cluster-role-binding-name>" deleted
```

References

Oracle Cloud Infrastructure Documentation
Overview of Kubernetes Engine (OKE)
Managing Kubernetes Clusters
Setting Up Cluster Access
Accessing a Cluster Using Kubectl
About Access Control and Kubernetes Engine (OKE)

Oracle Cloud Infrastructure CLI Documentation
compartment list
cluster list
cluster create-kubeconfig

Kubernetes Documentation
Using RBAC Authorization

Publication date Dec 11, 2025

Audit

Using OCI CLI

Remediation / Resolution

Using OCI CLI

References

Related OCI-OKE rules