Why Classic Authentication Still Matters in a Cloud-Native World

Classic Authentication In the modern world, while there are countless methods, mechanisms, and means for granting access to resources, password authentication remains the most widespread and, essentially, the classic approach. The exact date this type of digital access originated is difficult to pinpoint. Some attribute it to the American scientist Fernando J. Corbato, a staff member at the MIT Computation Center, who designed and implemented the first digital passwords in 1961 to authenticate users on a multi-user computer running the Compatible Time-Sharing System (CTSS). Others link the era of rapid development in digital passwords to the early 1970s with the advent of the Unix OS and the widespread adoption of its foundational principles. Fernando J. Corbato Nevertheless, it's certain that passwords or their equivalents have been in use for centuries. For instance, "watchwords" were employed by the ancient Romans to gain entry to secured areas or to identify allies. watchwords Another historical predecessor is the use of ciphers, which first appeared in Ancient Greece around 400 BCE for encoding and decoding messages between military commanders. Ciphers perform the same fundamental function as watchwords and passwords: ensuring security and restricting access. ciphers Modern technology is advancing rapidly, and humanity has quickly reached the point where relying on a single password is no longer sufficient to ensure robust protection. At the same time, we still cannot entirely abandon the concept of the password, nor the underlying principles of access restriction. This necessity has driven the creation of various principles for password management and usage, along with sophisticated access control systems (ACS) and rules. The concept of information relevance time emerged, which is directly linked to the difficulty of gaining access—and, indirectly, to the time required to crack (or brute-force) a password. The realization of the inherent vulnerability in traditional password protection has led to the development of many complementary solutions. In addition to the password, tokens have become prevalent. A token is typically a short-lived digital key or code issued by a system after a user successfully authenticates. This token is then used to access specific resources or services on the user's behalf without requiring the continuous re-entry of a login and password. tokens Tokens have significantly simplified and strengthened access control, thanks to their limited lifespan and the cryptographic complexity of their generation. Even if a token is compromised or stolen, the attacker's window of access to resources is strictly limited, thereby greatly reducing the potential damage. The Limitation of Classic Authentication and the Shift to Modern Security Despite the fundamental nature of classic password authentication, it suffers from several significant drawbacks that modern technologies and security approaches are actively working to mitigate or eliminate. For example: Weak and Predictable Passwords: Users frequently choose easily guessed passwords (e.g., "123456", "password", or personal details like a name or birth date) for simplicity. Such passwords are quickly compromised through dictionary or brute-force attacks. Modern systems now enforce strict password complexity policies, controlling length and character variety (letters, numbers, special symbols), and preventing the reuse of old passwords by cross-referencing them against databases of known compromised credentials. Secure Storage and Distribution: Once created, credentials must be securely stored, and their transmission and verification process must be safe. Most modern systems do not store the actual user passwords. Instead, they store their cryptographic hashes (often using a unique, random string called a "salt"). This salting makes it impossible to reverse-engineer the original password, even if the system's database is compromised. For storing secret data like application passwords or API keys, specialized tools known as Secret Management Systems are often used. Brute-Force Risk and Rotation: Theoretically, any password can be guessed in a finite time N, which depends on its complexity and the attacker's computational power. As a preventative security measure, passwords were traditionally required to be changed regularly. Therefore, older security policies often included requirements for password lifespan. However, recent expert consensus recommends against mandatory periodic rotation of complex passwords unless a compromise is suspected. Password rotation (automated changing) is now primarily used for service or technical accounts. Weak and Predictable Passwords: Users frequently choose easily guessed passwords (e.g., "123456", "password", or personal details like a name or birth date) for simplicity. Such passwords are quickly compromised through dictionary or brute-force attacks. Modern systems now enforce strict password complexity policies, controlling length and character variety (letters, numbers, special symbols), and preventing the reuse of old passwords by cross-referencing them against databases of known compromised credentials. Weak and Predictable Passwords: Secure Storage and Distribution: Once created, credentials must be securely stored, and their transmission and verification process must be safe. Most modern systems do not store the actual user passwords. Instead, they store their cryptographic hashes (often using a unique, random string called a "salt"). This salting makes it impossible to reverse-engineer the original password, even if the system's database is compromised. For storing secret data like application passwords or API keys, specialized tools known as Secret Management Systems are often used. Secure Storage and Distribution: Brute-Force Risk and Rotation: Theoretically, any password can be guessed in a finite time N, which depends on its complexity and the attacker's computational power. As a preventative security measure, passwords were traditionally required to be changed regularly. Therefore, older security policies often included requirements for password lifespan. However, recent expert consensus recommends against mandatory periodic rotation of complex passwords unless a compromise is suspected. Password rotation (automated changing) is now primarily used for service or technical accounts. Brute-Force Risk and Rotation: Speaking about User-to-System access, the first concept that comes to mind for maximizing data protection is Multi-Factor Authentication (MFA). Multi-Factor Authentication (MFA). MFA is an access control method that requires a user to successfully provide two or more independent pieces of evidence (factors) of their identity to gain access to a system, application, or service. For example, a user might provide a login, a password, and a one-time code sent via an alternative communication channel (like a text message). MFA significantly reduces the risk of unauthorized access because an attacker who steals the password (Factor 1) would still need to gain control of the second independent factor (e.g., the user's phone or a hardware key). However, MFA is neither the most convenient nor even a feasible solution when dealing with System-to-System (S2S) access—for instance, when a cloud application needs to securely access a database or storage service. In these scenarios, the preferred solution is often Managed Identity (MI). Managed Identity (MI) What is Managed Identity? Managed Identity is a fundamental security mechanism across major cloud platforms (such as Azure, AWS, and Google Cloud). It enables cloud resources, such as Virtual Machines (VMs), containers, serverless functions, databases, or web applications, to automatically and securely obtain credentials (tokens) to authenticate with other cloud services. Crucially, it eliminates the need to manually manage secrets, keys, or passwords within application code or configuration files, drastically improving security posture. This technology explicitly allows a resource to "authenticate itself" without ever needing to see or store a secret, greatly simplifying operations and reducing the attack surface. The process for a cloud resource to authenticate using an MI is standardized and consists of the following key steps: Identity Assignment: A unique identity (referred to as a Service Principal in Azure, an IAM Role in AWS, or a Service Account in GCP) is created and assigned to the cloud resource that needs access. This identity is then granted access policies (permissions) that define which target resources it is allowed to interact with (e.g., a data store, an API etc). Token Request: When the cloud resource (e.g., code running on a VM) needs to authenticate with a target service, it requests a local cloud API (such as Azure Instance Metadata Service (IMDS), AWS EC2 Metadata Service, or GCP Metadata Server). Token Issuance: The cloud platform automatically recognizes the source of the request, confirming that the request originates from the assigned identity. The cloud verifies that the resource is who it claims to be and returns a digitally signed JSON Web Token (JWT). Target Resource Access: The requesting resource uses the acquired JWT as a temporary, valid credential (bearer token) to authenticate and authorize its access to the required target cloud service, adhering strictly to the pre-assigned permissions. Identity Assignment: A unique identity (referred to as a Service Principal in Azure, an IAM Role in AWS, or a Service Account in GCP) is created and assigned to the cloud resource that needs access. This identity is then granted access policies (permissions) that define which target resources it is allowed to interact with (e.g., a data store, an API etc). Identity Assignment Token Request: When the cloud resource (e.g., code running on a VM) needs to authenticate with a target service, it requests a local cloud API (such as Azure Instance Metadata Service (IMDS), AWS EC2 Metadata Service, or GCP Metadata Server). Token Request Token Issuance: The cloud platform automatically recognizes the source of the request, confirming that the request originates from the assigned identity. The cloud verifies that the resource is who it claims to be and returns a digitally signed JSON Web Token (JWT). Token Issuance: Target Resource Access: The requesting resource uses the acquired JWT as a temporary, valid credential (bearer token) to authenticate and authorize its access to the required target cloud service, adhering strictly to the pre-assigned permissions. Target Resource Access: Key advantages: Key advantages: Elimination of Secrets: Developers no longer need to manually store (in code, configuration files, or secret stores) plaintext usernames, passwords, access keys, or certificates. This dramatically reduces the risk of credential exposure. Automatic Credential Rotation: The cloud platform automatically handles the lifecycle and rotation of the underlying credentials used for authentication. This removes a major operational burden and enhances security without manual intervention. Principle of Least Privilege (PoLP): A MI can be configured with the minimum necessary set of permissions required for its task. This adherence to PoLP significantly restricts the damage an attacker could cause if the identity were compromised. Elimination of Secrets: Developers no longer need to manually store (in code, configuration files, or secret stores) plaintext usernames, passwords, access keys, or certificates. This dramatically reduces the risk of credential exposure. Elimination of Secrets: Automatic Credential Rotation: The cloud platform automatically handles the lifecycle and rotation of the underlying credentials used for authentication. This removes a major operational burden and enhances security without manual intervention. Automatic Credential Rotation: Principle of Least Privilege (PoLP): A MI can be configured with the minimum necessary set of permissions required for its task. This adherence to PoLP significantly restricts the damage an attacker could cause if the identity were compromised. Principle of Least Privilege (PoLP): Main disadvantages: Main disadvantages: Cloud Environment Lock-in: MI is designed to work exclusively for cloud resources hosted within the same cloud ecosystem. An application running on a local developer machine or in a third-party data center cannot use MI for authentication. Service Integration Limitations: Not all cloud services offer full support for MI. For example, while Microsoft states support for Azure Cosmos DB, this support can be limited - MI might only be usable to access Cosmos DB secrets (like connection strings) and not directly for data access, requiring an extra step. Audit Complexity: In some cloud environments, such as Azure/Entra ID, the sign-in logs for MI may be less detailed or comprehensive compared to logs for regular users or standard Service Principals, potentially complicating security auditing and forensic analysis. Cloud Environment Lock-in: MI is designed to work exclusively for cloud resources hosted within the same cloud ecosystem. An application running on a local developer machine or in a third-party data center cannot use MI for authentication. Cloud Environment Lock-in: Service Integration Limitations: Not all cloud services offer full support for MI. For example, while Microsoft states support for Azure Cosmos DB, this support can be limited - MI might only be usable to access Cosmos DB secrets (like connection strings) and not directly for data access, requiring an extra step. Service Integration Limitations: Audit Complexity: In some cloud environments, such as Azure/Entra ID, the sign-in logs for MI may be less detailed or comprehensive compared to logs for regular users or standard Service Principals, potentially complicating security auditing and forensic analysis. Audit Complexity: Managed Identity is a powerful solution for securing cloud-native, System-to-System communication, but its utility is defined by its strong ties to the cloud provider's infrastructure. Cloud Managed Identity in Kubernetes Cluster In my opinion, one of the main benefits MI gives is its use in a Kubernetes cluster. The simplicity of implementation lies in associating a Kubernetes Service Account with a MI and then utilizing it in your workload. This significantly enhances granularity and flexibility, especially in a microservices architecture - you can precisely define the boundaries of authorization for each microservice. For example, one microservice might need access to an Object Storage, while another interacts with a PostgreSQL database, and they communicate via a cloud-managed message broker. The major benefit is that you can achieve all this without needing to store secrets; you use the Service Account token that's automatically mounted into the Pod. Setting up this binding is a straightforward process. I would like to use Microsoft Azure as an example. To begin, you first need to ensure your cluster is configured to support Azure AD Workload Identity. If this feature is not currently enabled, it can typically be activated with ease. az aks update \ --resource-group \ --name \ --enable-oidc-issuer \ --enable-workload-identity az aks update \ --resource-group \ --name \ --enable-oidc-issuer \ --enable-workload-identity Let’s assume we have some object storage and we want to allow our code to read data from it. First, we need to get the ID of this storage. STORAGE_ID=$(az storage account show \ --name \ --resource-group \ --query id -o tsv) STORAGE_ID=$(az storage account show \ --name \ --resource-group \ --query id -o tsv) Now, need to create an identity for our workload. az identity create \ --resource-group \ --name az identity create \ --resource-group \ --name The next step is the role assignment for the created identity az role assignment create \ --role "Storage Blob Data Reader" \ --assignee $MI_CLIENT_ID \ --scope $STORAGE_ID az role assignment create \ --role "Storage Blob Data Reader" \ --assignee $MI_CLIENT_ID \ --scope $STORAGE_ID Where the MI_CLIENT_ID was taken from the created identity MI_CLIENT_ID export MI_CLIENT_ID=$(az identity show \ --resource-group \ --name \ --query "clientId" -o tsv) export MI_CLIENT_ID=$(az identity show \ --resource-group \ --name \ --query "clientId" -o tsv) We have nearly everything needed in the cloud, but we need to build a bridge between the Cloud and Kubernetes. As I mentioned earlier, the only thing needed to use Managed Identity in Kubernetes is the Kubernetes Service Account. We can create it in the end. Let’s create a Federated Identity Credential to wire the created managed identity with the Kubernetes service account az identity federated-credential create \ --name "k8s-federation-for-storage" \ --identity-name \ --resource-group \ --issuer $AKS_OIDC_ISSUER \ --subject system:serviceaccount: : \ --audience api://AzureADTokenExchange az identity federated-credential create \ --name "k8s-federation-for-storage" \ --identity-name \ --resource-group \ --issuer $AKS_OIDC_ISSUER \ --subject system:serviceaccount: : \ --audience api://AzureADTokenExchange where the AKS_OIDC_ISSUER was taken asL AKS_OIDC_ISSUER export AKS_OIDC_ISSUER=$(az aks show \ --resource-group \ --name \ --query "oidcIssuerProfile.issuerUrl" -o tsv) export AKS_OIDC_ISSUER=$(az aks show \ --resource-group \ --name \ --query "oidcIssuerProfile.issuerUrl" -o tsv) Now that we have everything we need, it's time to create a Kubernetes service account and associate it with a workload. apiVersion: v1 kind: ServiceAccount metadata: name: storage-accessor-sa namespace: default annotations: azure.workload.identity/client-id: " " apiVersion: v1 kind: ServiceAccount metadata: name: storage-accessor-sa namespace: default annotations: azure.workload.identity/client-id: " " apiVersion: v1 kind: Pod metadata: name: my-storage-app labels: # This label is required to trigger the Workload ID sidecar/webhook azure.workload.identity/use: "true" spec: # This links the Pod to the Service Account serviceAccountName: storage-accessor-sa containers: - name: my-app-container image: apiVersion: v1 kind: Pod metadata: name: my-storage-app labels: # This label is required to trigger the Workload ID sidecar/webhook azure.workload.identity/use: "true" spec: # This links the Pod to the Service Account serviceAccountName: storage-accessor-sa containers: - name: my-app-container image: To interact with Managed Identity within the code, there are numerous libraries available for various languages, including those officially supported by Microsoft. This approach, when it is fully integrated into your CI/CD pipelines and Terraform configurations, creates a robust and powerful tool for deploying and managing your infrastructure. Conclustion Managed Identity is a modern and powerful cloud tool suitable for most tasks, significantly simplifying communication between cloud services. Managed Identity However, it does have its limitations, such as being cloud-vendor specific and the fact that not all older or specialized resources fully support this technology. I would recommend adopting this as the default for your architectures. It is important to realize, though, that migrating large, complex systems that were not built with this technology can be a highly labor-intensive endeavor. This is precisely why, even today, large IT companies may still rely on classic secret management approaches.