Using AWS OpsWorks (Chef 12) to deploy Centrify DirectControl in EC2 Linux Instances

This article is a republish of a blog post that I wrote for the Centrify Community Techblog.

Background

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 have a Kerberos key table for a service account authorized to join systems to Active Directory and Centrify Zones
  For an article on this topic, click here:
  http://centrifying.blogspot.com/2017/04/setting-up-kerberos-keytab-to-automate.html
• 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

http://centrifying.blogspot.com/2017/04/building-test-lab-centrify-capabilities.html

You need to be at the Standard Edition set up to follow this lab.

Note:  for abbreviated instructions and the source code for the methods use here, go to https://github.com/centrify/AWS-OpsWorks

Supported Platforms

• Amazon Linux
• Centos 7
• Red Hat Enterprise 7
• Ubuntu 16.04 LTS
• Ubuntu 14.04 LTS
• Chef 12

Configuration Overview

1. Copy your Kerberos keytab to your S3 bucket
2. Create an IAM policy for use by the IAM role for the instances created by OpsWorks
3. Create an IAM role to grant EC2 instances to access AWS resources
4. Create and configure Chef 12 OpsWorks custom stack
5. Add a layer to your stack
6. Add instances and troubleshooting
7. Verifying success for provisioning and deprovisioning

Copy your Kerberos keytab to your S3 bucket

1. Sign-in to the system that has the keytab (if the keytab file is in Linux, copy it to your Windows system)
2. Open Go to the S3 console: https://console.aws.amazon.com/s3/home
3. Click your S3 bucket and then click upload
   
4. Press Upload, click on the uploaded file and note the link.  E.g.
   https://s3-your-region.amazonaws.com/your-bucket-name-here/login.keytab

Create an IAM policy for use by the IAM role for the instances created by OpsWorks

1. Go to the IAM home:  https://console.aws.amazon.com/iam/home and click on Policies, then Create Policy
2. Select "Create your own Policy"
3. In the review policy page, give it a name (e.g. Centrify-Keytab-S3-Access-Policy and a description)
4. The policy should contain the following
   

   {
    "Version": "2012-10-17",
    "Statement": [ 
     {
     "Effect":"Allow",
     "Action":[
      "s3:GetObject",
      "s3:ListObject"
     ],
     "Resource":[ "arn:aws:s3:::your_s3_bucket/login.keytab" ]
     },
     {
     "Action": ["ec2:*",
      "iam:PassRole",
      "cloudwatch:GetMetricStatistics",
      "cloudwatch:DescribeAlarms",
      "ecs:*",
      "elasticloadbalancing:*",
      "rds:*"],
     "Effect": "Allow",
     "Resource": ["*"] 
     }
    ]
   }

   Substitute "your_s3_bucket" for the name of the S3 bucket you have from the AWS Centrify lab or from your environment.
5. Press Validate Policy and then Press Create Policy.

Now you have a Policy.

Create an IAM role to grant EC2 instances to access AWS resources

1. Go to the IAM home:  https://console.aws.amazon.com/iam/home and click on Policies, then Create New Role
2. In Select Role Type  under Amazon Role Service Amazon EC2, click Select
3. In attach policy, find the previously-created policy  (e.g. Centrify-Keytab-S3-Access-Policy) and check the box next to it, then press Next Step.
4. In set role name and review, give the role a name and optionally a description.
5. Click on the newly-created role and go to the Trust Relationship tab and press edit and substitute with this:
   

   { 
       "Version": "2012-10-17", 
       "Statement": [ 
           { "Effect": "Allow", 
           "Principal": { 
               "Service": [ "opsworks.amazonaws.com", "ec2.amazonaws.com" ]
               
           }, "Action": "sts:AssumeRole" 
               
           }] 
       
   }

6. Press Update Trust History

Now you have a role associated to your policy

Create and configure Chef 12 OpsWorks custom stack

In this step, we'll configure the stack to be used for deploying DirectControl, here we'll add custom JSON with information about your environment.

Create a Stack 

1. Go to the AWS OpsWorks home:  https://console.aws.amazon.com/opsworks/home and Press Add Stack
2. Select Chef 12 stack and complete the following info:
   • Name, Region and Subnet > based on your AWS Settings
   • Operating System > Linux and select your OS/version based on the supported platforms above
   • Default SSH Key > select yours if needed (do this at first to troubleshoot)
   • Use Custom Chef cookbok > Yes
   • Repository type: Git
   • Repository URL:  https://github.com/centrify/AWS-Opsworks.git
3. Select Advanced Options and in Custom JSON add:
   

   {
    "CENTRIFY_REPO_CREDENTIAL":"your-repo-credential",
    "CENTRIFYDC_JOIN_TO_AD": "yes",
    "CENTRIFYDC_ZONE_NAME": "AWS",
    "CENTRIFYDC_KEYTAB_S3_BUCKET": "centri-bucket",
    "CENTRIFYDC_ADDITIONAL_PACKAGES": "centrifydc-openssh",
    "CENTRIFYDC_ADJOIN_ADDITIONAL_OPTIONS": "--ldap --verbose --container ou=servers,ou=centrify"
   }

   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)
4. 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.

1. In your newly-created stack, click on layers and press Add Layer
2. Give it a name and a short name and press Add Layer
3. 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
4. On the Network tab, select the option based on your AWS VPC setup (e.g. Public IP addresses yes)
5. 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)
6. Press Save.

Adding instances to your stack  

Adding instances is the opportunity to debug your newly-created stack recipes.

1. 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)
2. Press Add Instance
   
3. 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