Static IDs and passwords have been around for decades, and for all the talk about getting rid of them, big pockets remain. Sure, for human login to systems and applications, we’re making some headway with multi-factor authentication (MFA) usage growing in adoption. However, enrolling second factors for use in MFA itself requires user authentication—with an ID and password!
Governments and related high-security agencies are perhaps the only entities to up that game with in-person enrollment.
The reality is that MFA is for humans. It doesn’t work for headless activities—non-human interactions where applications and services access other applications and services.
IT Operations Management (ITOM) is a good example. Perhaps you consume ITOM services (for example, ServiceNow® Discovery) to provide the tools you need to manage your IT infrastructure. Many of these ITOM tools need privileged IDs and passwords to log into IT systems to do their jobs, such as asset discovery, orchestration, and vulnerability scanning apps.
Another example is DevOps, where applications and services need credentials to authenticate to other apps and services.
Cyber adversaries are aware of this and are increasing their efforts to target such systems. Just like DevOps, they too strive for speed, agility, and automation. They deploy autonomous bots to seek out and harvest privileged credentials, enabling the bots to masquerade as legitimate “users” to progress their attacks.
A Better Way
This blog focuses on the DevOps challenges inherent with the continual use of IDs, passwords, and service accounts for application and machine identity, authentication, and authorization, and an effective alternative. The main objective is to remove authentication and authorization friction for DevOps, which remains a considerable inhibitor for accepting IAM into their workday.
It seems obvious, but a best practice to minimize your exposure is to take static IDs and passwords out of the equation. Ideally, delete them, or if you can’t, store them in a password vault and strictly govern and control access.
This alone is a massive win by reducing your attack surface. Application code can call an API to retrieve passwords. Any bots trawling through files for credentials are simply out of luck. However, you still have to manage those passwords, rotate them, discourage them, and avoid sharing, and at the end of the day, they’re persistent and still weak.
If you’re tired of the security team pointing fingers at DevOps for exposing the organization to risk by relying on IDs and passwords, ephemeral tokens are a worthy consideration. Tokens, such as OAuth, have way more benefits:
- They don’t hang around. They’re temporary, stored in the browser, in memory, or a protected cache. Unlike passwords or browser cookies, though, they’re automatically destroyed when a session completes or exceeds the expiration time. This shrinks the window of opportunity for cyber adversaries, reducing your risk.
- They’re machine-generated and encrypted, and so, are more secure than the simple, weak passwords set by humans. Unlike privileged accounts that administrators and developers often share and whose passwords are often identical across systems, tokens are unique.
- You can enforce checks to ensure OAuth tokens are only issued to applications that (for example) are digitally signed, have a specific application identity, and are in a particular filesystem path.
- The tokens can be digitally signed to ensure message integrity, enabling the receiver to detect tampering.
- You can also use the OAuth application identity to scope which APIs the application can access. Contrast this with another common approach: API keys, which persist and are accessible to clients. Like passwords embedded in code, they’re easy to steal and since they have no expiration, a threat actor can use them indefinitely unless or until they’re explicitly revoked. They’re also often shared and reused. Thus, if compromised in one application, this impacts any other application using the same API key.
So What’s the Catch?
Replacing passwords and even API keys with OAuth sounds perfectly nice, but there’s a reason why OAuth hasn’t seen stronger adoption. OAuth can be tricky for DevOps to implement, requiring yet another service account ID and secret for each application. And how does the application protect that secret?
With its OAuth provider and Delegated Machine Credentials (DMC) technologies, Delinea has cracked that nut. Let’s look at three main ways Delinea’s Privileged Access Service vault plus DMC helps.
Taking Those IDs and Passwords Off the Playing Field
Let’s first address those privileged credentials you can’t delete. You can protect and manage them inside the Delinea Privileged Access Service vault. In a perfect world, nobody should ever touch them. For emergencies, though, strictly control who can check them out and audit that activity. Further, enforce just-in-time access via workflow-based request and approval; time-box that access to prevent reuse; and, after use, rotate the passwords automatically, making them complicated and difficult to crack.
Enrolling Developer Apps and Services in the Vault
Vaults, in general, are not revolving doors allowing anyone or anything to access secrets, credentials, or tokens. Just like a user, your apps must also authenticate to the vault.
Traditionally, this has been a substantial manual undertaking. For each application, register an API account and password with the vault, configure roles and policies to constrain what they can access, create OAuth client code, and embed that client and a Secret in each application. Multiply that by the number of apps and services. With a new service account per application, your attack surface just exploded.
Then there’s the issue of how to store and protect that service account and password. In code? In a config file?
Alternatively, the Delinea Client establishes a trust relationship between the machine and the Delinea Platform, creates an OAuth Client in the vault, obtains a service account and an OAuth Secret (a DMC), and configures the OAuth Client with API scopes for the applications that run on the system. It does this automatically via a single enrollment command.
Consuming Vault Services
Your application can now ask the Delinea Client to log into the vault on its behalf (using DMC) and obtain a scoped bearer token granting access to specific vault API endpoints. The application can then make an HTTP request to the vault, with the bearer token in the Authorization header. Alternatively, it can issue commands to the Delinea CLI to do the same. The machine’s credential is never exposed to your application.
Either way, the developer doesn’t need to know how OAuth works – Delinea handles that complexity. No hard-coded secrets, passwords, or API keys in code or config files. Having a single service account per machine instead of per application dramatically reduces your attack surface.
To play nicely within your CI/CD pipeline, all of this can be automated – installing the Delinea Client, enrolling the machine, installing the Delinea CLI, configuring application OAuth scopes, creating the OAuth Client, etc.
DMC, coupled with ephemeral tokens, is a game-changer that avoids finger-pointing and risk exposure.
For more information, please check out the following blog articles:
ServiceNow® is a registered trademark of ServiceNow, Inc., in the United States and/or other countries. All other trademarks are property of their respective owners.
Manage DevOps secrets safely
With DevOps Secrets Vault you can securely provide secrets at the speed and agility DevOps needs to stay competitive.
