More Info:
The pods/create permission lets a principal effectively run code as any service account in the namespace. Limit it to controllers and CI accounts and audit any human grant.Risk Level
HighAddress
Compliance, SecurityCompliance Standards
- CIS OKE
Triage and Remediation
- Remediation
Remediation
Using Console
Using Console
In OKE this is enforced with Kubernetes RBAC, not a direct “toggle” in the OCI Console. You use the OCI Console to get kubeconfig and then apply RBAC that removes
All users in the OCI group
Summary:
create permissions on Pods for everyone except specific roles/groups.Below are the minimal console-driven steps.1. Make sure users don’t get cluster‑admin by default
- In OCI Console, go to Identity & Security → Policies.
- Look for policies like:
allow group <some-group> to manage cluster-family in compartment <compartment-name>allow group <some-group> to manage all-resources in compartment <compartment-name>
- Either:
- Remove these broad policies, or
- Replace them with more limited ones, such as:
Note: OCI IAM controls who can talk to the cluster endpoint and perform some OKE‑level actions, but Kubernetes RBAC controls who can create Pods.
2. Use OCI Console to get kubeconfig for an admin user
- In OCI Console, go to Developer Services → Kubernetes Clusters (OKE).
- Click your cluster.
- Click Access Cluster.
- Under Kubeconfig, choose Local access (or appropriate method).
- Click Copy or Download kubeconfig and configure
~/.kube/configas instructed.
kubectl to apply the RBAC restrictions.3. Create restricted Kubernetes roles (block Pod creation)
Define roles that don’t includecreate on Pods and bind normal users to them.- Create a file
restricted-role.yamlwith:
- Apply it:
4. Bind restricted role to your OCI‑mapped Kubernetes users/groups
In OKE, OCI groups/users are mapped into Kubernetes users/groups based on authentication method. Common pattern (OIDC / IAM Authenticator) is that a user ends up with groups likeoke:group:<oci-group-name>.- Identify the Kubernetes group for your OCI group:
- Ask a test user to run
kubectl config view --minifyandkubectl auth can-i --list - Or check your OKE IAM Authenticator/OIDC integration docs.
- Ask a test user to run
oke:group:Developers.- Create a RoleBinding or ClusterRoleBinding:
- Apply it:
Developers will now have read‑only access to Pods (cannot create them).5. Remove or narrow any existing roles that let users create Pods
If you previously granted broad roles (e.g.,cluster-admin, edit), users might still be able to create Pods.- List current clusterrolebindings:
- For any that bind regular users/groups to high‑privilege roles (
cluster-admin,edit,admin), either:- Delete them:
- Or replace them with bindings to your restricted role (
view-no-pod-create).
- Delete them:
6. (Optional) Restrict Pod creation to a small admin group
If some SRE/Platform team must create Pods:- Create an admin ClusterRole if not already using
edit/admin:
- Bind this only to an ops group:
- Apply it:
7. Verify that normal users cannot create Pods
Using a user from the restricted OCI group:Summary:
- Use OCI Console for: cluster access (kubeconfig) and OCI IAM policies to prevent broad OKE management.
- Use kubectl (via kubeconfig from Console) for: Kubernetes RBAC that removes
createon Pods for normal users and grants it only to a small admin group.
Using CLI
Using CLI
Below is how to restrict who can create Pods in OCI OKE using OCI CLI + kubectl (kubectl is required for Kubernetes RBAC; OCI CLI is used to get kubeconfig and manage IAM).
If you see something like a If you want to edit a role and remove Then remove so it becomes, for example:Save and exit.
Apply with kubectl:Bind it only to trusted subjects:
If you share your current RBAC (e.g. output of
1. Get kubeconfig for your OKE cluster (using OCI CLI)
2. Remove broad permissions to create Pods
If there are existing overly-privileged bindings (e.g., givingcreate on pods to many users/groups), remove or tighten them.Example: list current RBAC:ClusterRole giving create on pods bound to many users/groups, remove or edit it.Example – delete an unsafe binding:create on pods:create from:3. Create a least‑privilege role that can create Pods (if needed)
Define aRole or ClusterRole that only specific users/groups will use to create pods.Example clusterrole-pod-creator.yaml:4. Map OCI IAM users/groups to Kubernetes RBAC
- Create an OCI IAM group (e.g.
oke-pod-creators) and add the right users.
- Let this group access the cluster (OCI IAM policy, using OCI CLI):
- Use OIDC / auth mapping to surface this OCI group into Kubernetes as
oke-pod-creators(OKE automatically maps OCI groups to Kubernetes groups when using IAM auth; group name in Kubernetes will match the OCI group display name).
ClusterRoleBinding created earlier will apply to these users.5. Restrict cluster‑admin / admin access
Ensure only a very small set of admins can still create pods unconstrained.- Identify
cluster-adminbindings:
- Remove or tighten them:
- In OCI IAM, keep
manage cluster-familyin policies only for a very restricted admin group.
6. Validate that pod creation is restricted
- As a non‑authorized user:
- As an authorized user in
oke-pod-creators:
If you share your current RBAC (e.g. output of
kubectl get clusterrolebindings -o yaml), I can give an exact set of edits/commands for your environment.Using Python
Using Python
To restrict who can create Pods in OCI OKE, you must use Kubernetes RBAC on your OKE cluster. The Python part is mainly about applying RBAC objects (ClusterRole / RoleBinding) programmatically.Below is a minimal, practical remediation approach with Python.
1. Prerequisites
- An OKE cluster already running.
kubectlaccess to the cluster (you should beadminor equivalent).- Python installed with:
- Your kubeconfig updated for the OKE cluster (via OCI CLI or console), e.g.:
~/.kube/config to talk to the cluster.2. RBAC Design (what we’re implementing)
Objective:- Only a specific group of users (or service accounts) may create Pods.
- Others can still read/list Pods if you want, but cannot create them.
- Create a
ClusterRolethat grantscreateonpods. - Bind that role to a specific Kubernetes subject:
- Either a service account (safe and recommended).
- Or users/groups matching your OIDC/OCI IAM integration (advanced).
- Namespace:
restricted-apps - ServiceAccount:
pod-creator - You will only allow that service account to create Pods in that namespace.
3. Python Script to Apply RBAC
This script:- Ensures the namespace exists.
- Creates a
ServiceAccountnamedpod-creator. - Creates a
Role(namespace-scoped) that allowscreateonpods. - Binds that role to the
pod-creatorservice account viaRoleBinding.
4. How This Remediates “Ability to Create Pods Should Be Restricted”
- By default, many OKE clusters grant broad rights via
cluster-adminor wideRoleBindings. - You must:
- Audit and tighten existing RBAC (manually or with additional scripts):
- Remove or limit any
ClusterRoleBindingthat givescreateon pods to broad subjects likesystem:authenticatedor generic groups.
- Remove or limit any
- Use scripts like the above to:
- Define explicit, narrow permissions for pod creation.
- Bind them only to the identities that truly need it.
- Audit and tighten existing RBAC (manually or with additional scripts):
kubectl get clusterrolebinding -o yaml output (redacted), I can give a Python snippet to systematically remove unsafe bindings as well.Using Terraform
Using Terraform

