gitter-badger / gatekeeper Goto Github PK

Gatekeeper is self-serviced web application allowing users to make requests for temporary access to EC2/RDS instances running in AWS and gain access instantly.

For EC2 Gatekeeper leverages AWS SSM (Amazon Simple System Manager) to create (and remove) temporary users on EC2 Instances

For RDS Gatekeeper leverages the AWS RDS API to be able to connect to supported RDS instances and generate users with generic sql queries specific to the engine of the RDS Instance. Currently gatekeeper supports mysql and postgres

See our blog post here for more information

We also had a demo of the application in action at AWS Re:invent 2017, to see that you can find the following links below:

In a transient environment where application instances are constantly being torn down / spun up managing user access gets complicated. Gatekeeper resolves this by automating the creation of that user, and making sure that the user is only valid for a temporary time period.

Since access is automated and on a temporary basis, using Gatekeeper can reduce the amount of permanent users that get set up on an instance, allowing your resources to be more secure.

Gatekeeper also stores and logs all of the access requests making user access fully auditable.

We are initally providing a local run of the gatekeeper application, in the coming months we will provide more details on getting the Gatekeeper Application deployed into AWS.

Gatekeeper requires the following tools to be installed and on your $PATH variable:

1. Java 8+
2. Maven 3+
3. NPM 3+
4. Docker

Currently we provide a shell script that builds all of the app code / containers that comprise Gatekeeper. Currently we only support this for Linux and Mac environments. All you have to do is provide the following environment variables

1. AWS_DIRECTORY: the location on your computer with your AWS Credentials usually it's <USER_HOME>/.aws
2. http_proxy: if behind a corporate proxy set the proxy to this variable. (defaults to blank if not provided)

Once you have these set, simply run start.sh and the script will build all the gatekeeper code/containers + bring up gatekeeper locally.

Hit gatekeeper at the following locations to see the different User/Roles in action:

https://localhost:443 => Regular User

https://localhost:444 => Ops/Support User

https://localhost:445 => Approver

If you're a windows 10 user we don't have a script for you unfortunately, but that doesn't mean you can't run gatekeeper locally.

Make sure you have the following environment variables set:

1. AWS_DIRECTORY: the location on your computer with your AWS Credentials usually it's <USER_HOME>/.aws
2. http_proxy: if behind a corporate proxy set the proxy to this variable. you need to set it to blank if not provided

Run the following commands:

#cd to containers folder and build the base containers
docker-compose build
#cd to demo-services and build the fake-account-service
mvn clean install
#cd to services directory and build the gatekeeper backend services
mvn clean install
#cd to the ui directory and build the gatekeeper UI code
npm run win-build
#cd to the main directory and build the gatekeeper containers
docker-compose -f local-docker-compose.yml build
#bring the gatekeeper up with the following command
docker-compose -f local-docker-compose.yml up

Hit gatekeeper at the following locations to see the different User/Roles in action:

https://localhost:443 => Regular User

https://localhost:444 => Ops/Support User

https://localhost:445 => Approver

We currently only have a local instance of gatekeeper running, if you wanted to use it with your AWS Environment some setup needs to be done.

1. Ensure that your EC2 instances all install (and run) the AWS SSM agent
   • without the SSM agent running gatekeeper cannot create/delete temp users
2. Stage SSM docs to create/delete users for Linux/Windows (more details below)
3. Set up IAM roles for gatekeeper
   • an IAM role that the gatekeeper app runs with
     • this account needs to be able to assume to the cross-account gatekeeper role
   • a "cross-account" IAM role that gatekeeper assumes to perform AWS tasks
     • this needs to allow the gatekeeper role to assume this IAM role
     • this needs to be set up on every account Gatekeeper will support
     • below is the priveliges the cross account IAM role for gatekeeper should have:

{
            "Version": "2012-10-17",
            "Statement": [
                {
                    "Sid": "Update",
                    "Effect": "Allow",
                    "Action": [
                        "ec2:Describe*",
                        "rds:Describe*",
                        "rds:ListTagsForResource",
                        "ssm:Describe*",
                        "ssm:Get*",
                        "ssm:List*",
                        "ssm:CancelCommand"
                    ],
                    "Resource": [
                        "*"
                    ]
                },
                {
                    "Effect": "Allow",
                    "Action": [
                        "ssm:SendCommand"
                    ],
                    "Resource": [
                        "arn:aws:ssm:*:*:document/GK*",
                        "arn:aws:ec2:*:*:*"
                    ]
                }
            ]
        }

4. for RDS databases a gatekeeper account needs to be set up on every RDS instance you intend to use Gatekeeper with
   • for postgres please see aws/rds/postgres_setup.sql
   • for mysql please see aws/rds/mysql_setup.sql

