AWS

Overview

Running Conjur on Amazon Web Services allows your organization to use existing in-house AWS knowledge to provide a secure and scalable privileged access management platform for internal and external customers. Conjur can take advantage of AWS features like auto-scaling, load balancing, health checks and key encryption to compose robust high-availability infrastructure. Access to AWS resources from other platforms can also be managed with Conjur.

This page describes several ways in which Conjur integrates with AWS. Each integration can be implemented on its own, or integrations can be combined to further strengthen and automate a Conjur environment running on AWS.

Conjur AMI

To make it easy to run Conjur on AWS, we provide an AMI for every release. Docker is the primary distribution packaging of Conjur, so the AMI is built to run Conjur in Docker.

AMIs are shared directly to the AWS account(s) you specify. Contact us to request access to Conjur AMIs.

See our AWS Setup Guide for instructions on how to obtain Conjur AMIs and launch them in EC2.

Running a Conjur HA Cluster on AWS

A High Availability (HA) Conjur environment contains Conjur masters, standbys and followers. AWS services can be used to create a robust Conjur environment that will continue to work even when downtime occurs in AWS regions and availability zones.

Our recommended infrastructure setup utilizes these AWS resources:

  • EC2
  • Route53
  • Elastic Load Balancing

This is a fairly standard setup:

This is a representative configuration provided for example purposes only. Specific needs and requirements may dictate adjustments to this basic architecture. For example:

  • us-east-1a could also run Conjur followers.
  • Followers can also be deployed outside of EC2 (e.g. to other cloud providers, or to the data center).
  • The master and standby could be setup in the data center, with followers running in AWS.

In the figure above, Conjur is deployed to multiple availability zones (AZs), in AWS region us-east-1.

A Conjur master and standby are deployed as EC2 instances to AZs us-east-1a and us-east-1b, respectively. The instances are fronted with a Route53 DNS route and a cross-zone Elastic Load Balancer (ELB). The Route53 route resolves to the CNAME of the ELB, which passes requests on to the Conjur master EC2 instance. The health check for the ELB should ping /health on the Conjur instances. The Conjur health route returns 200 if Conjur is healthy. Otherwise it returns 502. Note that any standbys in the ELB will report as unhealthy. That is fine; these instances are only needed if a problem occurs with the Conjur master. When a standby is promoted master, it will report as healthy and start fielding requests from the ELB.

Note that if Conjur is deployed behind ELB/Route53, the hostname presented during initial setup (evoke configure master) should be the Route53 route, not the automatic DNS name of the EC2 instance. Automatic public DNS names can change if the instance is stopped and restarted; this will cause SSL verification to fail.

Two Conjur followers are deployed as EC2 instances to AZs us-east-1c and us-east-1d. These instances are also fronted with a Route53 DNS route and an ELB. Traffic to this ELB is then distributed across any follower instances. The ELB health check for followers should use the /health route as well. Note that for most use cases, two followers in an region is sufficient (they should run in different availability zones). For very high-traffic environments (lots of reads), an Auto-Scaling Group can also be used to scale followers up and down based on demand. Applications can issue read-only requests directly to the Route53 route fronting the followers' ELB.

Note that this is a simpler HA setup that should fit the needs of most organizations. Conjur standbys and followers can also be deployed to AWS regions across the globe to further reduce downtime potential caused by AWS datacenter issues. We recommend running Conjur in a VPC and taking regular EBS snapshots of the Conjur master instance. When KMS encryption is used (see below), backups do not contain any plaintext secrets or plaintext encryption keys.

Using KMS encryption

Conjur's internal database encryption keys and SSL private keys can be encrypted using AWS's Key Management Service (KMS). Encrypting the keys provides the following advantages:

  • Operational Conjur servers do not store any keys in plaintext on the filesystem. Data encryption keys are stored in the Linux kernel keyring, and SSL private keys are stored only in memory.

  • Conjur "seed" files, which are used to initialize Standby and Follower servers, contain only encrypted keys and are therefore no longer a part of the threat surface to Conjur itself.

  • The master key that unlocks the server keys can be provided by KMS.

  • Backups of Conjur contain encrypted data and encrypted data keys; secrets stored in backups cannot be decrypted without KMS.

Access to AWS from other platforms

Larger organizations typically use several different cloud platforms. Access to AWS services from other AWS services (EC2 instance to S3 bucket, for example) can be managed with IAM, but managing access to AWS services from other platforms (Azure, GCE, IT data center, etc) can be difficult. Conjur simplifies this problem by providing an API and suite of tooling that can be used to grant access to AWS resources from outside the AWS environment.

Example: An operations dashboard webapp running on premise lists an organization's running instances across all cloud environments. The webapp needs to be able to make a call to the AWS API to retrieve the list of instances. To facilitate this use case:

  1. Create an IAM user that only has permission to list EC2 instances.

  2. Store the access and secret keys for this user as variables in Conjur.

  3. Permit the host running the webapp to execute (fetch) the variables.

  4. Use the host's Conjur identity to fetch the AWS keys and make the API call.