Machine Identity, And Why It’s A Thing
March 30, 2017 | DevOps | Jody Hunt
What is Machine Identity?
Maybe the first time you saw the term machine identity you thought of a science fiction concept like singularity, SkyNet, or “I, Robot”. The term “service account” is probably a more familiar concept. Machine identity is the application of familiar privileged access management (PAM) concepts including identity, authentication, RBAC, least-privilege, auditing, etc. to non-human network entities (processes, services, containers and hosts).
Why is it important?
The goal of DevOps is to reliably increase the rate of change of applications and infrastructure. “Securely” is often added to that objective (hence DevSecOps). It is impossible to manage large quantities of virtual infrastructure (a cloud) without automation. Increasingly, IT automation is becoming less directed by human administrators, more autonomous. Privileged autonomous processes build and deploy applications, provision and configure infrastructure, and decide how to remediate problems. That is a lot of responsibility to entrust to non-human actors that are otherwise accountable to no one, that are making full-stack changes in production networks. Once auditors pick up on this fact, they will demand to see how these software robots are under control, as they demanded to see controls and proof of controls for human sysadmins. We need to securely manage processes running in a network by authenticating them and controlling their privileges.
What is the current practice?
Secrets management was a concept unfamiliar to many just a couple of years ago. Now most organizations at least attempt to control access to passwords and keys. The first step is removing those values from scripts and applications, storing them in secure vaults or key stores, and dynamically fetching them as needed. That is the onramp to machine identity. Access to secrets needs to be controlled, and many times it is a process that needs access. Currently many processes run as a conventional user identity – service accounts. Access to secrets is authenticated with conventional means like LDAP. But it soon becomes evident that for privileged software robots, more control is needed. In traditional / human-oriented scenarios, organizations deployed Privileged Access Management (PAM) solutions to address this challenge. However, human-oriented PAM solutions do not support the correct semantics and cannot scale to meet the dynamic nature of cloud requirements.
Is anybody doing this already?
As we might expect, Google is ahead of the curve with a full service identity management architecture to manage their cloud platform.
“Each service that runs on the infrastructure has an associated service account identity. A service is provided cryptographic credentials that it can use to prove its identity when making or receiving remote procedure calls (RPCs) to other services. These identities are used by clients to ensure that they are talking to the correct intended server, and by servers to limit access to methods and data to particular clients.”
Historically, classic PAM semantics granted or denied human access to non-human resources in relatively static IT environments. Now, in the cloud, non-human resources need controlled access to other non-human resources, with massive degrees of concurrency and scale. It’s no wonder that what worked before doesn’t work any more and new solutions must be developed.
PAM is dead, long live PAM
Let us not be too hasty to toss out concepts that have served us well. We can bring forward legacy PAM concepts and modernize them to work for us in the new DevSecOps cloud environments. This implies tackling use cases such as authenticating our Jenkins server, authorizing it to retrieve database passwords ONLY for development database servers and deploying ONLY to development repositories. All we really need is a way to let the process uniquely identify itself, and once its identity is established, grant access to the appropriate resources and deny access to all others. In the same vein, we can authorize our cloud automation engine to create uniquely identifiable hosts and processes, that are in turn authenticated and granted access to only the resources they need. This is possible today, but we need a new way implement the old concepts.
Here are just a few of the key capabilities that are crucial for a machine identity service that can secure your Cloud and DevOps infrastructure:
- Application of identities to all sorts of non-human constructs including servers, VMs, containers, and CI jobs
- Multi-factor machine authentication using attributes such as container ID, host API key, environment API, namespace API key, IP address / CIDR, and other attributes and, potentially custom, metadata
- Assigning roles and performing roles-based access control (RBAC) for machine operations
- Immutable audit logging, and human-consumable compliance reporting on machine activity
- Encryption always, for data at rest and in motion.