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. 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.
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. In these cases, this technique may be used in conjunction with Additional Cloud Roles.
Require multi-factor authentication for user accounts integrated into container clusters through cloud deployments or via authentication protocols such as LDAP or SAML.
|M1018||User Account Management||
Ensure that low-privileged accounts do not have permissions to add permissions to accounts or to update container cluster roles.
|ID||Data Source||Data Component||Detects|
|DS0002||User Account||User Account Modification||
Collect usage logs from accounts to identify unusual activity in the assignment of roles to those accounts. Monitor for accounts assigned to high-privileged cluster roles that go over a certain threshold of known admins.