Skip to content

strongdm/aws-lab-in-a-box

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

21 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

StrongDM Lab in a Box for AWS

Warning

While we will attempt to keep tagged versions "working", there are a lot of improvements being shipped. Update with caution :)

This repository contains a set of modules that enable the user to deploy a quick lab to evaluate StrongDM capabilities, including

  • An optional VPC, Subnet, Security Groups, NAT and Internet Gateway sets
  • A StrongDM Gateway and a relay with an instance profile allowing them to use AWS secrets manager
  • An SSH Target using StrongDM's CA for Authentication
  • An RDS PostgreSQL target, using an autogenerated secret stored in AWS Secrets Manager for access
  • AWS Read Only access on Both CLI and Console
  • A Windows domain controller
  • A Windows server target using certificate authentication
  • An EKS Cluster

All resources are tagged according to variables set in the module, in order to set adequate access roles in StrongDM

Prerequisites

In addition to the usual access credentials for AWS, the modules require an access key to StrongDM with the following privileges:

StrongDM Permissions

Export the environment variables

export SDM_API_ACCESS_KEY=auth-aaabbbbcccccc
export SDM_API_SECRET_KEY=jksafhlksdhfsahgghdslkhaslghasdlkghlasdkhglkshg

or in Powershell

$env:SDM_API_ACCESS_KEY="auth-xxxxxx888x8x88x8x6"
$env:SDM_API_SECRET_KEY="X4fasfasfasfasfasfsafaaqED34ge5343CkQ"

Note

The verification of the operating system is done based on the presence of "c:" in the module path. If there is no c:, the module will not assume you're using Windows.

Make sure you're logged into sdm with sdm login specially if you're using the Windows CA target, as it will use the local process to pull the Windows CA Certificate

Variables

  • Network

    • vpc: Id of an existing VPC. If it's null a new VPC will be created. If this variable is provided all of the related network variables will be required
    • gateway_subnet: ID of a Public Subnet
    • relay_subnet(-b,-c): Private subnets to deploy resources
    • private_sg: Id of the Security group for private machines (reachable by the relay)
    • public_sg: ID of the public security group The module will not verify if the right network configuration is set so make sure to refer to the SDM Ports Guide
  • Resources

    • create_linux_target: Create a linux target resource with ssh ca authentication
    • create_rds_postgresql: Create an RDS Postgresql database using password authentication, retrieving credentials from secrets manager
    • create_eks: Create a Kubernetes Cluster
    • create_domain_controller: Create a Windows Domain Controller
    • create_windows_target: Create a Windows RDP target
    • create_aws_ro: Create a Role that can be assumed by the gateway to access AWS
  • Other Variables:

    • tagset: tags to apply to all resources
    • name: an arbitrary string that will be added to all resource names

You can reference the terraform.tfvars.example file in the main module for reference

Getting started

Within the main module, do the usual steps

cd main
terraform init
terraform plan
terraform apply

If you're running this in Windows you may have to set your execution policy accordingly as the script will run some local Powershell to retrieve the CA certificate

set-executionpolicy bypass

Windows Target Warnings

Setting up a Domain controller takes several reboots. This is implemented by a persistent Powershell script that runs at each reboot and has flow control through creating some "flag files" in c:\ with the "done" extension as each step is completed. You can reference the full Powershell script here.

This means that of cource that you cannot deploy the "Windows target" until the domain controller is up and running