Info icon
End of Life Notice: For Trend Cloud One™ - Conformity Customers, Conformity will reach its End of Sale on “July 31st, 2025” and End of Life “July 31st, 2026”. The same capabilities and much more is available in TrendAI Vision One™ Cloud Risk Management. For details, please refer to Upgrade to TrendAI Vision One™
Use the Knowledge Base AI to help improve your Cloud Posture

Use Dedicated Service Accounts

TrendAI Vision One™ provides continuous assurance that gives peace of mind for your cloud infrastructure, delivering over 1400 automated best practice checks.

Risk Level: Medium (should be achieved)

Ensure that Kubernetes workloads do not use OKE cluster node service accounts to authenticate to OCI APIs, and provision a dedicated service account for every workload that requires OCI IAM access.

Security

Avoid manual OKE authentication approaches. Storing service account keys in Kubernetes secrets requires difficult manual key rotation, while utilizing the underlying node's IAM service account is a Principle of Least Privilege (POLP) violation because every pod on that node gains access to services needed by only one, leading to excessive permissions..


Audit

To determine if dedicated service accounts are used for your OCI Kubernetes Engine (OKE) cluster, perform the following operations:

Using OCI CLI

  1. 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"'
    
  2. The command output should return the requested OCI compartment identifiers (OCIDs):

    [
    	"ocid1.tenancy.oc1..aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd",
    	"ocid1.compartment.oc1..abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234abcd"
    ]
    
  3. 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"'
    
  4. The command output should return the requested OKE cluster IDs:

    [
    	"ocid1.cluster.oc1.ap-sydney-1.aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd",
    	"ocid1.cluster.oc1.ap-sydney-1.abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234abcd"
    ]
    
  5. 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
    
  6. The command output should return the path to the new Kubeconfig file:

    New config written to the Kubeconfig file /home/user/.kube/config
    
  7. Run the kubectl get namespaces command to identify your Kubernetes user-workload namespaces. A Kubernetes user-workload namespace is a logical partition within an OKE cluster intended for hosting applications and services deployed by users or development teams:

    kubectl get namespaces
    
  8. The command output should return a list with all namespaces. OCI Kubernetes Engine (OKE) clusters come with several default namespaces. Exclude the default OKE system namespaces (i.e., kube-system, kube-public, kube-node-lease, and default) from your check:

    NAME                 STATUS   AGE
    default              Active   16d
    kube-node-lease      Active   16d
    kube-public          Active   16d
    kube-system          Active   16d
    ...
    dev                  Active   16d
    staging              Active   16d
    prod                 Active   16d
    
  9. Run the kubectl get rolebinding command to check for any RoleBinding that grants permissions directly to the default service account within the specified namespace. Replace \<user-workload-namespace\> with the name of your own namespace:

    kubectl get rolebindings -n <user-workload-namespace> -o json | jq -r '.items[] | select(.subjects[]?.name == "default" and .subjects[]?.kind == "ServiceAccount") | .metadata.name'
    
  10. The command output should return the names of the RoleBindings within the specified namespace that grant permissions to the default service account:

    default-metrics-access
    default-developer-access
    

    If the command output returns one or more results, the presence of these RoleBindings confirms that the default service account has been granted explicit, custom privileges, indicating that dedicated service accounts are not being used. To enforce the Principle of Least Privilege (POLP), it is strongly recommended to revoke these bindings. The best practice is to create and use dedicated service accounts for all workloads, explicitly assigning only the necessary permissions to them.

Remediation / Resolution

To ensure that dedicated service accounts are used for OCI Kubernetes Engine (OKE) clusters, perform the following actions:

Using OCI CLI

  1. 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"'
    
  2. The command output should return the requested OCI compartment identifiers (OCIDs):

    [
    	"ocid1.tenancy.oc1..aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd",
    	"ocid1.compartment.oc1..abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234abcd"
    ]
    
  3. 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"'
    
  4. The command output should return the requested OKE cluster IDs:

    [
    	"ocid1.cluster.oc1.ap-sydney-1.aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd",
    	"ocid1.cluster.oc1.ap-sydney-1.abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234abcd"
    ]
    
  5. 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
    
  6. The command output should return the path to the new Kubeconfig file:

    New config written to the Kubeconfig file /home/user/.kube/config
    
  7. Run the kubectl create serviceaccount command to create a new dedicated service account the specified namespace. Replace and \<dedicated-service-account\> and \<user-workload-namespace\> with your own information:

    kubectl create serviceaccount <dedicated-service-account> -n <user-workload-namespace>
    
  8. The command output should return the confirmation status:

    serviceaccount/<dedicated-service-account> created
    
  9. Run the kubectl create rolebinding command to grant permissions (RoleBinding). Create a role (or use an existing one) that defines the minimum required access (least privilege), then use a RoleBinding to grant that specific role to your new dedicated service account within the specified namespace. Once the necessary permissions are granted, you can assign the service account to your workload. Replace \<binding-name\>, \<role-name\>, \<dedicated-service-account\> and \<user-workload-namespace\> with your own details:

    kubectl create rolebinding <binding-name> --role=<role-name> --serviceaccount=<user-workload-namespace>:<dedicated-service-account> -n <user-workload-namespace>
    
  10. The command output should return the confirmation status:

    rolebinding.rbac.authorization.k8s.io/<binding-name> created
    

References

Publication date Dec 11, 2025