As part of the security toolbox, we must deal with shared credentials, more specifically passwords. Many of you know how Infrastructure Services can secure credentials, however, a lot of work is going on to enhance the DevOps or automation use cases. In this article we'll explore the options available to retrieve passwords from the CLI using Centrify, how it works, how it's secured and how programs or scripts to retrieve them.
Using shared passwords in CLI scenarios while maintaining assurance
Passwords have been hard to get rid of, unfortunately, even with old technologies like Kerberos and PKI we must accommodate for the need to securely retrieve credentials. However, at the same time we need to maintain assurance and enforce principles like:
- Try to eliminate passwords
- Limit lateral movement
- Just in time/just enough access/privileges
- Identity Assurance
- Monitoring and Auditing
- Policy enforcement, etc
The maturity model illustrates this best:
Centrify eliminates passwords in this use case by relying on PKI credentials; the process happens during enrollment when a system is onboarded by an authorized party. The enrollment process looks like this:
Each system is represented by a service account in Centrify Infrastructure Service. Please note that in order to modify the PKI settings on a system, you must have administrative rights (you you require privileged access on the client side), plus you must have either an enrollment code or a user credential of a user that can enroll a system into Centrify Infrastructure Services.
In Linux, this is implemented with the cenroll command. If ther's a manual enrollment, we also ask for MFA based on authentication profiles like here (enrolls a system called centos7 to a vault.centrify.vms using the email@example.com credential and enables all features):
sudo cenroll --tenant vault.centrify.vms --user firstname.lastname@example.org
--verbose --features all --agentauth identity-broker-users
--name centos7 --address centos7.centrify.vms
If an Enrollment code is available, you can use it (the most common way of doing this, especially for automation), here's how it looks on Windows, with a code (enrolls a system called member-vault using an enrollment code):
Enroll-CIPSystem -EnrollCode "THISIS-WHERE-YOUR-CODE-GOES"
-FQDN 'member.centrify.vms' -ResourceName 'member-vault'
Access Control, Entitlements and Visibility
Centrify relies heavily on role-based access, but this is an interesting use case because it's highly-related to automation. In this scenario, most likely a system will be built, and as part of the on-boarding it will automatically enroll to the Centrify platform. Centrify includes a built-in group called: Centrify Agent Computers; by default, this group has visibility to systems, domains and databases.
As a best practice, don't overload the Centrify Agent Computers built-in group. Just use it for visibility purposes. Create sets and other roles, and leverage those instead.
For accounts, there are several entitlements
This means that you need View+Check out at the account level to check out a password. This is a mechanism for least access and limiting lateral movement.
Policy Enforcement and Monitoring
The most common password checkout policies (like multi-checkout or lifetime) are geared towards interactive use, but for machine communications, Centrify offers the ability to override the checkout lifetime settings at the account level.
A great policy that can be implemented is the use of internal/external, datetime or even Risk. This can be applied at the account level.
Because a compromised system, although with limited access is still a potential "stakeout" point, monitoring service account checkouts outside the applicable time or at a rate that is out of the blue, the monitoring and alerting capabilites of CIP provide several tools like: Dashboards, Reports or the ability to send events to a security operations or SIEM tool.
- Enrollment codes: allow Centrify clients to enroll the platform automatically. The benefit of codes is that you can add restrictions (like how many times or from which networks they can be used) or organizational options like sets or RBAC.
- Sets: Sets are collections of objects in CPS; they allow for dynamic or static membership as well as controlling permissions.
- Packages: The CLI toolkits are delivered as part of the Centrify clients for Linux or Windows.
- Policy overrides: Password lifetime overrides allow for different policies at the parent or account levels. This is useful when you need policies for human beings vs. machines.
The Centrify Agent for Linux, leverages the cgetaccount command (checking out the opieadmin local account password from as system called engcen6 for 5 minutes).
Here's more info about cgetaccount.
Here's how it looks in PowerShell (checking out the sa SQL server account from the database enterprise for 2 minutes)
Note that these examples are interactive checkouts. Ideally, a script or program would call this command to retrieve the password string and use it or assign it to a variable; as you can also see, the option to specify the checkout lifetime is available.
The solutions above address the challenge from the point of view of an infrastructure lead specifically focusing on systems. Although in this article we don't cover this in depth, it should be known that everything in the Centrify Identity Platform uses REST APIs.
The Developer Reference pages here: https://developer.centrify.com are another resource in your arsenal.
The resource management API, specifically the /Servermanage/CheckoutPassword API provides the capability of password checkouts. This reference provides the folllowing code samples:
- Node JS
- C# and
PowerShell Sample Pages in GitHub
Many of the CIP methods are already available in PowerShell using the samples posted in Github.
This is an area of a lot of interest for Centrify. Stay tuned.