Centrify 2017.3 - Container Linux by CoreOS is now supported

In this article, we'll discuss Centrify's support for Container Linux by CoreOS introduced with 2017.3 (5.4.3).  This is based on an article I wrote for the Centrify Community.

About Container Linux by CoreOS
"Container Linux by CoreOS (formerly CoreOS Linux) is an open-source lightweight operating system based on the Linux kernel and designed for providing infrastructure to clustered deployments, while focusing on automation, ease of application deployment, security, reliability and scalability. As an operating system, Container Linux provides only the minimal functionality required for deploying applications inside software containers, together with built-in mechanisms for service discovery and configuration sharing." - Source: Wikipedia.

Engineering Challenges
We had to overcome some challenges based on how Container Linux is architected.

• No package manager (required to deploy our solutions).
• Read-only /usr filesystem (Centrify usually installs under /usr/share/centrifydc and audit under /usr/share/centrifyda).
• No Perl (required by group policy and other utilities).
• Kernel not compiled with auditd support (required for file/monitoring).

Needless to say, our Engineering team was up to the task and was able to provide a solution that enabled our capabilities and maintained the ease-of-use that is common with Centrify solutions.

Solution

• Centrify provides an installation tarball with the 2017.3 agent bundle that includes Access and Audit components.
  
• A special version of the install.sh utility will allow for interactive or automatic installations.
• Centrify software is installed in the /opt/centrify folder.
• Limitations:  Express mode, deployment manager installation and monitoring service are not available.

Features
Host-Based Security

• Increased accountability - Container Linux users can sign-in with their Active Directory account.  We provide identity assurance with Multi-Factor Authentication.
  In AWS deployments, organizations don't need to rely on the shared SSH Key-based credential called "core"
• Centralized administration - Organizations don't have to duplicate effort and continue to leverage Active Directory as the directory of record.  No modifications required.
• Identity Management - Leverage Centrify zones to maintain a consistent UNIX namespace.
  You can leverage AD groups to control the memberships in the docker secondary UNIX group.
• Role-based Access Control - Use Centrify zones to control who can access a system, and what commands can be run with privilege.  For example:
  • You can create a role that defines who can elevate to root or the core accounts.
  • You can use Active Directory group membership to define who is a member of the docker(233) secondary group.
  • You can define very granular docker commands that can be granted to minimize risk or enforce separation of duties.
• Attestation and Security Operations -  Leverage Centrify Reports to facilitate attestation and Centrify Audit Trail to enrich security operations.
• Advanced Auditing -  Enjoy audit trail events as well as session capture and replay. 
• Extend host-based security to Linux Containers (LXC) - Centrify "bridges" capabilities to Linux Containers to enjoy the same level of accountability at the container level.

Vault-Based Security 

• Shared Account Password Management - if you need to use shared credentials, use the Centrify Privilege Service vault and enjoy the deployment flexibility and traditional password-related controls.
• Secure Access -  privilege Service connector infrastructure allows for Web, Native or SSH jumpbox client access regardless of on-premises or IaaS deployments. 
• Session Proctoring, termination and recording - Enjoy the benefits of session control as well as auditing without the need to add local capabilities.

Videos - Centrify + Container Linux in action

What's different in Container Linux

Host-based  Access Control, Identity Assurance and Role-Based Privilege Management
 
Vault-based Access Control, Shared Accounts and Secure Access

Using Role-based Access Control to manage and establish accountability for Docker operations


Centrify and Linux Containers (LXC)

[Labs] Centrify's SSH Gateway Explored - On Premises, AWS, Azure and GCP

This article illustrates the steps to set-up a lab to test the SSH Gateway capability of Infrastructure Service.  This capability provides secure access to on premises or IaaS (AWS, Azure or Google Cloud Platform) systems leveraging the Secure Shell protocol (SSH+File Transfer).

Background
Centrify Infrastructure Services provides a full-fledged secure shell and file transfer capability (SSH Gateway).  This "jumpbox"  supports all the core features of the platform including multi-factor authentication, workflow, real-time monitoring and session capture and replay.

Goals of this Lab

• Identity Consolidation:
  • Leverage existing Organizational Directory Services.
  • Accomodate for user populations outside the organization (e.g. Federation, other Directories, etc).
• Usability:  Provide secure access to systems running the SSH Service without visiting the Centrify portal.
• Access Control:  Align with best practices for security access controls, like:
  • Identity Assurance via Multi-factor Authentication.
  • Adherence to the Least Privilege principle  (users shall only access systems and accounts that they have a business need to access).
• Auditability:
  • Event tracking (who, what, when).
  • Allow the real-time proctoring of shell sessions as well as the session recording to be replayed later (e.g. PCI DSS 10.2.2).
• Simplicity and multi-use:  Provide these capabilities with minimal infrastructure or to reuse components of Centrify Infrastructure Service (E.g. leverage other services like AD or LDAP Proxy, or RDP jumpbox services).

Requirements

• A Centrify Infrastructure Services instance (SaaS or Customer Managed) - 17.10 and above.
• A Centrify Connector running the SSH gateway in all the subnets required for SSH jumpbox access.
• A handful of test systems running the SSH Service.
• SSH and sFTP client software.
• If testing "true MFA": An OATH OTP, configured RADIUS token or enrolled Mobile Authenticator.
• Familiarity with Centrify Infrastructure Services.
  • Policy and Authentication Profiles.
  • A configured "Corporate IP Range." 
  • Familiarity with CPS Roles, Permissions and Sets.
• Understanding of the communication paths for CPS (e.g. between connector and instance (HTTPS), between connector and SSH Servers (standard SSH port TCP 22).  Note that these ports are customizable.
• Understading of Infrastructure Services Role-based Access Control.

Conceptual Diagram


This diagram showcases the major components, the location, firewall rules, and additional details depend on the environment.

Diagram for this Lab


High-level Implementation Steps
AWS

• In this implementation, I'm using an AWS VPC as my "corporate HQ"  it has an AD domain, some systems (Windows and Linux) as well as a hosted AD domain.  This will allow me to have different user populations.
• I am leveraging an existing Active Directory and DirectAudit infrastructure.
• Launched a Windows 2012 R2 instance with a public IP address, Fthis instance is in a security group,  that allows inbound HTTPS and SSH from the internet to the instance, plus it can reach the rest of the systems internally, including AD (to allow for it to be joined).
• For internet name resolution, I created a CNAME record in the rpdemo.net DNS domain for the cps record that resolves to the public DNS name for the EC2 instance above
• Obtained a publicly rooted certificate, and exported it with the private key for Privilege Service to use.
• Installed Privilege Service (on-premises) in single-master mode (no HA);
  Note:  The single-master configuration does not provide HA or allows for upgrades.  This is for testing purposes only.
• Added a Centrify connector with the adproxy and SSH gateway services.
• Configured Privilege Service to use my ISP's IP address as part of the corporate IP range.  This is to provide the assurance that only I can access it.
• Configured 2 roles:  An Administrator, and a Least Access role.
• Configured Workflow for the resources.

Microsoft Azure

• Created inbound rules that allow the connector in AWS to reach the systems over RDP and SSH.
  Note: Depending on the services needed, an additional connector in Azure (or GCP) is needed.
• Launched existing Windows and Linux systems.

Test Matrix (Success Criteria)

Category	Description	Result
Identity Consolidation	Users from Active Directory and Centrify Directory can access systems via Web Portal or SSH Gateway.	Pass
Identity Assurance with MFA	Users must use an MFA or Step-up method to authenticate via Web portal or SSH Gateway.	Pass
Policy	Users can only access from a specific subnet.	Pass
Least Access	Users can only access the systems based on business need to know via Web Portal or SSH Gateway.	Pass
Access Request	Users must request temporary access to shared accounts.	Pass
Monitoring (real time)	SSH/RDP – Sessions can be monitored in real time. SFTP – Active sessions can be tracked.	Pass
Advanced Auditing	Sessions can be reviewed after the fact (indexing, replay, etc.)	Pass
Infrastructure Simplicity and Reuse	The same components can be used for other capabilities (e.g. RDP, etc).	Pass

Test Videos
Identity Consolidation and  Assurance with MFA

Policy, Least Privilege and Access Request

Real-time Monitoring  + Session Capture and Replay

Infrastructure Simplicity and Reuse

Centrify's Support for IBM i (AS/400) with Privilege Service

In a nutshell

• Centrify Infrastructure Service provides support for AS/400 systems
• Versions 6.x and 7.x (although 6.x will be EoL soon)
• You must be running SSH on your AS/400
• Apply all platform PIM features (Policy, MFA, Workflow, RBAC, SSH Gateway, etc)
• Secure Access via SSH
• Password Lifecycle
• Support for different password profiles.

See it in Action

How to check out passwords from the CLI using Centrify Infrastructure Services

How to check out passwords from the CLI using Centrify Infrastructure Services
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 discover the options available to retrieve passwords from the CLI and we'll focus on using it as a way for 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:

Eliminate Passwords
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.

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:

sudo cenroll --tenant vault.centrify.vms --user admin@opie.demo 
--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:

Enroll-CIPSystem -EnrollCode "THISIS-YADA-YADA-CODE-682DBEF6CA78"  
-FQDN 'member.centrify.vms'  -ResourceName 'member-vault' 
-Endpoint 'https://vault.centrify.vms'

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.

Permissions
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.

Monitoring
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.


Deployment Utilities

• 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.

Implementations
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.  Notice that you can specify the checkout lifetime.

Futures
This is an area of a lot of interest for Centrify.  Stay tuned.