Gatekeeper requires some configuration for it to run in your environment, see below for all of the supported configuration parameters

These parameters are used by both the EC2 and RDS Gatekeeeper services

Currently Gatekeeper only supports authorization through LDAP, the application expects authentication to be done via SSO, and looks for the username in a header.

Gatekeeper primarily communicates out temporary credentials via email, these are the properties gatekeeper requires for email

These configurations are specific to Gatekeeper EC2

You will set these once for each environment you have in your company

Here's an example (taken from config/ec2_service_config.env)

gatekeeper.approvalThreshold.dev.dev=45
gatekeeper.approvalThreshold.dev.qa=44
gatekeeper.approvalThreshold.dev.prod=-1
gatekeeper.approvalThreshold.dev.test=4

gatekeeper.approvalThreshold.support.dev=42
gatekeeper.approvalThreshold.support.qa=41
gatekeeper.approvalThreshold.support.prod=2
gatekeeper.approvalThreshold.support.test=5

This tells Gatekeeper the following:

1. For a developer role the maximum hours the user can request is:
   • <= 45 for dev environment
   • <= 44 for qa environment
   • approval is always required for prod
   • <= 4 for test
2. For a support role the maximum hours the user can request without requiring approval is:
   • <= 42 hours for dev environment
   • <= 41 for qa environment
   • <= 2 for prod environment
   • <= 5 for test environment

Gatekeeper for EC2 resources requires SSM documents to be staged to AWS before being able to generate a temporary user. There are 4 different documents that Gatekeeper requires you to provide in order to Create and Delete temporary users. These documents are:

1. Create document for Linux
2. Delete document for Linux
3. Create document for Windows
4. Delete document for Windows

We provide examples of what we are currently using in our environment, you can find these documents located in the aws/ssm folder; You ultimately have control of the content in these documents should you have differing requirements in your environment.

If you decide to write your own document, please keep in mind that gatekeeper will be passing on the following parameters to the documents.

For create documents (linux):

1. userName - Gatekeeper provides The Username for the temporary user. Currently gatekeeper provides this to the SSM document in the form of gk-$username
2. publicKey - Gatekeeper generates the public key for the user and provides it to the SSM document
3. executionTimeout - Gatekeeper provides The maximum time to wait for the script to succeed

For windows gatekeeper functions differently as we do not want to send the user password directly to SSM (these parameters get logged to the AWS console, so the password would be exposed which is insecure), instead we rely on SSM to generate the user password on the Windows box and have the box send the username and password directly to the requestor(s)

For create documents (windows):

1. opsEmail - Gatekeeper provides the email of the operations team so that they are notified if any issue occurs
2. teamEmail - Gatekeeper provides the team email to notify the team that supports gatekeeper if it encounters any issues
3. userId - Gatekeeper provides the User Id being added
4. userName - Gatekeeper provides the User Name being added
5. account - Gatekeeper provides the account the windows instance exists in
6. mailFrom - Gatekeeper provides the sender of the email (who users of gatekeeper see the email is from)
7. smtpServer - YOU MUST PROVIDE THIS IN THE TEMPLATE the SMTP server that will be responsible for relaying the mail
8. hours - Gatekeeper provides the amount of time the request is for
9. accessRequest - Gatekeeper provides the access request ID
10. executionTimeout - Gatekeeper provides The maximum time to wait for the script to succeed

For delete documents:

1. userName - Gatekeeper provides the Username for the temporary user that should be removed.
2. executionTimeout - Gatekeeper provides the maximum time to wait for the script to succeed.

For convenience, we have provided SSM scripts with the script part left blank if you need to create your own script to set up a user / remove them. You can learn more about SSM here

The following are configuration properties which tell gatekeeper which documents to run for which action:

These configurations are specific to Gatekeeper RDS

Like the EC2 service, the RDS approval criteria needs to be set, however this configuration is handled at a more granular level.

Here is an example from config/rds_service_config.env

gatekeeper.approvalThreshold.dev.readonly.dev=120
gatekeeper.approvalThreshold.dev.readonly.qa=100
gatekeeper.approvalThreshold.dev.readonly.prod=-1

gatekeeper.approvalThreshold.dev.readonly_confidential.dev=50
gatekeeper.approvalThreshold.dev.readonly_confidential.qa=20
gatekeeper.approvalThreshold.dev.readonly_confidential.prod=-1

gatekeeper.approvalThreshold.dev.datafix.dev=180
gatekeeper.approvalThreshold.dev.datafix.qa=180
gatekeeper.approvalThreshold.dev.datafix.prod=-1

