As you start your cloud incubation journey, one of the very first hurdles you would run into is access management. How to secure access to your cloud provider? Whom do you allow to provision resources? Do you want to centralize the provisioning, or empower project teams with self-service capability? Can we leverage on-premise identity stores for cloud access? Needless to say, these aspects can get quite tricky. In this post, I will talk about different options around managing accessibility to cloud services and as always would love to hear your feedback.
No Self Service: Many organizations looking at cloud as an extension to their data center, and want similar to enforce similar control over their cloud environment. Their IT team provisions and de-provisions cloud resources as necessary. But the end users have no direct access from their end. They still raise a ticket through tools like Service Now which are then full filled by IT Ops through automation or manual setup.
Self Service via Custom Portal: This is standard practice across many organizations. Instead of providing direct access via cloud service provider portal, they create a layer of abstraction – a custom portal for managing access. This is definitely feasible as most of the cloud service providers have APIs, controlling access to cloud resources. A typical custom portal can help drive governance. An example use case could be – someone requests a VM image and an request approval email is automatically sent to her manager. Further custom portals can provide a unified view catering to different cloud platforms – i.e. a single UI to provision workload on AWS, Azure or Google Cloud. But challenge with such initiative is to keep pace with new cloud services. Most of the cloud platforms are introducing new features biweekly, making custom portal a never ending project. One solution here could be to control the feature scope of the custom portal – e.g. cater to just IaaS services – Compute, Network, Storage & Security.
Controlled Access to Provider portal with extensions: Many enterprises don’t want to reinvent the wheel. Their intent is to add only delta functionality to the existing self-service cloud provider portal. For instance, most of the cloud provider portal have no context of the consuming enterprise, its projects, its policies, etc. In such cases, it makes sense to augment cloud provider portal with additional project view and build an ecosystem to enforce organizational policies. E.g. When User A logs into the extended Portal she can view the list of projects (a project can have a direct mapping to cloud subscription or account), her role / rights on each. But provisioning any cloud resources would have to be carried out through provider portal (may be a SSO with provider portal). Depending on the rights user has, she will be able to provision only those cloud resources.
Let’s understand the last option from Microsoft Azure perspective, though similar features are available in other cloud platforms like AWS as well.
Single Sign On:
To setup Single sign on you will require Azure Active Directory domain configuration and ADFS setup. You can find more details here. This ensures that only employees of the organization will have access to Azure portal & resources.
Controlling access to resources:
SSO is great, but you don’t want every user of the organization to have unrestricted access to Azure resources. Rather only the authorized set of users should have access to them. That’s where Role based access control comes in. A role in RBAC terms is a collection of actions that can be performed on an Azure resources or group of Azure resources (group of resources referred to as ‘Resource Groups’ in Azure are containers holding resources for a given application). RBAC is currently supported in Azure Preview Portal only. You can also configure the access through PowerShell.
Subscription, Administrators & Azure AD:
While RBAC is the preferred way of setting access control, knowing the different Azure Portals administrative roles is necessary to gain comprehensive understanding. Once you sign up for Azure EA, MS sets up an account for you called ‘Enterprise administrator’. As an enterprise admin you can create different accounts and subscriptions. Each account has an Account administrators who in turn can create multiple subscriptions, with each subscription having its own service administrator. Service Administrator is the super user having complete access to the subscription and can provision resources (VMs, Databases, etc.) as required. Service Administrator can also create co-administrators as required to support them with administrative tasks.
Coming to Azure AD, you can create, rename, delete Azure AD from Azure Portal. Every Azure Subscription can trust only one Azure AD and only service administrator has the rights to choose the trusted AD for a given subscription (Settings -> Subscriptions -> Edit Directory).
Hope that provided some good perspective. As always do drop a note below, on how are you managing access to cloud resources.
Niraj Bhatt - Architect's Blog 