Cómo configurar Parameter Store
Antes de configurar parámetros en el Parameter Store, configure las políticas de AWS Identity and Access Management (IAM) que proporcionan a las entidades de su cuenta permiso para llevar a cabo las acciones que especifique.
En esta sección, aprenderá a configurar manualmente estas políticas mediante la consola de IAM y asignarlas a los usuarios y los grupos de usuarios. También puede crear y asignar políticas para controlar las acciones de parámetro que se pueden ejecutar en un nodo administrado.
En esta sección, también se explica cómo crear reglas de Amazon EventBridge que le permitan recibir notificaciones sobre los cambios en los parámetros de Systems Manager. Puede utilizar reglas de EventBridge para invocar otras acciones en AWS en función de los cambios en el Parameter Store.
Contenido
Administración del acceso a los parámetros del Parameter Store mediante políticas de IAM
La entidad principal de IAM que accede a los parámetros de AWS Systems Manager debe tener permisos para ejecutar las acciones de SSM requeridas. La entidad principal puede ser un usuario de IAM, un rol de IAM, un perfil de instancia de Amazon EC2, un rol de ejecución de Lambda, un rol de tarea de Amazon ECS, un rol de servicio de CodeBuild u otro rol de servicio de AWS.
En la siguiente tabla, se describen los permisos de IAM necesarios para las diferentes acciones del Parameter Store.
| Action | Privilegio de IAM necesario | Información de referencia |
|---|---|---|
| Creación o actualización de un parámetro | ssm:PutParameter |
PutParameter |
| Recuperación de un parámetro | ssm:GetParameter |
GetParameter |
| Recuperación de varios parámetros con nombre | ssm:GetParameters |
GetParameters |
| Recuperación de parámetros de una ruta | ssm:GetParametersByPath |
GetParametersByPath |
| Visualización de metadatos de parámetros | ssm:DescribeParameters |
DescribeParameters |
| Visualización del historial de versiones de parámetros | ssm:GetParameterHistory |
GetParameterHistory |
| Eliminación de un parámetro | ssm:DeleteParameter |
DeleteParameter |
| Eliminación de varios parámetros | ssm:DeleteParameters |
DeleteParameters |
Si utiliza políticas de IAM para conceder acceso a parámetros de Systems Manager, le recomendamos que cree y utilice políticas de IAM restrictivas. Por ejemplo, la siguiente política permite a una entidad principal llamar a las operaciones de la API DescribeParameters y GetParameters para un conjunto limitado de recursos. La entidad principal puede obtener información sobre todos los parámetros que comiencen por prod-* y utilizarlos.
nota
La política anterior permite ssm:GetParameters, pero no las demás acciones de recuperación. Parameter Store autoriza cada operación de recuperación en función de su propia acción de IAM, por lo que permitir o denegar una acción no afecta a las demás. Antes de confiar en una política para restringir los parámetros que una entidad principal puede leer, consulte Cómo Parameter Store autoriza la recuperación de parámetros y Restricción del acceso a parámetros y rutas específicos.
importante
Parameter Store autoriza la operación GetParametersByPath en función de la ruta que se especifique en la solicitud, no en función de cada parámetro devuelto por la operación. La entidad principal a la que se le permite llamar a GetParametersByPath para la ruta /a recibe todos los parámetros incluidos en esa ruta, como /a/b. Esto es cierto incluso si la misma política deniega explícitamente el acceso a /a/b para otras acciones.
Para evitar que GetParametersByPath devuelva un parámetro, deniegue la acción ssm:GetParametersByPath en todas las rutas antecesoras que puedan incluir el parámetro en sus resultados. Por ejemplo, para evitar que se devuelva /a/b, deniegue ssm:GetParametersByPath tanto para /a como para /.
En el caso de los administradores de confianza, puede proporcionar acceso a todas las operaciones de la API de parámetros de Systems Manager mediante el uso de una política similar a la del siguiente ejemplo. Esta política concede al usuario acceso completo a todos los parámetros de producción que empiecen por dbserver-prod-*.
Denegar permisos
Cada API es única y tiene operaciones y permisos distintos que puede permitir o denegar individualmente. Una denegación explícita en cualquier política invalida el permiso concedido.
importante
Como cada operación está autorizada en función de su propia acción de IAM, denegar una sola acción no impide que la entidad principal recupere el mismo parámetro mediante otra operación. Por ejemplo, denegar ssm:GetParameter por sí solo no tiene ningún efecto en ssm:GetParameters, ssm:GetParameterHistory o ssm:GetParametersByPath. Deniegue siempre todas las acciones que puedan devolver el valor. Para obtener una descripción completa de este comportamiento, consulte Cómo Parameter Store autoriza la recuperación de parámetros.
nota
La clave predeterminada AWS Key Management Service (AWS KMS) tiene permiso Decrypt para todas las entidades principales de IAM dentro de la Cuenta de AWS. Si desea diferentes niveles de acceso a parámetros SecureString en su cuenta, no le recomendamos que utilice la clave predeterminada. La restricción kms:Decrypt de una clave administrada por el cliente impide el descifrado de un valor SecureString mediante cualquier operación de recuperación. Para obtener más información, consulte Restricción del descifrado de los valores de los parámetros SecureString.
Los cuatro nombres de las acciones de recuperación comienzan con GetParameter, por lo que la entrada única ssm:GetParameter* cubre ssm:GetParameter, ssm:GetParameters, ssm:GetParameterHistory y ssm:GetParametersByPath. En el siguiente ejemplo, se utiliza este patrón para denegar las cuatro acciones de todos los parámetros que comiencen por prod-*.
nota
En el ejemplo anterior, la denegación de ssm:GetParametersByPath se aplica únicamente a las llamadas que solicitan una ruta que coincida con prod-*. No impide que una llamada que solicita una ruta antecesora devuelva un parámetro prod-*. Para cerrar esa brecha, niegue también ssm:GetParametersByPath en las rutas antecesoras. Para obtener más información, consulte Restricción del acceso a parámetros y rutas específicos.
En el siguiente ejemplo se muestra cómo denegar algunos comandos mientras se permite al usuario realizar otros comandos en todos los parámetros que comienzan con prod-*.
nota
El historial de parámetros incluye todas las versiones de parámetros, incluida la actual. Por lo tanto, si se deniega a un usuario el permiso para GetParameter, GetParameters y GetParametersByPath, pero se le otorga el permiso para GetParameterHistory, este puede ver el parámetro actual, incluidos los parámetros SecureString, mediante GetParameterHistory.
El mismo comportamiento se aplica a la eliminación. ssm:DeleteParameters se autoriza de forma independiente de ssm:DeleteParameter, por lo que denegar únicamente ssm:DeleteParameter no impide que una entidad principal elimine el parámetro con la operación DeleteParameters. Niegue ambas acciones o utilice el patrón ssm:DeleteParameter*.
Cifrado y descifrado de parámetros mediante claves de AWS KMS
Los parámetros SecureString del Parameter Store utilizan claves de AWS KMS para el cifrado. AWS KMS cifra el valor mediante una Clave administrada de AWS o una clave administrada por el cliente. Para obtener más información acerca de AWS KMS y AWS KMS key, consulte Guía para desarrolladores de AWS Key Management Service.
Todos los usuarios de la cuenta de cliente tienen acceso a la clave administrada de AWS predeterminada. Puede localizar el Nombre de recurso de Amazon (ARN) de la clave predeterminada en la consola de AWS KMS de la página Claves administradas de AWSaws/ssm en la columna Alias. Es posible que desee utilizar la clave predeterminada para cifrar los parámetros SecureString mientras impide que los usuarios trabajen con los parámetros SecureString. En este caso, las políticas de IAM deben denegar explícitamente el acceso a la clave predeterminada, como se muestra en el siguiente ejemplo de política.
Cuando se utiliza una clave administrada por el cliente, la política de IAM que concede a una entidad principal acceso a un parámetro o una ruta de parámetro debe proporcionar permisos kms:Encrypt explícitos para la clave. Por ejemplo, la siguiente política permite a una entidad principal crear, actualizar y ver parámetros SecureString que comienzan por prod- en la Región de AWS y la Cuenta de AWS especificadas.
nota
El permiso kms:GenerateDataKey es necesario para crear parámetros avanzados cifrados utilizando la clave administrada por el cliente especificada.
Si necesita un control de acceso detallado sobre los parámetros SecureString de su cuenta, utilice una clave administrada por el cliente para proteger y restringir el acceso a estos parámetros. También se recomienda utilizar AWS CloudTrail para supervisar las actividades de los parámetros SecureString.
Para obtener más información, consulte los temas siguientes:
-
Policy evaluation logic (Lógica de evaluación de políticas) en la Guía del usuario de IAM
-
Uso de las políticas de claves en AWS KMS en la Guía para desarrolladores de AWS Key Management Service
-
Visualización de eventos con el historial de eventos de CloudTrail en la Guía del usuario de AWS CloudTrail
Permiso para que los nodos administrados accedan a parámetros específicos
Para controlar qué parámetros del Parameter Store puede recuperar un nodo administrado, puede adjuntar una política de IAM al rol de la instancia. Si elige el tipo de parámetro SecureString cuando crea el parámetro, Systems Manager utiliza AWS KMS para cifrar el valor del parámetro. Puede ver la Clave administrada de AWS ejecutando el siguiente comando desde la AWS CLI.
aws kms describe-key --key-id alias/aws/ssm
El siguiente ejemplo permite que los nodos obtengan un valor de parámetro solo para los parámetros que comienzan con prod-. Si el parámetro es un parámetro de SecureString, el nodo descifra la cadena mediante AWS KMS.
nota
Las políticas de instancia, como las del ejemplo siguiente, se asignan a el rol de la instancia en IAM. Para obtener más información acerca de cómo configurar el acceso a las características de Systems Manager, incluido el modo de asignar políticas a los usuarios y las instancias, consulte Administrar instancias de EC2 con Systems Manager.
