Search…
Control Your EKS Fleet with Systems Manager
This page describes how to use AWS Systems Manager (SSM) to install agents or configuration on your EKS worker nodes automatically.

Overview

Customers that run self-hosted EKS clusters may need a way to manage their worker nodes for compliance, security, and/or operational reasons. The most common example is needing to install a monitoring agent on the EKS worker nodes to validate system configuration or to run vulnerability scans on each physical node in the cluster.
ReleaseHub installs the AWS SSM agent on each node in advance so that new clusters and nodes will automatically be available in the Fleet Manager and Operations Management section of AWS Systems manager. In this way, customers can leverage the full power of AWS's products for full compliance in whatever way is necessary.
The AWS SSM product is fully audited, logged, and configurable inside your AWS account and enables customers to meet the highest security, compliance, and operational needs available in the market at the time of this writing. The Systems Manager defines a document that is used to define the installation or configuration steps to execute on each node. Then, the document can be associated to a node or nodes by tag and executed on an ad hoc, or repeated schedule basis.
The steps required for enabling SSM to run on your nodes are as follows:
  • Create an SSM document to install or configure your nodes
  • Create a fleet association to match nodes (or apply to all nodes)
  • Create a schedule to apply the document to your fleet at set intervals

Example for Installing the Vanta Agent

In this example we will walk you through a common task of installing the Vanta agent on each node in a cluster. The directions should be general enough to get you started on any configuration or installation exercise you wish to complete. Documents can be shared across accounts and regions once created. You can create and manage these documents via the AWS Console, AWS CLI, Terraform, or any other suitable method.

Create an SSM document

The SSM document is a YAML or JSON document that describes parameters, steps, and configuration options that will be applied to nodes. There are many example documents available in AWS and our recommendation is to start with one. In this example, we will start with the AWS default document called AWS-RunRemoteScript. This generic template is designed to download a script or file from Github or S3 and then execute it on either a Linux or Windows server. This fits perfectly with the Vanta agent installation. For Linux, the installation involves running the installation script from Github and supplying an API key. For the Windows agent, one downloads a signed version from your Vanta website and storing the binary in S3 for installation.
Following the instructions for selecting the document or copying the document with the CLI, you will want to specify the parameters to the source code that will be run in a later step:
"sourceInfoLinux": {
"description": "(Required) Specify the information required to access the resource from the source. If source type is GitHub, then you can specify any of the following: 'owner', 'repository', 'path', 'getOptions', 'tokenInfo'. If source type is S3, then you can specify 'path'.",
"type": "StringMap",
"displayType": "textarea",
"default": {
"owner": "VantaInc",
"repository": "vanta-agent-scripts",
"branch": "master",
"path": "install-linux.sh"
}
},
"sourceInfoWindows": {
"description": "(Required) Specify the information required to access the resource from the source. If source type is GitHub, then you can specify any of the following: 'owner', 'repository', 'path', 'getOptions', 'tokenInfo'. If source type is S3, then you can specify 'path'.",
"type": "StringMap",
"displayType": "textarea",
"default": {
"path": ""https://s3.amazonaws.com/our-example-bucket/ourVantaAgent/vantaagent.exe""
}
}
Next, specify the command line that will be used in each installation process, one for Linux and one for Windows. Notice that the Vanta key can be pulled from parameter store or secrets manager when specified in the parameters section.
"commandLineLinux": {
"description": "(Required) Specify the command line to be executed. The following formats of commands can be run: 'pythonMainFile.py argument1 argument2', 'ansible-playbook -i \"localhost,\" -c local example.yml'",
"type": "String",
"default": "VANTA_KEY={{ssm:/admin/vanta/vanta_key}} ./install-linux.sh"
},
"commandLineWindows": {
"description": "(Required) Specify the command line to be executed. The following formats of commands can be run: 'pythonMainFile.py argument1 argument2', 'ansible-playbook -i \"localhost,\" -c local example.yml'",
"type": "String",
"default": "vantaagent.exe"
}
Set a temporary working folder for the installation for each OS
"workingDirectoryLinux": {
"type": "String",
"default": "/tmp",
"description": "(Optional) The path where the content will be downloaded and executed from on your instance.",
"maxChars": 4096
},
"workingDirectoryWindows": {
"type": "String",
"default": "${env:TEMP}",
"description": "(Optional) The path where the content will be downloaded and executed from on your instance.",
"maxChars": 4096
},
Next, the actual execution of the installation steps occurs for each distribution.
"mainSteps": [
{
"action": "aws:downloadContent",
"name": "downloadContentLinux",
"inputs": {
"sourceType": "Github",
"sourceInfo": "{{ sourceInfoLinux }}",
"destinationPath": "{{ workingDirectoryLinux }}"
}
},
{
"action": "aws:downloadContent",
"name": "downloadContentWindows",
"inputs": {
"sourceType": "S3",
"sourceInfo": "{{ sourceInfoWindows }}",
"destinationPath": "{{ workingDirectoryWindows }}"
}
},
{
"precondition": {
"StringEquals": [
"platformType",
"Windows"
]
},
"action": "aws:runPowerShellScript",
"name": "runPowerShellScript",
"inputs": {
"runCommand": [
"",
"$installed = (Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\* | Where { $_.DisplayName -match 'Vanta' }) -eq $null"
"",
"If(-Not $installed) {",
" {{ commandLineWindows }}",
"}"
""
],
"workingDirectory": "{{ workingDirectoryWindwos }}",
"timeoutSeconds": "{{ executionTimeout }}"
}
},
{
"precondition": {
"StringEquals": [
"platformType",
"Linux"
]
},
"action": "aws:runShellScript",
"name": "runShellScriptLinux",
"inputs": {
"runCommand": [
"",
"if ! sudo yum list installed vanta || ! sudo service vanta.service status",
"then",
" {{ commandLineLinux }} ",
"fi",
""
],
"workingDirectory": "{{ workingDirectoryLinux }}",
"timeoutSeconds": "{{ executionTimeout }}"
}
}
]

Create a Fleet Association

Follow the steps found in the References section below to create an association. This is an example of how to associate the document with nodes in your cluster. You can specify nodes either by tag names and values, choose them manually (not recommended), choose them by Resource Groups (see the documentation), or simply choose "all" instances which might be a very good choice.
Associate the document with nodes using tags or choose instances directly
Here is a helpful table to select some common tags for EKS clusters:
Selection Criterion
Tag Key
Tag Value
Any EKS worker node
alpha.eksctl.io/cluster-name
Only nodes in a specific cluster
alpha.eksctl.io/cluster-name
<your-cluster-name>
Nodes marked production
VantaOwner

Create a Schedule

You can select a simple cron style method for applying the State Manger association to any nodes as they are added to your cluster, or if the application is somehow uninstalled or stops working. In this way, you never have to worry about keeping nodes up to date as they are added, removed, or changed.
Specify a schedule for your association

Specify a Logging Bucket

You can log the output and executions in a logging bucket of your choice.

Verify it is working

After some time you will be able to inspect logs in an S3 bucket if you have one. You can also view progress and events in the SSM Inventory Dashboard or State Manager History section.
Verify the installation and executions

References