Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Despite its reputation as slow and complex, PAM can be included in the DevOps pipeline effectively
The introduction of DevOps practices has led to a revolution in software development. However, as companies adopt these new technologies, tools and methodologies, incorporating privileged access management (PAM) becomes increasingly complex. Nonetheless, corporate policies, industry standards and government regulations mandate that security and operations teams must manage and audit permissions and credentials for a growing number of user and service accounts. As a best practice, a least privilege access control model is a must.
Compounding the issue is that traditional methods of securing developer environments involve manual interventions and restrictive controls that significantly hamper the agility of development and operations teams. Because of that, DevOps has eschewed PAM as too slow and complex to deploy and manage.
Adding to the complexity, applications, virtual machines, services and workloads running in the cloud all have identities. In fact, non-human identities nowadays represent most “users” in many organizations. This proliferation of non-human identities exacerbates the difficulty of achieving least privilege.
Like human identities, access for these identities must be strictly monitored and controlled so that unauthorized, unverified access is automatically denied. PAM solutions that support modern application-to-application password management (AAPM) approaches can achieve this. DevOps owners can take control of privileged access without impacting agility, leaving them to focus on what they do best while finally putting the “Sec” into DevSecOps.
AAPM eliminates the need to store credentials in clear text in the application. Instead, developers introduce API calls in their code to access a vault programmatically and to check out the password. The password is stored in application memory and not written to disk. Once the application terminates, the memory is deallocated and the password is gone, leaving nothing for a threat actor to find. Using this approach, the vault secures the credentials and controls access to them. The vault can also automatically rotate passwords, making them more challenging to crack. Since dependent applications now make API calls to fetch them, DevOps teams are no longer concerned with updating their code whenever the passwords change.
PAM and DevOps: AAPM in Action
This is a fundamental approach to AAPM. Other options exist, however, distinguished by increasing levels of cyber-risk mitigation and operational efficiencies:
Level 1: AAPM to Retrieve a Vaulted ID and Password
As described, this is the traditional approach to PAM. While vaulting the passwords provides an extra layer of security by removing them from code, passwords remain the weakest form of authentication. Even with automatic password rotation, they persist until the next scheduled rotation (often days or weeks), giving an attacker ample time to attempt to crack. To check them out of the vault, each workload needs a service account. This can quickly amount to hundreds, if not thousands, of additional accounts, increasing administrative overhead and increasing the attack surface.
Level 2: AAPM to Retrieve a Vaulted ID and SSH Key
Human administrators and workloads present an added risk to organizations through the widespread use of shared privileged accounts for authentication. Secure Shell (SSH) keys are frequently implemented as a safer alternative, allowing the workload to check out a vaulted SSH key instead of checking out a vaulted password.
The use of SSH keys includes similar risks and benefits to vaulted passwords. They’re also static, relying on a scheduled rotation. They, too, can be shared among developers and between workloads. Developers and IT admins are often given enough rights to create SSH keys at will without any oversight or central management. This makes them difficult to track and know how they’re being used, by whom and for what. If they’re lost or if a developer leaves, system and service availability can be impacted.
On the positive side, however, the SSH protocol employs public-key cryptography. The SSH keys (public and private) are longer and more complex than any password. Unlike passwords, they’re not sent over the wire. All this makes them more difficult to compromise and, thus, more secure.
That said, each workload still needs a service account to authenticate to the vault and check out an SSH key, each of which is a potential vector of attack.
Level 3: AAPM to Retrieve Ephemeral Tokens
Ephemeral tokens (e.g., OAuth2) can be created automatically by the vault on-demand and offer a modern form of secure access that is temporary, time-based and expires automatically. This releases DevOps from dealing with installation, configuration and rotation issues while contributing to a best-practice “just-in-time” access control approach. As with the earlier methods, however, each workload still needs a service account to authenticate to the vault to obtain a token.
Although such tokens can persist, they’re generally short-lived for the duration of a session or transaction, greatly reducing the window of opportunity for a threat actor.
Level 4: AAPM Using Delegated Machine Credentials and an Ephemeral Token
The prior methods are all characterized by a per-workload service account requirement. With a Delegated Machine Credential approach, a service account is only required per-machine.
When the machine is enrolled in the PAM service, it establishes a mutual trust relationship. The PAM service creates a unique Delegated Machine Credential, machine identity and service account for that machine. Local workloads can then piggy-back off that machine identity, leveraging the delegated machine credential to authenticate to the vault, exchanging it for an OAUth2 bearer token it can use for subsequent API calls (e.g., to check out a password or obtain a token.) Since not all workloads are equal, OAuth scoping can limit which APIs each workload is allowed to access. Thus, by using a Delegated Machine Credential, the number of service accounts is reduced to practically zero, closing thousands of potential vulnerabilities.
This approach also addresses the lack of desire to introduce PAM into DevOps, as I highlighted right at the start. This method can be fully automated and inserted naturally into the CI/CD pipeline.
All these approaches give organizations more choice, based on their existing PAM maturity, risk tolerance, and compliance pressures. They ultimately allow DevOps teams to automate, simplify and centralize PAM security management while improving the organization’s security posture, without sacrificing agility.
