I am unsure if serverfault is the appropriate exchange for this question, please indicate if it is not so
Create a minimum permissions set up to implement the highest possible level of security with the RBAC and AD before dealing with any other security issues.
- To create a kubernetes cluster, a service principal must exist or be created.
- The service principal used for the kubernetes cluster requires no permissions on the AD, nor any roles on the RBAC.
- I have a subscription where users have no permissions on AD and on the RBAC are only contributors/owners on one and only one resource group.
- To create a kubernetes cluster a user requires at the minimum read access to the service principals.
- AD is standard so no custom roles, i.e. have to use basic roles.
After some digging with the initial parameters, I have for the moment decided that the AD role of Directory Reader is the least priviledge possible on the AD to create a kubernetes cluster. This gives the user read access but nothing else.
I have a user A to which I have granted this role on the AD, on the RBAC the only permissions they have is inside their own resource group, they cannot even see what other resource groups exist.
I have a service principle SPforA that has zero roles on either the RBAC or the AD.
User A is the owner of resource group RGforA and cannot see all the other resource groups that exist (RGforB, RGforC, etc…) and cannot create resource groups.
Service principal SPforA is in the same situation as A.
Now I create a kubernetes cluster in RGforA with the usser A and assign SPforA as the service principal for the cluster.
As is stated in the documentation, when a kubernetes cluster is created, a second resource group is created containing all the infrastructure of the cluster.
Neither A nor SPforA can create the resource group or the machines and load balancers, security service, log analytics, etc… that are created. Yet the resource group and infrastructure is created.
The logs indicate that the creator of the resource group and all the services was the AzureContainerService service principal.
How is it that a user with no priviledges can manage to make the resources to be created even through a delegation? Is this some weird low-key priviledge escalation?
I might be missing some little detail so before raising a ticket would like to know if this is supposed to be actual behaviour.