Skip to content

Latest commit

 

History

History
257 lines (219 loc) · 10.9 KB

ssm.md

File metadata and controls

257 lines (219 loc) · 10.9 KB

SSM - AWS Systems Manager

  • Used for managing a fleet of EC2 instances and on-premise systems at scale
  • Offers operational insights about the state of the infrastructure
  • Provides easy problem detection
  • Offers patching automation for enhanced compliance
  • Works for both Windows and Linux
  • It has integration with CloudWatch metrics and dashboards
  • It has integration with AWS Config

SSM Features

  • Resource Groups
  • Operations Management:
    • Explorer
    • OpsCenter
    • CloudWatch Dashboard
  • Shared Resources:
    • Documents
  • Change Management:
    • Change Manager
    • Automation
    • Change Calendar
    • Maintenance Windows
  • Application Management:
    • Application Manager
    • AppConfig
    • Parameter Store
  • Node Management:
    • Fleet Manager
    • Compliance
    • Inventory
    • Hybrid Activations
    • Session Manager
    • Run Command
    • State Manager
    • Patch Manager
    • Distributor

How Systems Manager Works?

  • We need to install the SSM agent on the systems we want to control
  • The agent is by default installed on Amazon Linux and some Ubuntu AMIs
  • If an instance can not be controlled by the agent, the issue is probably with the agent on the IAM role is missing to allow SSM actions

AWS Tags and Resource Groups

  • We can add text key/value pairs to many AWS resources
  • Tags are commonly used with EC2 instances
  • Tags can be used for resource grouping, automation, cost allocation
  • AWS Resource Groups are used to create, view and manage logical groups of resources
  • They allow creation of logical groups of resources such as :
    • Applications
    • Different layers of an application stack
    • Differentiate a prod and development environment
  • There are 2 types of resource groups:
    • Tag based
    • CloudFormation stack based

AWS SSM Documents

  • SSM Documents are written in JSON or YAML
  • In SSM Documents we define parameters and actions. Documents are then executed by a specific service
  • Documents are either managed by AWS or created and managed by users
  • Documents can be 4 different types:
    • Command
    • Automation
    • Policy
    • Session
  • Example of AWS SSM Document:
schemaVersion: "2.2"
description: "Hello World"
parameters: 
    parameters: 
        type: "String"
        description: "Some text to print"
        default: "none"
mainSteps: 
    - 
        action: "aws:runShellScript"
        name: "runShellScript"
        inputs: 
            workingDirectory: "{{.}}"
            runCommand:
            - "echo 'hello world'"
            - "echo {{ parameters }}"
  • AWS Documents are used to run commands with SSM Run Command
  • They are also used with State Manager, Patch Manager, Automation
  • AWS Documents can retrieve data from Parameter Store

SSM Run Command

  • Used for execute documents (scripts) or just to run simple commands
  • Commands are executed across multiple instances (using resource groups)
  • Documents are either managed by AWS or created and managed by users
  • Run Command has builtin rate control/error control - progressively roll out commands to instances, in case of errors stop executing commands
  • Integrates with IAM and CloudTrail
  • SSM Run Command requires no SSH access to instances
  • The output of the command can be shown in the AWS SSM Run Command Console, or it can be sent to an S3 bucket or to CloudWatch Logs
  • Run Command can be evoked with Even Bridge

SSM Automation

  • Systems Manager Automation simplifies common maintenance and deployment tasks of Amazon EC2 instances and other AWS resources. Automation enables to do the following:
    • Build automations to configure and manage instances and AWS resources
    • Create custom runbooks or use pre-defined runbooks maintained by AWS
    • Receive notifications about Automation tasks and runbooks by using Amazon EventBridge
    • Monitor Automation progress and details by using the AWS Systems Manager console
  • Automation Runbook:
    • SSM Documents of type Automation
    • Define actions to be performed on our EC2 instances or other AWS resources
    • Runbooks may be pre-defined (by AWS) or custom
  • Automation can be triggered:
    • Manually by using the AWS console, AWS CLI or SDK
    • By Amazon EventBridge
    • On schedule using Maintenance Windows
    • By AWS Config rules remediations
  • Automation use cases:
    • Perform common IT tasks:
      • Use the AWS-StopEC2InstanceWithApproval runbook to request that one or more AWS Identity and Access Management (IAM) users approve the instance stop action. After the approval is received, Automation stops the instance
      • Use the AWS-StopEC2Instance runbook to automatically stop instances on a schedule by using Amazon EventBridge or by using a maintenance window task
      • Use the AWS-UpdateCloudFormationStackWithApproval runbook to update resources that were deployed by using CloudFormation template. The update applies a new template
    • Safely perform disruptive tasks in bulk:
      • Use the AWS-RestartEC2InstanceWithApproval runbook to target an AWS resource group that includes multiple instances
    • Simplify complex tasks:
      • Use the AWS-UpdateLinuxAmi and AWS-UpdateWindowsAmi runbooks to create golden AMIs from a source AMI. We can run custom scripts before and after updates are applied. We can also include or exclude specific packages from being installed
      • Use the AWSSupport-ExecuteEC2Rescue runbook to recover impaired instances. An instance can become unreachable for a variety of reasons, including network misconfigurations, RDP issues, or firewall settings
    • Enhance operations security
  • WhitePaper: Building a Secure, Approved AMI Factory Process Using Amazon EC2 Systems Manager (SSM), AWS Marketplace, and AWS Service Catalog https://d1.awsstatic.com/whitepapers/aws-building-ami-factory-process-using-ec2-ssm-marketplace-and-service-catalog.pdf

SSM Parameter Store

  • Used for securely storing configuration and secrets in AWS
  • It can have optional encryption using KMS
  • Serverless, scalable, durable, easy SDK
  • Version tracking of configurations and secrets
  • Configuration management happens using IAM policies
  • We get notification with Amazon EventBridge
  • Has full integration with CloudFormation

SSM Parameter Store Hierarchy

  • Example of hierarchy:

    • /my-department/
      • my-app/
        • dev/
          • db-url
          • db-password
        • prod/
          • db-url
          • db-password
      • other-app
    • /other-department

SSM Parameter Tiers

  • Standard:
    • Total number of parameters: 10K
    • Max size of a parameter: 4KB
    • Pricing: free
    • Parameter policies: NO
  • Advanced:
    • Total number of parameters: 100K
    • Max size of a parameter: 8KB
    • Pricing: 0.05$ per advanced parameter per month
    • Parameter policies: YES

SSM Parameters Policies for Advanced Parameters

  • Allow assigning a TTL for a parameter to force updating or deleting sensitive data
  • We can assign multiple policies at a time

SSM Parameter Store CLI

  • Get parameters

    aws ssm get-parameters --names /my-app/dev/db-url /my-app/dev/db-password

  • Get parameters decrypted

    aws ssm get-parameters --names /my-app/dev/db-url /my-app/dev/db-password --with-decryption

  • Get parameters by path: gets multiple parameters recursively

    aws ssm get-parameters-by-path --path /my-app/ --recursive

SSM Patch Manager

  • Used to automatically patch running instances with OS updates, application updates, security patches, etc.
  • Patching can happen on-demand or on a schedule with Maintenance Windows
  • Patch Baselines:
    • Defines which patches should and should not be installed on an instance
    • We have the ability to create custom Patch Baselines
    • Patches can be auto-approved withing days of their release
    • By default, only critical patches and security patches are installed
  • Patch Groups:
    • We can associate a set of instances with a specific Patch Baseline
    • Instances should defined with the tag key Patch Group
    • An instance can only be part of one Patch Group
    • A Patch Group can only be registered with one Patch Baseline
  • Patch Baseline types:
    • Pre-defined Patch Baseline:
      • Managed by AWS for different Operating Systems
      • AWS-RunPatchBaseline SSM Document can be used to run a Patch Baseline
    • Custom Patch Baseline:
      • We can create our own Patch Baseline and choose which patches to auto-approve
      • We can specify custom and alternative patch repositories

Maintenance Windows

  • It is a scheduled job (Cron job) in order to specify when the patch baselines can be applied to instances
  • We can set the duration of windows (up tp 24 hours)
  • We can set a period before patching in order to stop initiating new tasks
  • Register targets: we have to register a target for which the patching has to be done. Targets can be based on tags, resource groups or single resource
  • Register a run command: we have to set a command (example RunPatchBaseline) which will execute the patches

SSM Inventory

  • Used to collect data about running instances
  • The data it collects can be the following:
    • Applications
    • AWS Components
    • Network configurations
    • Windows Updates
    • Instance Detail Information
    • Services
    • Etc.

AWS Session Manager

  • Allows to start a secure shell on a VM
  • Does not use SSH access and bastion hosts
  • Only works for EC2 for now
  • Log actions done through secure shells to S3 and CloudWatch Logs
  • IAM permissions: access SSM + write to S3 + write to CloudWatch
  • CloudTrail can intercept StartSessions events
  • AWS Secure Shell compared to SSH:
    • No need to open port 22 at all anymore
    • No need fot a bastion host
    • All commands are logged to S3/CloudWatch
    • Access to Secure Shell is done through User IAM, not SSH keys

SSM Hybrid Activations

  • SSM Hybrid Activations: https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-managedinstances.html
    • Used form setup on-premise instances in order to be managed by SSM
    • When a hybrid activation is created, SSM provides an Activation Code and an Activation ID which will be used to set up the SSM agent on the on-premise instance
    • The instance id for EC2 instances starts with i- and for on-premise instances it starts with mi-
    • Managed on-premise instances can be tagged in SSM