Summary

Note: This is a work in progress, we are still working on our design.

This document provides information about our SSM access model and guidance on connecting to ec2 instances.

SSM Model

Decision Path

Based on our discussions about enabling the Terraform Federated model, we figured one of our current node management model (Anisble) limitations is that providing ssh access to ec2 instances requires running the playbook after each change (adding a new ec2 instance, adding/removing users).

To remediate this limitation, we decided to leverage AWS Systems Manager Node Management capabilities. In particular, using Session Manager to start terminal sessions with ec2 instances while dedicating authentication to IAM policies.

Proposed Model

Here is the proposed workflow for starting a session with an ec2 instance.

Prerequisites

• The ec2 instance has the AmazonSSMManagedInstanceCore policy in its IAM profile.
• The SSMAgent is up and running on the instance (by default it is enabled on our base AMIs, check ace-packer-templates repository)
• The ec2 instance has a valid Team tag.
• The user-principal (either the user or the role assumed) has a valid Team tag.
• The principal has the ACESessionManagerPolicy policy attached.

Workflow

1. User authenticates with AWS (console/CLI).
2. The identity assigned to the user has a Team tag.
3. User requests to start a session with an instance.
4. Since the user has the ACESessionManagerPolicy attached, they are authorized to connect to any instance that exactly has the same Team tag as them.

Limitations/Questions

• Is it possible for a user to be a member of multiple teams?
• Should we support multiple teams having access to the same instance?
• This model gives sudo access to all authorized users. Should we support unprivileged users?

Reference

Here I will add references to the resources and how we implemented this model.

User Guides

Here I will add user guides for creating instances and connecting to them.