Mazes are a challenge – at least without a bird’s eye view. Authentication for technical accounts presents a similar challenge for cloud engineers.
Technical accounts are the backbone of CI/CD pipelines, infrastructure-as-code, and any form of process automation for IT or business processes. They enable engineers to deploy and configure complete cloud tenants or applications. This fact implies that hackers can misuse them to destroy complete cloud tenants and enterprise application landscapes. Technical accounts for backups have access to all non-sensitive and sensitive data, a goldmine for hackers if they can take over any of them. In short, technical accounts have the impact of nuclear bombs when misused.
In this article, I present the most relevant security and authentication patterns – as well as concrete samples of access control features to use in Azure and AWS – to help cloud engineers and architects navigate the maze.
Figure 1 — The big picture of technical accounts in the cloud
Firewalls are a typical, very rough first filter and protection layer (Figure 1). They block obviously illegitimate network traffic, e.g., traffic from Antarctica to a company-internal ERP system in Italy. The second, more fine-granular filter or layer is authentication. Authentication ensures – by validating user identities – that only the right persons (or systems) have access. It is the main topic we’ll discuss here.
Authentication with Cloud-Platform Identities
Authentication in the cloud is super easy – if everything runs within one cloud ecosystem. Most enterprises do not meet this condition. They have mixed workloads: one lead cloud, smaller outlets with other cloud providers, on-prem servers, plus external web services. Thus, engineers must navigate a variety of access control patterns (Figure 2).
Figure 2 — Overview of authentication patterns in the cloud
The most secure approach for authentication in the cloud is passwordless and based on cloud-managed identities (Figure 1, #1), or, in Microsoft Azure terminology, managed identities. The pattern eliminates the need for authentication and, thus, the risk of breached and stolen secrets. Engineers just grant cloud workloads access rights in the cloud IAM. An Azure Function accessing a Cosmos DB is a typical scenario for this pattern.
The pattern also works for applications running on a cloud VM and for accessing resources in the same cloud, but only with a slight adaption (Figure 1, #2). The cloud IAM does not know the applications on the VM, so it is impossible to assign roles to the applications. But there is a trick: the cloud platform knows the VM, and we can grant access rights to the VM. Then, applications running on the particular VM can inherit or use the VM’s access rights (Figure 1, #3).
In Azure, this works as follows: First, the VM needs an identity to make it known to the cloud IAM (Figure 3, #1). Next, we assign the necessary roles to this VM, e.g., a reader role for a specific Storage Account (Figure 3, #2). Now, applications running on this VM can request roles granted to the VM without authenticating themselves—a simple solution, at least for self-developed or standard software implementing this approach.
Figure 3 — A VM with a managed identity (left) and a Storage Account (right) with “reader” access to this VM.
This authentication approach has one important side effect: Every component running on the VM can access cloud resources with the VM’s credentials. So, knowing what applications and components do is essential, and so is securing them against hackers. Alternatively, applications running on a cloud VM can implement the next access management strategy.
Authentication via Platform Representatives
It changes everything when an application does not run within a cloud but needs access to specific cloud resources (Figure 1, #4). The most elaborate access management and authentication pattern for this scenario builds on application representatives in the cloud IAM. Microsoft calls them service principals. The external application authenticates itself using a secret certificate. Afterward, it can access all resources to which the service principal has access (Figure 4).
Figure 4 — Application registration for creating service principals; in this case, MobileAppClassic and MobileAppNeo
The significant advantage of application representatives is transparency: the cloud IAM knows them and can provide a report with all their cloud access rights. Plus, role-based access management works.
Figure 5 presents a similar AWS construct. While Azure distinguishes strictly between service principals as workload identities and regular user accounts, AWS knows user accounts – and user accounts can have additional access keys for programmatic access by applications.
Figure 5 — Access keys for programmatic access to an AWS user account
The weak link in this AWS construct is the authentication via an internet-exposed API with just one factor: the access key. Azure works similarly – if an engineer exposes such a key by mistake (or copies it when laid off), unwanted access is child’s play. It violates all security and risk best practices to put technical accounts so much at risk. IP restrictions are a solution, i.e., limiting the IP range from which authentication requests are acceptable. The internal IP range is an obvious starting point. Azure’s conditional access feature is one way to implement such requirements.
A final variant is relevant for more complex enterprise IAM setups. There is the option to authenticate an application representative via an external identity provider, which the cloud IAM trusts (Figure 1, #5). Azure AD Workload Identity Federation falls into this category.
Service-Managed Local Access Provisioning
The final approach to authentication in the cloud brings one essential change: access to cloud resources bypassing users and roles in the cloud IAM. Figure 6 presents two examples of how Azure implements this pattern, both related to Storage Accounts. The first is an access key. Every application knowing the key (and the Storage Account) can connect and access the data. It is a simplistic access model without roles (Figure 6, #1).
Figure 6 — Granting local access to Azure PaaS services without direct Azure Active Directory involvement.
The second example is a more sophisticated feature for Storage Account access: Shared Access Signatures. They do not provide “real” roles but rather protection concepts for restricting access, e.g., the validity period for the signature or IP ranges from which log-ins are permitted (Figure 6, #2).
The local access pattern, e.g., with access keys, is widespread. It is super convenient for developers: Generate an access key, add it to your code, and everything works. Why deal with the authentication maze and risk getting lost if you have an axe and explosives to clear their way? However, this local access pattern is a security nightmare. Who has which access key? Who manipulated the data? Simple questions are nearly impossible to answer if just a few services and applications follow this pattern. To be realistic: security hates this pattern, but there is one justification for its usage. There are scenarios for which all other patterns fail.
To conclude, CISO organizations, cloud platform managers, and architects must clarify which cloud access control strategies to push for which scenario and which to eradicate from their enterprise architecture landscape.
Managed identities within an ecosystem are secure; application representatives for accessing cloud resources are also secure if authentication is looked at thoroughly. In contrast, service-specific access management inherently comes with a higher risk. So, when choosing authentication patterns for technical accounts in the cloud, selecting the quickest-to-implement options equals making the life of hackers easier. If you are responsible for security or architecture, you should not listen too much to the mourning of engineers troubled by having to go yet another short extra mile. Technical accounts are too mission-critical for a laissez-faire approach to access management.
