Note: This public repo contains the documentation for the private GitHub repo https://github.com/gruntwork-io/module-security. We publish the documentation publicly so it turns up in online searches, but to see the source code, you must be a Gruntwork customer. If you're already a Gruntwork customer, the original source for this file is at: https://github.com/gruntwork-io/module-security/blob/master/README.md. If you're not a customer, contact us at [email protected] or http://www.gruntwork.io for info on how to get access!

This repo contains modules for setting up best practices for managing secrets, credentials, and servers:

• auto-update: This module can configure a Linux server to automatically install security updates.
• aws-auth: This script module makes it easy to use the CLI to authenticate to AWS when you have an MFA code, or want to assume an IAM Role in another AWS account.
• cloudtrail: This Terraform Module configures AWS CloudTrail in an AWS account, along with reasonable defaults around the S3 Bucket in which CloudTrail logs are stored.
• kms-master-key: This Terraform Module creates a new Customer Master Key (CMK) in Amazon's Key Management Service (KMS) as well as a Key Policy that controls who has access to the CMK. You can use a CMK to encrypt and decrypt small amounts of data and to generate Data Keys that can be used to encrypt and decrypt larger amounts of data.
• ssh-iam: This module contains an app called ssh-iam that allows you to manage SSH access to your EC2 Instances using AWS IAM. Developers can upload public SSH Keys to their IAM user accounts and ssh-iam will allow them to SSH to EC2 Instances using their IAM user name and SSH key for authentication.
• iam-groups: This Terraform Module creates a best-practices set of IAM Groups that can be used to secure human and machine IAM Users.

Click on each module above to see its documentation. Head over to the examples folder for examples.

At Gruntwork, we've taken the thousands of hours we spent building infrastructure on AWS and condensed all that experience and code into pre-built packages or modules. Each module is a battle-tested, best-practices definition of a piece of infrastructure, such as a VPC, ECS cluster, or an Auto Scaling Group. Modules are versioned using Semantic Versioning to allow Gruntwork clients to keep up to date with the latest infrastructure best practices in a systematic way.

Most of our modules contain either:

1. Terraform code
2. Scripts & binaries

To use a module in your Terraform templates, create a module resource and set its source field to the Git URL of this repo. You should also set the ref parameter so you're fixed to a specific version of this repo, as the master branch may have backwards incompatible changes (see module sources).

For example, to use v1.0.8 of the ecs-cluster module, you would add the following:

module "ecs_cluster" {
  source = "git::[email protected]:gruntwork-io/module-ecs.git//modules/ecs-cluster?ref=v1.0.8"

  // set the parameters for the ECS cluster module
}

Note: the double slash (//) is intentional and required. It's part of Terraform's Git syntax (see module sources).

See the module's documentation and vars.tf file for all the parameters you can set. Run terraform get -update to pull the latest version of this module from this repo before runnin gthe standard terraform plan and terraform apply commands.

You can install the scripts and binaries in the modules folder of any repo using the Gruntwork Installer. For example, if the scripts you want to install are in the modules/ecs-scripts folder of the https://github.com/gruntwork-io/module-ecs repo, you could install them as follows:

gruntwork-install --module-name "ecs-scripts" --repo "https://github.com/gruntwork-io/module-ecs" --tag "0.0.1"

See the docs for each script & binary for detailed instructions on how to use them.

For an intro to server security, check out the following guides:

• My First 10 Minutes On a Server - Primer for Securing Ubuntu
• 2016 Guide to User Data Security
• 7 Security Measures to Protect Your Servers
• The Open Web Application Security Project, especially their handy cheat sheets on Password Storage, Session Management, SQL Injection, and XSS.
• What should every programmer know about security?

We are following the principles of Semantic Versioning. During initial development, the major version is to 0 (e.g., 0.x.y), which indicates the code does not yet have a stable API. Once we hit 1.0.0, we will follow these rules:

1. Increment the patch version for backwards-compatible bug fixes (e.g., v1.0.8 -> v1.0.9).
2. Increment the minor version for new features that are backwards-compatible (e.g., v1.0.8 -> 1.1.0).
3. Increment the major version for any backwards-incompatible changes (e.g. 1.0.8 -> 2.0.0).

The version is defined using Git tags. Use GitHub to create a release, which will have the effect of adding a git tag.

See the test folder for details.

Please see LICENSE.txt for details on how the code in this repo is licensed.