gatekeeper.approvalThreshold.dev.dba.dev=180
gatekeeper.approvalThreshold.dev.dba.qa=2
gatekeeper.approvalThreshold.dev.dba.prod=-1

gatekeeper.approvalThreshold.dev.dba_confidential.dev=-1
gatekeeper.approvalThreshold.dev.dba_confidential.qa=-1
gatekeeper.approvalThreshold.dev.dba_confidential.prod=-1

gatekeeper.approvalThreshold.ops.readonly.dev=-1
gatekeeper.approvalThreshold.ops.readonly.qa=-1
gatekeeper.approvalThreshold.ops.readonly.prod=180

gatekeeper.approvalThreshold.ops.readonly_confidential.dev=75
gatekeeper.approvalThreshold.ops.readonly_confidential.qa=50
gatekeeper.approvalThreshold.ops.readonly_confidential.prod=-1

gatekeeper.approvalThreshold.ops.datafix.dev=-1
gatekeeper.approvalThreshold.ops.datafix.qa=-1
gatekeeper.approvalThreshold.ops.datafix.prod=1

gatekeeper.approvalThreshold.ops.dba.dev=-1
gatekeeper.approvalThreshold.ops.dba.qa=-1
gatekeeper.approvalThreshold.ops.dba.prod=-1

gatekeeper.approvalThreshold.ops.dba_confidential.dev=-1
gatekeeper.approvalThreshold.ops.dba_confidential.qa=-1
gatekeeper.approvalThreshold.ops.dba_confidential.prod=-1

gatekeeper.approvalThreshold.dba.readonly.dev=180
gatekeeper.approvalThreshold.dba.readonly.qa=180
gatekeeper.approvalThreshold.dba.readonly.prod=180

gatekeeper.approvalThreshold.dba.readonly_confidential.dev=100
gatekeeper.approvalThreshold.dba.readonly_confidential.qa=125
gatekeeper.approvalThreshold.dba.readonly_confidential.prod=1

gatekeeper.approvalThreshold.dba.datafix.dev=180
gatekeeper.approvalThreshold.dba.datafix.qa=180
gatekeeper.approvalThreshold.dba.datafix.prod=180

gatekeeper.approvalThreshold.dba.dba.dev=180
gatekeeper.approvalThreshold.dba.dba.qa=180
gatekeeper.approvalThreshold.dba.dba.prod=-1

gatekeeper.approvalThreshold.dba.dba_confidential.dev=180
gatekeeper.approvalThreshold.dba.dba_confidential.qa=180
gatekeeper.approvalThreshold.dba.dba_confidential.prod=-1

Here's an explanation of what this configuration translates to in Gatekeeper:

1. For Dev Role
   • Requesting readonly
     • < 120 days for dev environment
     • < 180 days for qa environment
     • approval is always required for prod
   • Requesting readonly_confidential
     • <= 50 days for dev environment
     • <= 20 days for qa environment
     • approval is always required for prod
   • Requesting datafix
     • <= 180 days for dev environment
     • <= 180 days for qa environment
     • approval is always required for prod
   • Requesting dba
     • <= 180 days for dev environment
     • <= 2 days for qa environment
     • approval is always required for prod
   • Requesting dba_confidential
     • approval is always required for dev
     • approval is always required for qa
     • approval is always required for prod
2. For Ops Role
   • Requesting readonly
     • approval is always required for dev
     • approval is always required for qa
     • <= 180 days for prod
   • Requesting readonly_confidential
     • <= 75 days for dev environment
     • <= 50 days for qa environment
     • approval is always required for prod
   • Requesting datafix
     • approval is always required for dev
     • approval is always required for qa
     • <= 1 days for prod
   • Requesting dba
     • approval is always required for dev
     • approval is always required for qa
     • approval is always required for prod
   • Requesting dba_confidential
     • approval is always required for dev
     • approval is always required for qa
     • approval is always required for prod
3. For DBA Role
   • Requesting readonly
     • <= 180 days for dev environment
     • <= 180 days for qa environment
     • <= 180 days for prod environment
   • Requesting readonly_confidential
     • <= 100 days for dev environment
     • <= 125 days for qa environment
     • approval is always required for prod
   • Requesting datafix
     • <= 180 days for dev environment
     • <= 180 days for qa environment
     • <= 180 days for prod environment
   • Requesting dba
     • <= 180 days for dev environment
     • <= 180 days for qa environment
     • approval is always required for prod
   • Requesting dba_confidential
     • <= 180 days for dev environment
     • <= 180 days for qa environment
     • approval is always required for prod

You can see the format for these properties below: