Restrict the Ability to Create Pods

Risk Level: Medium (should be achieved)

Enforce the Principle of Least Privilege (POLP) for users creating pods within your OCI Kubernetes Engine (OKE) clusters. The ability to create pods can enable privilege escalation by assigning privileged service accounts or mounting sensitive host volumes.

Security

The capability to create pods in an OCI Kubernetes Engine (OKE) cluster must be tightly controlled due to its potential for privilege escalation. Granting this access unnecessarily increases the security risk, as users could assign privileged service accounts or mount host volumes with sensitive data. Enforce the Principle of Least Privilege (POLP) and restrict pod creation wherever possible.

Audit

To determine if the ability to create pods is restricted across your OCI Kubernetes Engine (OKE) cluster, 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 create pods across all namespaces:
```
kubectl auth can-i create pods --all-namespaces --as=system:authenticated
```
The command output should return yes or no. If the command output returns yes, anyone who can log in to your OKE cluster (any user or service account) has the ability to create pods in all namespaces, which is a common vector for privilege escalation (e.g., mounting sensitive host paths). If the command output is no (recommended), it confirms that general authenticated users do not automatically receive broad permissions to create pods:
```
yes
```
If the command output returns yes, any user or service account that successfully authenticates to the selected OKE cluster has the ability to create pods across all namespaces and this is considered a security risk.

Remediation / Resolution

To implement the Principle of Least Privilege (POLP), ensure that pod creation access is restricted across your OCI Kubernetes Engine (OKE) clusters. This can be achieved by revoking the pod creation privilege from all 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, which provides implicit access to create pods with elevated permissions:
```
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 in order to ensure the principal requires global pod creation privileges:

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 (POLP) and remove unnecessary access to create privileged pods, delete the "cluster-admin binding" for all principals that do not strictly require it. 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