IT:AD:Azure:Security:Role:Why Move To Builtin Roles

(UP)

Summary

The Administration Roles were introduced when Azure first was introduced (ie with the IT:AD:Azure:Portal:Classic Portal).

But its simplicity caused issues.

Any Azure Service Management required full IT:AD:Azure:Security:Role:Administration:Service Administrator (SA) or IT:AD:Azure:Security:Role:Administration:Service Co-Administrator (CA) access to a IT:AD:Azure:Subscription which provided the user with full permission to do anything provisioned there-in.

This meant that a subscription typically became a security container.

For example you could provision a subscription for an application or you could provide a subscription for an environment (such as Dev / Test / Prod). Or you could provision a subscription for an application, in an environment. Either way, one ended up with many co-administrators with full control.

Obviously, not a good scenario.

The above issue is why RBAC and Resource Groups were introduced (along with the new Service Portal).

The use of Account Administrator (AA) and Service Administrator (SA) will continue, but the Co-Administrator (CA) is deprecated in favour of the use of the Contributor or Owner Role.

I suspect that now when you are defined as one of the classic *Administrator roles, you are assigned Roles from the built in roles (eg: Owner, Contributor, etc) ¹⁾ but maybe not. I have not seen a map of this.

* https://blog.kloud.com.au/2015/10/16/azure-security-fundamentals-moving-co-admins-to-rbac/

¹⁾

https://azure.microsoft.com/en-us/documentation/articles/role-based-access-built-in-roles/

IT:AD:Azure:Security:Role:Why Move To Builtin Roles

Summary

Resources

Notes