Centrify Delegated Machine Credentials – Modern IAM for Machines and Services

Centrify was founded on the idea of centralizing identity and access management across the heterogeneous enterprise within Active Directory. More specifically, this meant the integration of UNIX and Linux systems into Active Directory to support centralizing identity services and access controls for both the operating system as well as the applications and services running on those systems.

Over time we have seen the transition to virtualization as well as the transition from data center to software-defined data centers where “infrastructure as code” models are used to deploy virtualized systems hosted on-premises as well as in cloud Infrastructure-as-a-service environments. This transition to Cloud-hosted virtual machines has been a challenge for Identity and Access Management (IAM) and Privileged Access Management (PAM) professionals as they work to provide IAM services to these systems without creating yet another identity silo. 

There are also several new application use cases that contribute to the IAM challenges of this new environment, where applications are being redesigned to take advantage of the robust capabilities of the software-defined data center.

Modernizing AAPM

Automated application deployments within virtualized environments are driving the need for centralized storage and management of both credentials and configuration information (aka secrets), in order to support the distribution of the application across different virtual machines that support the operation of the application. Additionally, these applications are being designed to support automated scaling in order to support fluctuating loads, which requires automated access to their credentials and secrets which must be simple, fast, and secure. In many cases these applications are made up of several services which may require authentication from one service to another, which will also require the management of the credentials used to authenticate those connections.

As you can see, these environments tend to focus more on machine-to-machine communication. Thus, there is more focus than ever on the machine-to-machine identity and access controls to support these new applications. 

Delegated Machine Credentials

Given these new realities, we sought to build a solution that would enable scripts and applications to get temporary credentials so they can authenticate to the Centrify Platform via REST API calls. This empowers them to perform specific operations such as checkout a credentials, retrieve or update a secret or data value, or request a temporary token to access an external web service.

Leveraging a well-known model for computer accounts, we enhanced the enrollment of computers such that Operations can control the role assignment for new computers, as their accounts are created without exposing a long-lived credential to any automation tooling. This enrollment process with short-lived tokens and pre-assignment to a role enables Operations to control the rights that are granted to new compute instances for access to Centrify Platform objects, without requiring app developers to modify any code.

Additionally, we are leveraging well-known authentication protocols such as OAuth2 to grant specifically-named applications or services on each computer the right to request scoped tokens to authenticate to the Centrify Platform. We call this Centrify Delegated Machine Credentials, which essentially creates machine accounts that are configured as OAuth2 confidential clients for federated authentication to the Centrify Platform.

Figure 1 – Workload using Centrify Client and Delegated Machine Credentials to access Centrify Privilege Access Service

This model makes it far simpler for an app developer to get a temporary credential that is needed to perform the action desired. It doesn’t need to be stored, vaulted or rotated periodically. It only grants the right to call specific APIs of the Centrify Platform via the scoped token. Only the properly named application can make that request to get the scoped token via Centrify CLI or lrpc2 calls to the Centrify Client. Applications can be pre-authorized via the computer’s membership in a role that grants specific rights to other Centrify Objects where membership in the role is controlled by the enrollment code.

This enhanced model gives the Operations team the flexibility to customize the deployment configuration of the application and the objects that it is authorized to access without requiring code modifications. This can be especially helpful when Operations needs to set up multiple test and production environments for the same application. 

Learn More

If you want to learn more about this new capability, we have a Solution Brief available that covers many more use cases, and provides more detail on the operation of the solution. You can always try Centrify Delegated Machine Credentials for yourself by signing up for our free tier Centrify Privileged Access Service via the AWS Marketplace. And we have made our Centrify CLI tool available in source and binary form on GitHub, where you can learn more about the Client and how to use it within your own automation scripts. 

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