An adversary may add additional roles or permissions to an adversary-controlled user or service account to maintain persistent access to a container orchestration system. For example, an adversary with sufficient permissions may create a RoleBinding or a ClusterRoleBinding to bind a Role or ClusterRole to a Kubernetes account.[1],[2] Where attribute-based access control (ABAC) is in use, an adversary with sufficient permissions may modify a Kubernetes ABAC policy to give the target account additional permissions.[3]

This account modification may immediately follow Create Account or other malicious account activity. Adversaries may also modify existing Valid Accounts that they have compromised.

Note that where container orchestration systems are deployed in cloud environments, as with Google Kubernetes Engine, Amazon Elastic Kubernetes Service, and Azure Kubernetes Service, cloud-based role-based access control (RBAC) assignments or ABAC policies can often be used in place of or in addition to local permission assignments.[4],[5],[6] In these cases, this technique may be used in conjunction with Additional Cloud Roles.

References

  1. Kubernetes. (n.d.). Role Based Access Control Good Practices. Retrieved March 8, 2023.
  2. Michael Katchinskiy, Assaf Morag. (2023, April 21). First-Ever Attack Leveraging Kubernetes RBAC to Backdoor Clusters. Retrieved July 14, 2023.
  3. Kuberenets. (n.d.). Using ABAC Authorization. Retrieved July 14, 2023.
  4. Google Cloud. (n.d.). Create IAM policies. Retrieved July 14, 2023.
  5. Amazon Web Services. (n.d.). IAM roles for service accounts. Retrieved July 14, 2023.
  6. Microsoft Azure. (2023, April 28). Access and identity options for Azure Kubernetes Service (AKS). Retrieved July 14, 2023.

Länkade ärenden