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
As Amazon AWS's popularity increases as an IaaS platform, many organizations are looking to extend current capabilities like consolidated identities and privilege management out to those environments.
AWS provides a framework for DevOps called AWS OpsWorks. This framework allows the use of solutions like Chef or Puppet to manage the lifecycle of Linux or Windows instances.
Centrify customers and prospects have requested sample configurations to control the lifecycle of the deployment of Centrify DirectControl out in AWS. The typical goals are:
Linux or (Windows) instances are launched in AWS
Centrify DirectControl is installed on these instances
The system is joined to Active Directory (Linux) and the Centrify Zone, Child Zone and/or Computer Role (Windows, Linux)
On termination, the system(s) leave the domain and Centrify zone (freeing-up the Centrify license)
This way, while the system is running:
Administration is Centralized and not duplicated (like with SSH keys)
Assurance is achieved, for example, with MFA
Privileged User Management is based on roles
There are reporting and attestation mechanisms.
Pre-flight Checklist
You have AWS account set up with a VPC set up correctly for DNS and Active Directory communication
Your account has AWSOpsWorksFullAccess and permission to create, modify, read, list and delete IAM Policies and Roles
You have Active Directory (managed by you or with Amazon) and a Centrify Zone
You have tested joining a Linux system to your AD and Centrify zone successfully. Your users can authenticate and perform privilege management duties.
You have an AWS S3 Bucket and permission to create and upload files to it.
You know the DN for your Computers container (e.g. "ou=servers,ou=centrify"), this is where the service account can create (or delete) computer objects.
You have a Centrify Repo credential, zone information (E.g. Name) or an alternate repo with the Centrify packages for your platform type (yum, apt, zypper)
Optional: A domain-joined Windows server with Centrify tools (for verification purposes)
Optional: You have an AWS key-pair to deploy our EC2 instances to connect for troubleshooting purposes
A Centrify-AWS Lab article has been written for the pre-requisites
The information (in red) in this JSON file is based on my example configuration: CENTRIFY_REPO_CREDENTIAL is the cyphered username/password combination assigned to you in the Centrify Download repo page. CENTRIFY_ZONE_NAME is the name of the Centrify Zone in AD that I want my Linux systems to be joined to CENTRIFY_KEYTAB_S3_BUCKET is the name of the S3 bucket that contains the login.keytab file for the service account. CENTRIFY_ADJOIN_ADDITIONAL_OPTIONS: has been set with the --container option that points to the DN of where my service account can add computer objects (e.g. ou=servers,ou=centrify)
Press Add Stack
Add a Layer
The desired state is that when the system is launched, the Centrified system is joined to AD and to the Zone. Once the system is shutdown, the system leaves AD, the Centrify license is freed and the access/privilege reports reflect the proper information.
In your newly-created stack, click on layers and press Add Layer
Give it a name and a short name and press Add Layer
In the layers, click on Recipes tab, this will display the Custom Recipes lifecycle
Setup box: centrify_agents::deploy_centrifydc
Shutdown box:centrify_agents::undeploy_centrifydcPress Save
On the Network tab, select the option based on your AWS VPC setup (e.g. Public IP addresses yes)
On the Security tab, press Edit and in Security Groups select your Security group EC2 Instance Profile select the IAM Role created in the previous step (e.g. Centrify-IAM-Role-4EC2)
Press Save.
Adding instances to your stack
Adding instances is the opportunity to debug your newly-created stack recipes.
In your stack, click Instances and click Add an Instance
Hostname: give it a name (e.g. test1)
Size: select a size (e.g. t2-micro)
Subnet: select a subnet from your VPC (must have AD connectivity and DNS resolution)
Press Add Instance
Press Start
Troubleshooting and Debugging
Your troubleshooting can happen from the OpsWorks console. If there's an issue with your setup, the console will provide you with an error and a log with the actions yielded by Chef. For example, while debugging, I saw this issue:
Note that the erros will be quite explicit. The category of errors that you'll see may be dependent on the sanity checks that you perform along the way.
Known Errors
Invalid CENTRIFYDC_ADDITIONAL_PACKAGES attribute: the JSON value contains an invalid value. Valid entries include: centrifydc-openssh, centrifydc-ldapproxy, etc. Modify the value of the custom JSON attributes in the stack.
Either user your-user@YOURDOMAINNAME. does not have sufficient permissions to update the YOUR_ZONE zone computer information: this means that the service account can't create the computer object in the target container. Note that if you did not modify the JSON parameter for the stack called CENTRIFY_ADJOIN_ADDITIONAL_OPTIONS to have the --container switch with the proper DN, adjoin will try to add the system to the default computers container in AD. This is atypical.
Verifying Success - Provisioning
The layman's test is to be able to sign-in to the system and perform privilege elevation
The OpsWorks console shows the system online.
In Active Directory, there should be a computer object in the target OU:
Attestation reports can be generated with who has access to which system(s), what type of access they have, what privileged commands they can run, and where the privileges came from.
Verifying Success - Deprovisioning
The best test here is to stop the system and verify that the objects don't exist in AD and the system no longer is present in the Access/Privilege reports.
Conclusion
You can leverage Centrify's Github https://github.com/centrify/ for different private and public cloud configurations. This scenario is only the first of many to come.
Related Articles
Setting a Centrify AWS Test Lab:http://centrifying.blogspot.com/2017/04/building-test-lab-centrify-capabilities.html
Background
Securing Linux instances in public (or private) clouds often requires the duplication of infrastructure (or additional overhead) just to be able to provide basic services like authentication. Centrify just debuted a new client that leverages a capability called Identity Broker. This allows users of Centrify privilege service to extend authenticaiton to Linux systems using Active Directory, LDAP, Google Directory and others without the need to implement extensions to AD or LDAP or any supporting infrastructure (like site-to-site VPNs). The Challenges (AWS as an example)
In previous blog posts,
we discussed the additional controls that can be implemented on top of
Amazon's IAM and cryptography-based capabilities. The model suggested the use of Active Directory and Centrify Server Suite.
Regardless of the solution, organizations need
to find ways to extend this infrastructure by using these techniques:
Re-creation of infrastructure (e.g. standing-up Active Directory or LDAP-like infrastructure)
Network extension (e.g. treating the public cloud like a branch by implementing site-to-site VPNs)
Capability duplication (e.g. implementing software and services in AWS)
In this article we'll discuss how organizations can leverage Centrify
Privilege Service and the new Linux Agent (Identity Broker) to secure
Linux instances and extend Enterprise Identity out to public clouds
without the need of the additional overhead.
Centrify Privilege Service
Privilege Service is Centrify's answer to the traditional
"password-driven" use cases (the industry refers as Shared Account
Password Management, Privilege Session Management, etc); however unlike
other solutions, there are several capabilities areas that set it apart
from the traditional "Password Vault"
Flexible deployment: Both as SaaS and On Premises (in fact, it was designed as a SaaS solution first)
Identity Sourcing and Federation built-in (includes Identity
Service, this means support for AD, LDAP, Google and others plus
simplified SAML-based federation and 3K+ ready web and mobile apps)
Policy, Workflow and MFA Engine: Policies for time and
geo-location, RBAC, step-up authentication and Multi-factor including
Smartcard, plus a built-in access request system (+ServiceNow
integration)
Infrastructure Extensibility: Privilege Service can be extended to
any network using a Windows-based Centrify Connector via web protocols.
New Linux Agent
The new Linux agent takes advantage of a capability called "Identity
Broker" this allows the bridging of identities known to Centrify
Privilege Service; this is done via the Centrify connector. This means
that the overhead of duplicating enterprise identity infrastructure or
extending the enterprise to the public network can be avoided in this
particular use case; all that is required is to deploy a Centrify
connector wherever you want to extend Password-related services and
Linux authentication. Let's show an illustration.
Company X needs to provide identity-based reporting and attestation
of who has access to their public cloud EC2 instances in AWS; their
primary identity source is AD. They could have used any model
(independent forest, one-way trust + site2site VPN or RODC) to extend AD
to AWS or they could have deployed Amazon IAM roles and used SSH keys;
but any of these models implied additional overhead. With CPS and
Identity Broker, all they did is this:
With this model, CompanyX not only can accomodate their corporate IT
users, but external entities as well. And as we discussed before,
password, session and additional services are consolidated as well, both
on premises and on any public cloud. Plus
No need to deploy "jumpboxes" to the private clouds (limits exposure)
Shared account passwords for local accounts (Linux, Windows) or databases (like Amazon RDS) can be controlled
Access Request provides the assurance of "documented approvals" to sensitive systems
Deploy MFA or access only from the OnPrem network as additional controls.
Agent Architecture
The client architecture is using UNIX frameworks like Name Service
Switch (Identity) and Pluggable Authentication Modules (Auth). It also
supports offline login as well as direct or proxy-based user/password or
OAUTH-based enrollment codes (very useful for automation). This client
implements the CLI tookit for setting, retrieving or deleting
credentials under management.
Supported Platforms Platforms supported in the initial release - more on the way UNIX Identity
Following on the legacy of Server Suite, the new agent generates identity like DirectControl in workstation mode. Login - user's short name (must use the fully-qualified name the first time) UID - auto-generated based on the GUID Primary group - auto-private (same as UID) GECOS - the display name in Centrify Identity Service Home/Shell - configurable in the Settings tab.
Since most public clouds don't need legacy identity (for services like NFS), this makes the client very lightweight.
Automation
There's an implied expectation of DevOps "friendliness" when a
private or public cloud solution is implemented. The new Linux agent
leverages enrollment codes for this capability.
Centrify provides a sample AWS script that can be used with
enrollment codes in the User Data field or with any other framework like
OpsWorks (see attachment)
Identity Broker
Privilege Service can accomodate several identities, including:
Note that it can accommodate identities from Active Directories without any trust relationships.
These identities can be aggregated using Identity Service Roles:
Roles, in turn can be assigned the AgentAuth privilege on a Linux Resource:
As you can see the model works like this:
Users or groups from Identity Sources are added to CIS Roles that are granted the AgentAuth right in CPS.
Basic Commands
Agent Operation
cinfo – obtain information about the agent
cenroll – enroll the identity platform and enable features
cunenroll – leave the platform and optionally delete resource and any managed accounts
cflush – flush the local cache
AAPM
csetaccount – add a managed account for the resource
Centrify Access Manager and access to perform the configuration
A UNIX or Linux System and the Centrify Enterprise Edition Agent (DirectControl/DZ & DirectAudit)
A Windows System and the Centrify Enterprise Edition Windows Agent (DZWin/DAWin)
Two Active Directory Groups and a test user.
Planning Privileges Based on Roles
In the previous entry, you saw how we conquered the issue of limiting
access to systems based on business need-to-know and how we can create a
SuperUser-like role across platforms. Now it's time to implement a
true Role Based governance model. Just like with any capability
(security included) you must achieve balance on the people-process-technology
triad, in the context of Roles, its key is to understand how people use
privileges in their job functions, implement a process around it and
leverage the technology to implement it. Here's an oversimplified example for DBAs in a mixed Oracle and SQL Server shop.
How DBAs access systems: SSH and Toad on Linux and RDP on Windows
Typical tasks needed for operations: In Linux, DBAs need to run the
sqplus command as the Oracle account and switch user to oracle. In
Windows, DBAs need to run SQL Server Manager and to manipulate the SQL
Server Service.
Typical tasks needed for change-control: DBAs need to elevate to Root during upgrades and installations.
In my fictitious company, I will allow the SSH PAM access role and
the commands to run sqlplus and switch to oracle. The Sysadmin role
(that allows to elevate to root) will only be granted with a
change-control number and duration.
This process needs to be adjusted because of two things:
Resistance to change I guarantee you that users will initially think that you're making their jobs harder and will try to find ways to resist.
Nuances around how people perform their jobs For example, a
Windows DBA may also need access to SQL Server Configuration tools; or a
UNIX DBA may like to switch user without profile (su oracle, instead
of su - oracle).
So be ready to have a review of roles and rights with certain
cadence, to add/remove commands or apps; as well a to make usability
adjustments. Make it part of your attestation process.
In our example, we'll use the Centrify-Model-Mixed-Role-DBAs group to provision this role.
Access Based on Roles
The concept continues to be the same as the previous post, but now
you are further breaking down your access governance model based on your
needs. For example: you may have a DEV-QA-PROD train for an
application and you can grant access just to that set of systems, and
you can classify systems based on that model; This is where your
investment in Centrify Professional Services can pay the most. In my
example, I'll just use a Computer Role called Mixed Database Servers,
based on an AD group called Centrify-Model-Mixed-CR-Database Servers.
Security Operations Requirements
In the previous example we leveraged both the UNIX Syslog and the
Windows Event log to augment log collection capabilities. Since
DirectAudit data is contained inside a SQL server database, this is
another repository that can be tapped by log aggregators. Since
DirectAudit provides session data, information gathered from security
operations can be further investigated by looking at session data.
Provisioning
Here the principles continue to be the same as the previous entry.
Granting or revoking the role or making a system part of the collective
is performed via AD Group Membership (Manually with ADUC,
Programmatically with PowerShell or Scripting and controlled via any
Workflow engine)
Planning for Platforms
Same exceptions apply: IBM AIX with LAM enabled don't allow the breakdown of PAM access rights.
Implementation Just
like the previous entry, remember that these steps can be automated via
Centrify adedit on UNIX/Linux or Centrify Access Module for PowerShell
as well as the DirectManage SDK.
Recap: Rights go into Roles, Roles are configured and Assigned to AD
Principals in a Given Scope (zone, child zone, computer role or
individual computer)
Step 1: Create the AD Groups for the Computer Role and to assign the Roles
Manually you can open Active Directory Users and Computers (ADUC)
Navigate to your designated OU, right click > New > Group.
Select the appropriate scope and give it a name. In our case we repeat this for both Centrify-Model-Mixed-CR-Database Servers and Centrify-Model-Mixed-Role-DBAs
Step 2: Create the Mixed Database Systems Computer Role
Open Access Manager and right-click your Zone > Authorization > Computer Roles and Select Create New Computer Role.
In the New Computer Role window, give it a name (Mixed Database Systems), description and browse for the Centrify-Model-Mixed-CR-Database Servers group. Then Press OK.
Step 3: Create the DBA commands to be used in UNIX and Linux platforms SQL Plus as Oracle
Creating this command requires a bit of research. Information about
the diversity of platforms, versions and their differences are relevant.
For example, in my environment, I’m using Oracle Express 11G running on
Linux.
Another important detail has to do with the environment variables. I
want to conserve them in this case so sqlplus has all it needs to launch
correctly: Switching to the Oracle account
Some DBAs may need to do a simple (no profile) elevation, or they
would want the opposite, Centrify offers the flexibility of Regular or
Global expressions. Service Control for the Oracle Service
More research required. In my environment, the service is oracle-xe and I will limit the directives available for service.
Step 4: Create the DBA commands to be used in Windows platforms SQL Server Management Studio
Windows application rights provide a lot of flexibility. Some key highlights
You can consolidate several applications in a single command
Applications can be defined manually, by looking at local or remote processes or by browsing directly to the file.
Application arguments can be evaluated with or without case sensitivity
Application types can be further broken down (e.g. exe, bat, cmd, vbs, ps1, etc.)
Additional criteria can be added based on the file metadata (e.g. version, company, etc)
Application rights can be executed in 3 different contexts
As a service account: the user in the role does not need to know the credentials.
As a member of an AD group without persistent membership
As a member of a Windows built-in group (like Power Users, etc.)
In the case of the SQL Server Management studio, I have a Windows
native deployment with a SQL management account. I can easily use an AD
group, but since I have this privilege elevation mechanism, I don’t need
to fall into the bad habit sharing that account - there are many other
ways to accomplish the same objective.
Stop, start and query the SQL Server Service command
I'm choosing to use the service control command line utility (sc.exe)
in the context of the local administrator account to provide the DBA
with the ability to control the SQL server service. The alternative
today is to grant the DBA administrator rights, which they can use to
stop other services (like the AV or firewall).
Step 5: Creating, configuring, assigning the role and provisioning a user
This process follows exactly the same steps of the previous post.
Keep in mind that the Windows rights will be for remote (RDP or Citrix)
and to add the UNIX and Windows rights after the role is created.
The role assignment will be performed at the Computer Role level, so
it only applies to computers provisioned into that group. Finally you
can add your test user to the group that gets the role assigned.
Part of our process dictates that if they do need higher privileges, they can request it based on a change control approval.
Step 6: Verifying and the rights on the UNIX/Linux system
To view the role attributes and definition, use the dzinfo command
$ dzinfo
User: thomasf
Forced into restricted environment: No
Role Name Avail Restricted Env
--------------- ----- --------------
Mixed Yes None
DBA/Global
Effective rights:
Password login
Non password login
Allow normal shell
Audit level:
AuditIfPossible
Always permit login:
false
PAM Application Avail Source Roles
--------------- ----- --------------------
Privileged commands:
Name Avail Command Source Roles
--------------- ----- -------------------- --------------------
DBA Oracle - Yes service oracle-xe Mixed DBA/Global
oracle-xe start|stop|status|re
service start
control/Global
DBA Oracle - Yes su oracle Mixed DBA/Global
switch to
oracle
no-profile/Glob
al
DBA Oracle - Yes sqlplus * Mixed DBA/Global
sqlplus as
oracle/Global
DBA Oracle - Yes su - oracle Mixed DBA/Global
switch to
oracle with
profile/Global
To view the command definitions, use the dzdo –l command
$ dzdo -l
AD Password:
User thomasf may run the following commands on this host:
(root) service oracle-xe start|stop|status|restart
(oracle) sqlplus *
(root) su oracle
(root) su - oracle
To use your privileges via privilege elevation use dzdo
$ dzdo service oracle-xe restart
Shutting down Oracle Database 11g Express Edition instance.
Stopping Oracle Net Listener.
Starting Oracle Net Listener.
Starting Oracle Database 11g Express Edition instance.
Finally, and for the benefit of security operations, all privilege elevation continues to be written to syslog:
Step 7: Verifying and the rights on the Windows system
In Windows, to view the role definition, you can open the Authorization Center in the System Tray, the role definitions tab shows the applications defined for the role, double clicking provides a deeper dive.
To use your privileges, in the GUI you can use the Run as role shell extension, pick the role and the application will be launched as defined. Finally, just like with UNIX, privileged elevation will be logged in the Windows Event Log. Step 8: Session Capture and Replay with Audit Analyzer
Audit analyzer provides a very neat view of what's going on with your audited systems; in the left pane you have queries and categories, on the right side you can see the sessions. The columns include the AD user, the client and server systems, the status of the session, etc.
If you drill down into a session, you can see an index of the commands or events that happened during the session.
Looking at a replay, provides you with the event data + a video of the terminal or Windows session.
Reconstructing what happened (especially on Windows platforms) is as simple as just watching and controlling like a DVR.
Finally, let's look at this scenario and do some testing:
This article is a repost of a two-part series I wrote for the Centrify Community.
"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.
