Securing DevOps with Centrify Delegated Machine Credentials

At its core, DevOps focuses on delivering faster time to market with more reliability and efficiency through a cycle of rapid, continuous development, integration, delivery and deployment. The credentials are numerous, complicated, and spread throughout various components of the automation pipeline rendering security administration and compliance incredibly challenging.

And so, electing for speed and ease of use, many administrators use multiple ways of storing credentials locally in config files, scripts, application servers and clustered services. These hard-coded credentials continue to be one of the biggest security hazards for organizations adopting DevOps. They usually remain unchanged due to the associated administrative difficulty, and thus become easy victims for guessing exploits, giving bad actors a free ticket to sensitive data.

Application to Application Password Management (AAPM) is the prescribed solution to this problem. The basic model of AAPM consists of a credential store and a mechanism to allow workloads to use API calls and retrieve the necessary credentials.

The general process is as follows:

1. Create a service account and an OAuth2 client app on a per workload basis
2. Delegate the necessary permissions for each service account and scope API access
3. Embed an OAuth2 client and secret to authenticated to the vault and retrieve a scoped token
4. Call the required API using the retrieved token to access the needed privileged resource.

Although this approach solves the root issue of hardcoded credentials, its implementation brings about additional challenges:   

• Service account proliferation: instead of decreasing the amount of privileged accounts, this approach to AAPM increases the number of service accounts by requiring one per workload. This increases the attack surface substantially and, in the case that the account gets compromised, it gives away direct administrative access to the attacker. 
• Increased administrative overhead: with this approach administrators must manually configure OAuth2, numerous service accounts, and their permissions. This increases the administrative to-do list, especially when taken on a per-workload basis.
• Risk of failure: industry best practice recommends frequently rotating these accounts. With an increased number of service accounts though, frequent rotations can lead to unsynchronized credentials and ultimately cause a major disruption to IT operations.

Centrify’s Solution: Delegated Machine Credentials (DMC)

Centrify Delegated Machine Credentials (DMC) effectively solves these three problems by addressing their root cause – the prerequisite for per-workload service accounts.

Instead of asking the administrator to create a service account per workload to act as the gateway to the vault, DMC takes advantage of the machine trust established by the footprint of the Centrify Client on a host machine. It hands this machine trust to other applications/workloads/microservices in the form of an OAuth2 token. The applications, workloads, etc. can then use this new token based trusted identity to communicate with Centrify Privileged Access Service (PAS) and pull the necessary information via scoped API access.

What does this mean in terms of configuration? 

1. Scale down the number of service accounts – no more service account per workload. Upon enrollment, the Centrify Client will create machine service account that will be leveraged to establish a strong root of trust w/ the Centrify password vault (PAS) and can be utilized by multiple workloads.
2. Do it all at enrollment time and cut the administrative overhead associated with traditional AAPM approaches. With DMC, the trusted machine account will be the only account that will be interacting with the vault. Thus, an admin is only required to configure the permission assignments for one account, instead of the numerous service accounts he/she was tasked with handling before. 
3. DMC further expedites time to production by allowing an admin to fully automate and generalize PAM as a part of the DevOps process. An admin can create a new instance with the app he/she needs running on it, and simply include a script that installs, enrolls, and configures DMC for the Centrify Client at initialization. Then the admin is free to use these tools in additional automation to communicate with the vault and retrieve any privileged resources in real-time using the trust provided by the machine credential.
4. By cutting the number of service accounts, DMC allows you to improve your security posture in multiple ways. The machine service account is managed only by the Centrify vault and cannot be tampered with by external users and/or services and thus ensures high integrity and availability. In addition, DMC’s API scopes help prevent lateral movement by limiting  a workload’s vault access to only the resources that it needs to get the job done.

Centrify’s DMC was designed to align itself with the main goals of DevOps – reliability and speed. By capitalizing on machine trust and eliminating the need for extensive service account use, DMC equips security admins with both reliable and efficient AAPM capabilities that allow them to effectively secure ever-changing IT environments.

Learn more in this video on our Youtube channel. 

This post was first first published on Blog | Centrify website by KavyaDindu. You can view it by clicking here