Skip to main content

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

High

Address

Compliance, Security

Compliance Standards

  • CIS OKE

Triage and Remediation

Remediation

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 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

  1. In OCI Console, go to Identity & Security → Policies.
  2. 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>
  3. Either:
    • Remove these broad policies, or
    • Replace them with more limited ones, such as:
    This ensures they can connect to the cluster but aren’t automatically full OCI administrators for the cluster.
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

  1. In OCI Console, go to Developer Services → Kubernetes Clusters (OKE).
  2. Click your cluster.
  3. Click Access Cluster.
  4. Under Kubeconfig, choose Local access (or appropriate method).
  5. Click Copy or Download kubeconfig and configure ~/.kube/config as instructed.
You will use this kubeconfig with kubectl to apply the RBAC restrictions.

3. Create restricted Kubernetes roles (block Pod creation)

Define roles that don’t include create on Pods and bind normal users to them.
  1. Create a file restricted-role.yaml with:
  1. 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 like oke:group:<oci-group-name>.
  1. Identify the Kubernetes group for your OCI group:
    • Ask a test user to run kubectl config view --minify and kubectl auth can-i --list
    • Or check your OKE IAM Authenticator/OIDC integration docs.
Assume you have a group oke:group:Developers.
  1. Create a RoleBinding or ClusterRoleBinding:
  1. Apply it:
All users in the OCI group 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.
  1. List current clusterrolebindings:
  1. 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).

6. (Optional) Restrict Pod creation to a small admin group

If some SRE/Platform team must create Pods:
  1. Create an admin ClusterRole if not already using edit/admin:
  1. Bind this only to an ops group:
  1. 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 create on Pods for normal users and grants it only to a small admin group.
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).

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., giving create on pods to many users/groups), remove or tighten them.Example: list current RBAC:
If you see something like a ClusterRole giving create on pods bound to many users/groups, remove or edit it.Example – delete an unsafe binding:
If you want to edit a role and remove create on pods:
Then remove create from:
so it becomes, for example:
Save and exit.

3. Create a least‑privilege role that can create Pods (if needed)

Define a Role or ClusterRole that only specific users/groups will use to create pods.Example clusterrole-pod-creator.yaml:
Apply with kubectl:
Bind it only to trusted subjects:

4. Map OCI IAM users/groups to Kubernetes RBAC

  1. Create an OCI IAM group (e.g. oke-pod-creators) and add the right users.
  1. Let this group access the cluster (OCI IAM policy, using OCI CLI):
Create a policy in the same compartment as the OKE cluster:
  1. 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).
Then the 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.
  1. Identify cluster-admin bindings:
  1. Remove or tighten them:
  1. In OCI IAM, keep manage cluster-family in policies only for a very restricted admin group.
Example OCI policy (keep this narrow):

6. Validate that pod creation is restricted

  1. As a non‑authorized user:
  1. 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.
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

  1. An OKE cluster already running.
  2. kubectl access to the cluster (you should be admin or equivalent).
  3. Python installed with:
  4. Your kubeconfig updated for the OKE cluster (via OCI CLI or console), e.g.:
The Python script below will use ~/.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.
We will:
  1. Create a ClusterRole that grants create on pods.
  2. 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).
For simplicity, we’ll assume:
  • 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:
  1. Ensures the namespace exists.
  2. Creates a ServiceAccount named pod-creator.
  3. Creates a Role (namespace-scoped) that allows create on pods.
  4. Binds that role to the pod-creator service account via RoleBinding.

4. How This Remediates “Ability to Create Pods Should Be Restricted”

  • By default, many OKE clusters grant broad rights via cluster-admin or wide RoleBindings.
  • You must:
    1. Audit and tighten existing RBAC (manually or with additional scripts):
      • Remove or limit any ClusterRoleBinding that gives create on pods to broad subjects like system:authenticated or generic groups.
    2. Use scripts like the above to:
      • Define explicit, narrow permissions for pod creation.
      • Bind them only to the identities that truly need it.
If you show me your current kubectl get clusterrolebinding -o yaml output (redacted), I can give a Python snippet to systematically remove unsafe bindings as well.