Esquemas, características y ejemplos
Los documentos de AWS Systems Manager (SSM) utilizan las siguientes versiones de esquema.
-
Los documentos del tipo
Command
pueden utilizar la versión de esquema 1.2, 2.0 y 2.2. Si utiliza documentos de esquema 1.2, le recomendamos que cree documentos que utilicen la versión de esquema 2.2. -
Los documentos del tipo
Policy
deben utilizar la versión de esquema 2.0 o posterior. -
Los documentos del tipo
Automation
deben utilizar la versión de esquema 0.3. -
Los documentos del tipo
Session
deben utilizar la versión de esquema 1.0. -
Puede crear documentos en JSON o YAML.
Para obtener más información acerca del esquema del documento de Session
, consulte Esquema del documento de Session.
Si utiliza la versión de esquema más reciente para los documentos de tipo Command
y Policy
, puede aprovechar las siguientes características.
Característica | Detalles |
---|---|
Edición de documentos |
Ahora los documentos pueden actualizarse. Con la versión 1.2, cualquier actualización de un documento requería guardarlo con otro nombre. |
Control de versiones automático |
Cualquier actualización de un documento crea una versión nueva. No es una versión de esquema, sino una versión del documento. |
Versión predeterminada |
Si tiene varias versiones de un documento, puede especificar qué versión es el documento predeterminado. |
Secuenciación |
Los complementos o los pasos de un documento se ejecutan en el orden especificado. |
Compatibilidad multiplataforma |
La compatibilidad multiplataforma le permite especificar diferentes sistemas operativos para distintos complementos dentro del mismo documento de SSM. La compatibilidad multiplataforma utiliza el parámetro |
Interpolación de parámetros | Permite interpolar los parámetros de cadena en las variables de entorno antes de la ejecución del comando, lo que proporciona una mayor seguridad contra las inyecciones de comandos. Cuando se establece en ENV_VAR , el agente crea una variable de entorno denominada SSM_ que contiene el valor del parámetro. |
nota
El AWS Systems Manager SSM Agent de las instancias debe mantenerse actualizado con la versión más reciente para poder utilizar las características nuevas de Systems Manager y las características del documento de SSM. Para obtener más información, consulte Actualización de SSM Agent mediante Run Command.
La siguiente tabla enumera las diferencias entre las versiones de esquema principales.
Versión 1.2 | Versión 2.2 (versión más reciente) | Detalles |
---|---|---|
runtimeConfig |
mainSteps |
En la versión 2.2, la sección |
propiedades |
inputs |
En la versión 2.2, la sección |
Comandos de la de |
runCommand |
En la versión 2.2, la sección |
id |
acción |
En la versión 2.2, |
no se usa |
nombre |
En la versión 2.2, |
Uso del parámetro precondition
Con la versión de esquema 2.2 o posterior, puede utilizar el parámetro precondition
para especificar el sistema operativo de destino de cada complemento o para validar los parámetros de entrada que definió en su documento de SSM. El parámetro precondition
admite hacer referencia a los parámetros de entrada de su documento de SSM, y platformType
utilizando los valores de Linux
, MacOS
, y Windows
. Solo el operador StringEquals
es compatible.
En el caso de documentos que utilizan la versión de esquema 2.2 o posterior, si no se especifica precondition
, cada complemento se ejecuta u omite en función de la compatibilidad del complemento con el sistema operativo. La compatibilidad de los complementos con el sistema operativo se evalúa antes de precondition
. En el caso de los documentos que utilizan el esquema 2.0 o anterior, los complementos incompatibles generarán un error.
Por ejemplo, en un documento con la versión de esquema 2.2, si no se especifica precondition
y se incluye el complemento aws:runShellScript
, el paso se ejecuta en las instancias de Linux, pero el sistema lo omite en las instancias de Windows Server, ya que aws:runShellScript
no es compatible con las instancias de Windows Server. Sin embargo, en el caso de un documento con versión de esquema 2.0, si especifica el complemento aws:runShellScript
y, a continuación, ejecuta el documento en una instancia de Windows Server, se produce un error en la ejecución. Puede ver un ejemplo del parámetro de condición previa en un documento de SSM más adelante en esta sección.
Versión de esquema 2.2
Elementos de nivel superior
En el siguiente ejemplo, se muestran los elementos de nivel superior de un documento de SSM que utiliza la versión 2.2 del esquema.
Ejemplo de la versión 2.2 del esquema
En el ejemplo siguiente, se utiliza el complemento aws:runPowerShellScript
para ejecutar un comando de PowerShell en las instancias de destino.
Ejemplos del parámetro de condición previa de una versión de esquema 2.2
La versión de esquema 2.2 ofrece compatibilidad multiplataforma. Esto significa que dentro de un mismo documento de SSM puede especificar diferentes sistemas operativos para distintos complementos. La compatibilidad multiplataforma utiliza el parámetro precondition
dentro de un paso, tal y como se muestra en el siguiente ejemplo. También puede utilizar el parámetro precondition
para validar los parámetros de entrada que haya definido en el documento de SSM. Puede ver esto en el segundo caso de los siguientes ejemplos.
Ejemplo de interpolación de la versión 2.2 del esquema con versiones de SSM Agent anteriores a la 3.3.2746.0
En las versiones de SSM Agent anteriores a la 3.3.2746.0, el agente ignora el parámetro interpolationType
y, en su lugar, realiza una sustitución de cadena sin procesar. Si hace referencia a SSM_
de forma explícita, debe configurarlo de forma explícita. En el siguiente ejemplo para Linux, se hace referencia explícita a la variable de entorno parameter-name
SSM_Message
.
{ "schemaVersion": "2.2", "description": "An example document", "parameters": { "Message": { "type": "String", "description": "Message to be printed", "default": "Hello", "interpolationType" : "ENV_VAR", "allowedPattern: "^[^"]*$" } }, "mainSteps": [{ "action": "aws:runShellScript", "name": "printMessage", "inputs": { "runCommand": [ "if [ -z "${SSM_Message+x}" ]; then", " export SSM_Message=\"{{Message}}\"", "fi", "", "echo $SSM_Message" ] } } }
nota
allowedPattern
no es técnicamente obligatorio si un documento SSM no utiliza doble llave: {{ }}
Ejemplo de la versión 2.2 del esquema State Manager
Puede utilizar el siguiente documento de SSM con State Manager, una herramienta de Systems Manager, para descargar e instalar el software antivirus ClamAV. State Manager aplica una configuración específica, lo que significa que cada vez que se ejecuta la asociación de State Manager, el sistema comprueba si el software ClamAV está instalado. En caso contrario, State Manager vuelve a ejecutar este documento.
Ejemplo de inventario con la versión 2.2 del esquema
Puede utilizar el siguiente documento de SSM con State Manager para recopilar metadatos de inventario de las instancias.
Ejemplo de la versión 2.2 del esquema AWS-ConfigureAWSPackage
El siguiente ejemplo muestra el documento de AWS-ConfigureAWSPackage
. La sección mainSteps
incluye el complemento aws:configurePackage
en el paso action
.
nota
En sistemas operativos Linux, solo son compatibles los paquetes AWSSupport-EC2Rescue
y AmazonCloudWatchAgent
.
Versión de esquema 1.2
El siguiente ejemplo muestra los elementos de nivel superior de un documento con la versión de esquema 1.2.
{ "schemaVersion":"1.2", "description":"
A description of the SSM document.
", "parameters":{ "parameter 1
":{ "one or more parameter properties
" }, "parameter 2
":{ "one or more parameter properties
" }, "parameter 3
":{ "one or more parameter properties
" } }, "runtimeConfig":{ "plugin 1
":{ "properties":[ { "one or more plugin properties
" } ] } } }
Ejemplo de la versión 1.2 del esquema aws:runShellScript
El siguiente ejemplo muestra el documento de SSM AWS-RunShellScript
. La sección runtimeConfig incluye el complemento aws:runShellScript
.
{ "schemaVersion":"1.2", "description":"Run a shell script or specify the commands to run.", "parameters":{ "commands":{ "type":"StringList", "description":"(Required) Specify a shell script or a command to run.", "minItems":1, "displayType":"textarea" }, "workingDirectory":{ "type":"String", "default":"", "description":"(Optional) The path to the working directory on your instance.", "maxChars":4096 }, "executionTimeout":{ "type":"String", "default":"3600", "description":"(Optional) The time in seconds for a command to complete before it is considered to have failed. Default is 3600 (1 hour). Maximum is 172800 (48 hours).", "allowedPattern":"([1-9][0-9]{0,3})|(1[0-9]{1,4})|(2[0-7][0-9]{1,3})|(28[0-7][0-9]{1,2})|(28800)" } }, "runtimeConfig":{ "aws:runShellScript":{ "properties":[ { "id":"0.aws:runShellScript", "runCommand":"{{ commands }}", "workingDirectory":"{{ workingDirectory }}", "timeoutSeconds":"{{ executionTimeout }}" } ] } } }
Versión de esquema 0.3
Elementos de nivel superior
El siguiente ejemplo muestra los elementos de nivel superior de un manual de procedimientos de automatización con la versión de esquema 0.3 o posterior en formato JSON.
{ "description": "
document-description
", "schemaVersion": "0.3", "assumeRole": "{{assumeRole}}", "parameters": { "parameter1": { "type": "String", "description": "parameter-1-description
", "default": "" }, "parameter2": { "type": "String", "description": "parameter-2-description
", "default": "" } }, "variables": { "variable1": { "type": "StringMap", "description": "variable-1-description
", "default": {} }, "variable2": { "type": "String", "description": "variable-2-description
", "default": "default-value
" } }, "mainSteps": [ { "name": "myStepName
", "action": "action-name
", "maxAttempts": 1, "inputs": { "Handler": "python-only-handler-name
", "Runtime": "runtime-name
", "Attachment": "script-or-zip-name
" }, "outputs": { "Name": "output-name
", "Selector": "selector.value
", "Type": "data-type
" } } ], "files": { "script-or-zip-name
": { "checksums": { "sha256": "checksum
" }, "size":1234
} } }
Ejemplo de manual de procedimientos de automatización YAML
En el siguiente ejemplo, se muestra el contenido de un manual de procedimientos de automatización en formato YAML. Este ejemplo de trabajo de la versión 0.3 del esquema del documento también demuestra el uso de Markdown para dar formato a las descripciones del documento.
description: >- ##Title: LaunchInstanceAndCheckState ----- **Purpose**: This Automation runbook first launches an EC2 instance using the AMI ID provided in the parameter ```imageId```. The second step of this document continuously checks the instance status check value for the launched instance until the status ```ok``` is returned. ##Parameters: ----- Name | Type | Description | Default Value ------------- | ------------- | ------------- | ------------- assumeRole | String | (Optional) The ARN of the role that allows Automation to perform the actions on your behalf. | - imageId | String | (Optional) The AMI ID to use for launching the instance. The default value uses the latest Amazon Linux AMI ID available. | {{ ssm:/aws/service/ami-amazon-linux-latest/amzn-ami-hvm-x86_64-gp2 }} schemaVersion: '0.3' assumeRole: 'arn:aws:iam::111122223333::role/AutomationServiceRole' parameters: imageId: type: String default: '{{ ssm:/aws/service/ami-amazon-linux-latest/amzn-ami-hvm-x86_64-gp2 }}' description: >- (Optional) The AMI ID to use for launching the instance. The default value uses the latest released Amazon Linux AMI ID. tagValue: type: String default: ' LaunchedBySsmAutomation' description: >- (Optional) The tag value to add to the instance. The default value is LaunchedBySsmAutomation. instanceType: type: String default: t2.micro description: >- (Optional) The instance type to use for the instance. The default value is t2.micro. mainSteps: - name: LaunchEc2Instance action: 'aws:executeScript' outputs: - Name: payload Selector: $.Payload Type: StringMap inputs: Runtime: python3.8 Handler: launch_instance Script: '' InputPayload: image_id: '{{ imageId }}' tag_value: '{{ tagValue }}' instance_type: '{{ instanceType }}' Attachment: launch.py description: >- **About This Step** This step first launches an EC2 instance using the ```aws:executeScript``` action and the provided python script. - name: WaitForInstanceStatusOk action: 'aws:executeScript' inputs: Runtime: python3.8 Handler: poll_instance Script: |- def poll_instance(events, context): import boto3 import time ec2 = boto3.client('ec2') instance_id = events['InstanceId'] print('[INFO] Waiting for instance status check to report ok', instance_id) instance_status = "null" while True: res = ec2.describe_instance_status(InstanceIds=[instance_id]) if len(res['InstanceStatuses']) == 0: print("Instance status information is not available yet") time.sleep(5) continue instance_status = res['InstanceStatuses'][0]['InstanceStatus']['Status'] print('[INFO] Polling to get status of the instance', instance_status) if instance_status == 'ok': break time.sleep(10) return {'Status': instance_status, 'InstanceId': instance_id} InputPayload: '{{ LaunchEc2Instance.payload }}' description: >- **About This Step** The python script continuously polls the instance status check value for the instance launched in Step 1 until the ```ok``` status is returned. files: launch.py: checksums: sha256: 18871b1311b295c43d0f...[truncated]...772da97b67e99d84d342ef4aEXAMPLE
Ejemplos de gestión segura de parámetros
Los siguientes ejemplos demuestran la gestión seguro de parámetros mediante una variable de entorno interpolationType
.
Ejecución básica de comandos de forma segura
En este ejemplo se muestra cómo gestionar de forma segura un parámetro de comando:
nota
allowedPattern
no es técnicamente obligatorio en los documentos SSM que no utilizan doble llave: {{ }}
Uso de parámetros en lenguajes interpretados
Este ejemplo demuestra la gestión segura de parámetros en Python:
Ejemplo de compatibilidad con versiones anteriores
En este ejemplo se muestra cómo gestionar los parámetros de forma segura y mantener la compatibilidad con versiones anteriores:
nota
allowedPattern
no es técnicamente obligatorio en los documentos SSM que no utilizan doble llave: {{ }}
Prácticas recomendadas de seguridad de parámetros
Siga estas prácticas recomendadas cuando gestione parámetros en documentos SSM:
-
Utilice la interpolación de variables de entorno: utilice siempre
interpolationType: "ENV_VAR"
para los parámetros de cadena que se utilizarán en la ejecución de comandos. -
Implemente la validación de entradas: utilice
allowedPattern
para restringir los valores de los parámetros a patrones seguros. -
Gestione los sistemas heredados: incluya una lógica alternativa para las versiones de SSM Agent anteriores que no admitan la interpolación de variables de entorno.
-
Escape los caracteres especiales: cuando utilice valores de parámetros en los comandos, escape correctamente los caracteres especiales para evitar que el intérprete de comandos los interprete.
-
Limite el alcance de los parámetros: utilice los patrones de parámetros más restrictivos posibles para su caso de uso.