CloudNativeSecurityCon_2023_ppt.pdf

1、Arun Krishnakumar,VMware IncWhen Sys-Admins QuitProtecting Kubernetes Clusters when Cluster-Admins QuitProblemUsually,humans are operators and owners of Clusters.Humans change teams or companiesWhen Cluster-Owners leave a team,they need to have a way to cleanly transfer ownership of their Kubernetes

2、 Cluster(*)This is with regard to Kubernetes Clusters created using kubeadmSolutionTransfer Cluster ownership to a new userRevoke access from old userScope of Solution clear,but building for this is an afterthoughtWhen the problem appears,developers scramble and present hacky solutionsKubernetes Clu

3、sterLoad BalancerNode1Node3Node2Node4PV1PV2IP Pool,DNAT rulesGPUMetadata:-Secrets-OS access toNodesApplication Data-Separate Problem-Just as complex-Out of scopeKubernetes Cluster ObjectsCloud Infrastructure Objects:Multitenant CloudObjects to be transferred to another user:NodesNetworking component

4、s such as Load-Balancer,DNAT Rules,IP Addresses etc.StorageKubernetes Cluster ObjectsCloud Infrastructure Objects:Multitenant CloudQuota Considerations for new userPermission considerations:new user must have access to resources that old user hasEvery object of the cluster needs to be transferred to

5、 the new user:both logical and physical objectsAdministrator to have access to both objects and be able to transferKubernetes Cluster ObjectsCloud Infrastructure Objects:LogicalCertificatesRoot-Access to NodesUser Accounts(Port Profiles)(Defined Entities)(VM metadata)Kubernetes Cluster ObjectsKubern

6、etes ObjectsUser-created SecretsCluster SecretsUser RBACUser AccountsUser KUBECONFIGsADMIN KUBECONFIGButADMIN KubeConfig is a Break-glass KubeconfigRoot-access to node is revoked,but a copy could existIf earlier Cluster-Admin still has network access,the cluster is still accessibleNetwork Access can