Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Identity and Access Management en Amazon OpenSearch Service
Amazon OpenSearch Service ofrece varias formas de controlar el acceso a tus dominios. En este tema, se tratan los diversos tipos de política, la forma en que interactúan entre sí y cómo crear sus propias políticas personalizadas.
importante
VPCEl soporte introduce algunas consideraciones adicionales en relación con el control OpenSearch de acceso al servicio. Para obtener más información, consulte Acerca de las políticas de acceso a VPC los dominios.
Tipos de políticas
OpenSearch El servicio admite tres tipos de políticas de acceso:
Políticas basadas en recursos
Al crear un dominio, agrega una política basada en recursos, a veces denominada política de acceso al dominio. Estas políticas especifican qué acciones puede realizar una entidad principal en los subrecursos del dominio (con la excepción de la búsqueda entre clústeres). Los subrecursos incluyen OpenSearch índices y. APIs El elemento Entidad principal especifica las cuentas, los usuarios o los roles que tienen permitido el acceso. El elemento Recurso especifica los subrecursos a los que pueden obtener acceso estos elementos principales.
Por ejemplo, la siguiente política basada en recursos concede a test-user
acceso completo (es:*
) a los subrecursos en test-domain
:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:user/test-user" ] }, "Action": [ "es:*" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*" } ] }
Dos consideraciones importantes se aplican a esta política:
-
Estos privilegios se aplican únicamente a este dominio. A menos que cree políticas similares en otros dominios,
test-user
solo puede acceder atest-domain
. -
El
/*
final en el elementoResource
es significativo e indica que las políticas basadas en recursos solo se aplican a los subrecursos del dominio, no al propio dominio. En las políticas basadas en recursos, la acciónes:*
es equivalente aes:ESHttp*
.Por ejemplo,
test-user
puede realizar solicitudes frente a un índice (GET https://search-test-domain.us-west-1.es.amazonaws.com/test-index
), pero no puede actualizar la configuración del dominio (POST https://es.us-west-1.amazonaws.com/2021-01-01/opensearch/domain/test-domain/config
). Observe la diferencia entre los dos puntos de conexión. El acceso a la configuración API requiere una política basada en la identidad.
Puede especificar un nombre de índice parcial agregando un comodín. Este ejemplo identifica cualquier índice que empiecen con commerce
:
arn:aws:es:us-west-1:987654321098:domain/test-domain/commerce*
En este caso, el comodín significa que test-user
puede realizar solicitudes a índices dentro de test-domain
que tengan nombres que comiencen con commerce
.
Para restringir aún más test-user
, puede aplicar la siguiente política:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:user/test-user" ] }, "Action": [ "es:ESHttpGet" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/commerce-data/_search" } ] }
Ahora test-user
puede realizar solo una operación: búsquedas del índice commerce-data
. Todos los demás índices del dominio son inaccesibles y, sin permisos para utilizar las acciones es:ESHttpPut
o es:ESHttpPost
, test-user
no puede agregar ni modificar documentos.
A continuación, podría decidir configurar un rol para usuarios avanzados. Esta política da power-user-role
acceso a los PUT métodos HTTP GET y a todos los que figuran URIs en el índice:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:role/power-user-role" ] }, "Action": [ "es:ESHttpGet", "es:ESHttpPut" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/commerce-data/*" } ] }
Si tu dominio pertenece a un control de acceso detallado VPC o lo usa, puedes usar una política de acceso al dominio abierta. De lo contrario, la política de acceso al dominio debe contener alguna restricción, ya sea por entidad principal o dirección IP.
Para obtener información sobre todas las acciones disponibles, consulte Referencia de los elementos de las políticas. Para obtener un control mucho más pormenorizado sobre sus datos, utilice una política de acceso al dominio abierto con control de acceso detallado.
Políticas basadas en identidad
A diferencia de las políticas basadas en recursos, que forman parte de cada dominio de OpenSearch servicio, tú adjuntas políticas basadas en la identidad a los usuarios o roles que utilizan el servicio (). AWS Identity and Access Management IAM Al igual que las políticas basadas en recursos, las políticas basadas en identidad especifican quién puede obtener acceso a un servicio, las acciones que puede realizar y, si corresponde, los recursos en los que se pueden realizar dichas acciones.
Aunque en realidad no tienen por qué serlo, las políticas basadas en identidad suelen ser más genéricas. A menudo, solo rigen las API acciones de configuración que un usuario puede realizar. Una vez implementadas estas políticas, puede usar políticas basadas en recursos (o un control de acceso detallado) en OpenSearch Service para ofrecer a los usuarios acceso a los índices y. OpenSearch APIs
nota
Los usuarios con la AmazonOpenSearchServiceReadOnlyAccess
política AWS gestionada no pueden ver el estado del clúster en la consola. Para que puedan ver el estado del clúster (y otros OpenSearch datos), añada la es:ESHttpGet
acción a una política de acceso y adjúntela a sus cuentas o funciones.
Como las políticas basadas en la identidad se relacionan con los usuarios o las funciones (principales), JSON no especifican una entidad principal. La siguiente política concede acceso a las acciones que comienzan por Describe
y List
. Esta combinación de acciones proporciona acceso de solo lectura a las configuraciones de dominio, pero no a los datos almacenados en el dominio:
{ "Version": "2012-10-17", "Statement": [ { "Action": [ "es:Describe*", "es:List*" ], "Effect": "Allow", "Resource": "*" } ] }
Un administrador puede tener acceso total al OpenSearch Servicio y a todos los datos almacenados en todos los dominios:
{ "Version": "2012-10-17", "Statement": [ { "Action": [ "es:*" ], "Effect": "Allow", "Resource": "*" } ] }
Las políticas basadas en la identidad le permiten usar etiquetas para controlar el acceso a la configuración. API La siguiente política, por ejemplo, permite a las entidades principales adjuntas ver y actualizar la configuración de un dominio si el dominio tiene la etiqueta team:devops
:
{ "Version": "2012-10-17", "Statement": [{ "Action": [ "es:UpdateDomainConfig", "es:DescribeDomain", "es:DescribeDomainConfig" ], "Effect": "Allow", "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "aws:ResourceTag/team": [ "devops" ] } } }] }
También puede usar etiquetas para controlar el acceso a. OpenSearch API Las políticas basadas en etiquetas OpenSearch API solo se aplican a HTTP los métodos. Por ejemplo, la siguiente política permite a los directores adjuntos enviar PUT solicitudes GET y enviar solicitudes OpenSearch API si el dominio tiene la environment:production
etiqueta:
{ "Version": "2012-10-17", "Statement": [{ "Action": [ "es:ESHttpGet", "es:ESHttpPut" ], "Effect": "Allow", "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "aws:ResourceTag/environment": [ "production" ] } } }] }
Para un control más detallado del OpenSearch API, considere la posibilidad de utilizar un control de acceso detallado.
nota
Tras añadir una o varias OpenSearch APIs políticas basadas en etiquetas, debe realizar una sola operación de etiquetado (como añadir, eliminar o modificar una etiqueta) para que los cambios surtan efecto en un dominio. Debe utilizar el software de servicio R20211203 o posterior para incluir OpenSearch API las operaciones en las políticas basadas en etiquetas.
OpenSearch El servicio admite las claves de condición TagKeys
globales RequestTag
y las claves de condición de la configuraciónAPI, no las. OpenSearch API Estas condiciones solo se aplican a las API llamadas que incluyen etiquetas en la solicitudCreateDomain
, comoAddTags
, yRemoveTags
. La siguiente política permite a las entidades principales adjuntas crear dominios, pero solo si incluyen la etiqueta team:it
en la solicitud:
{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "es:CreateDomain", "es:AddTags" ], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/team": [ "it" ] } } } }
Políticas basadas en IP
Las políticas basadas en IP restringen el acceso a un dominio a una o más direcciones IP o bloques. CIDR Técnicamente, las políticas basadas en IP no son un tipo de política distinto. En lugar de ello, son solo políticas basadas en recursos que especifican una entidad principal anónima e incluyen un elemento de Condición especial.
El principal atractivo de las políticas basadas en IP es que permiten realizar solicitudes sin firmar a un dominio de OpenSearch servicio, lo que permite utilizar clientes como curl
nota
Si has habilitado el VPC acceso a tu dominio, no puedes configurar una política basada en IP. En su lugar, puede utilizar grupos de seguridad para controlar qué direcciones IP pueden tener acceso al dominio. Para obtener más información, consulte Acerca de las políticas de acceso a VPC los dominios.
La siguiente política concede acceso a todas HTTP las solicitudes que se originan en el rango de IP especificado atest-domain
:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": [ "es:ESHttp*" ], "Condition": { "IpAddress": { "aws:SourceIp": [ "192.0.2.0/24" ] } }, "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*" } ] }
Si tu dominio tiene un punto final público y no utiliza un control de acceso detallado, te recomendamos combinar las direcciones IP IAM y principales. Esta política concede el test-user
HTTP acceso solo si la solicitud se origina en el rango de IP especificado:
{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::987654321098:user/test-user" ] }, "Action": [ "es:ESHttp*" ], "Condition": { "IpAddress": { "aws:SourceIp": [ "192.0.2.0/24" ] } }, "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*" }] }
Realizar y firmar solicitudes OpenSearch de servicio
Incluso si configura una política de acceso completamente abierta y basada en recursos, todas las solicitudes a la configuración del OpenSearch Servicio API deben estar firmadas. Si sus políticas especifican IAM funciones o usuarios, las solicitudes que se envíen OpenSearch APIs también deben firmarse mediante la versión 4 de AWS Signature. El método de firma se diferencia en los API siguientes aspectos:
-
Para realizar llamadas a la configuración del OpenSearch servicioAPI, le recomendamos que utilice una de las AWS SDKs
. Esto simplifica SDKs enormemente el proceso y puede ahorrarle una cantidad significativa de tiempo en comparación con la creación y firma de sus propias solicitudes. Los API puntos finales de configuración utilizan el siguiente formato: es.
region
.amazonaws.com/2021-01-01/Por ejemplo, la siguiente solicitud introduce un cambio de configuración en el dominio
movies
, pero es preciso identificarse (no recomendado):POST https://es.
us-east-1
.amazonaws.com/2021-01-01/opensearch/domain/movies
/config { "ClusterConfig": { "InstanceType": "c5.xlarge.search" } }Si utiliza uno de ellosSDKs, como Boto 3
, gestiona SDK automáticamente la firma de la solicitud: import boto3 client = boto3.client(es) response = client.update_domain_config( DomainName='
movies
', ClusterConfig={ 'InstanceType': 'c5.xlarge.search' } )Para ver un código de muestra de Java, consulte Utilizar SDK de AWS para interactuar con Amazon OpenSearch Service.
-
Para realizar llamadas al OpenSearch APIs, debes firmar tus propias solicitudes. OpenSearch APIsUtilizan el siguiente formato:
domain-id
.region
.es.amazonaws.comPor ejemplo, la siguiente solicitud busca en el índice
movies
de thor:GET https://
my-domain
.us-east-1
.es.amazonaws.com/movies/_search?q=thor
nota
El servicio ignora los parámetros transferidos a HTTP POST las URLs solicitudes firmadas con la versión 4 de Signature.
Cuando las políticas chocan
Surgen complejidades cuando las políticas están en desacuerdo o no hacen mención explícita a un usuario. Si se explica cómo IAM funciona en la Guía del IAM usuario, se ofrece un resumen conciso de la lógica de evaluación de políticas:
-
De forma predeterminada, se deniegan todas las solicitudes.
-
Un permiso explícito anula esta opción predeterminada.
-
Una denegación explícita anula cualquier permiso concedido.
Por ejemplo, si una política basada en recursos le concede acceso a un subrecurso de dominio (un OpenSearch índice oAPI), pero una política basada en la identidad le niega el acceso, se le deniega el acceso. Si una política basada en identidad concede acceso y una política basada en recursos no especifica si debe tener acceso o no, tiene permitido el acceso. Consulte la siguiente tabla de políticas que se entrecruzan para acceder a un resumen completo de resultados de subrecursos del dominio.
Permitido en política basada en recursos | Denegado en política basada en recursos | Ni permitido ni denegado en política basada en recursos | |
---|---|---|---|
Allowed in identity-based policy |
Permitir |
Denegar | Permitir |
Denied in identity-based policy | Denegar | Denegar | Denegar |
Neither allowed nor denied in identity-based policy | Permitir | Denegar | Denegar |
Referencia de los elementos de las políticas
OpenSearch El servicio admite la mayoría de los elementos de política de la Referencia de elementos IAM de política, con la excepción de. NotPrincipal
La siguiente tabla muestra los elementos más comunes.
JSONelemento de política | Resumen |
---|---|
Version |
La versión actual del idioma de la política es |
Effect |
Este elemento especifica si la instrucción permite o deniega el acceso a las acciones especificadas. Los valores válidos son |
Principal |
Este elemento especifica el IAM rol Cuenta de AWS o el usuario al que se le permite o deniega el acceso a un recurso y puede adoptar varias formas:
importanteAl especificar el
|
Action
|
OpenSearch El servicio usa Determinadas acciones Para obtener una lista de todas las acciones disponibles y saber si se aplican a los subrecursos del dominio ( Aunque los permisos de nivel de recurso para Por supuesto, nada impide que incluya acciones junto a elementos de recursos menos restrictivos, como las siguientes:
Para obtener más información acerca de las acciones y recursos de emparejamiento, consulte el elemento |
Condition |
OpenSearch El servicio admite la mayoría de las condiciones que se describen en las claves de contexto de condiciones AWS globales de la Guía del IAMusuario. Entre las excepciones más destacables se incluye la Al configurar una política basada en IP, se especifican las direcciones IP o el CIDR bloque como condición, por ejemplo:
Como se indica en Políticas basadas en identidad |
Resource |
OpenSearch El servicio utiliza
Para conocer detalles sobre qué acciones admiten los permisos en el nivel de recursos, consulte el elemento |
Opciones y API consideraciones avanzadas
OpenSearch El servicio tiene varias opciones avanzadas, una de las cuales tiene implicaciones en el control de acceso:rest.action.multi.allow_explicit_index
. En su configuración predeterminada como verdadero, permite a los usuarios omitir los permisos de subrecursos en determinadas circunstancias.
Por ejemplo, tomemos la siguiente política basada en recursos:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:user/test-user" ] }, "Action": [ "es:ESHttp*" ], "Resource": [ "arn:aws:es:us-west-1:987654321098:domain/test-domain/test-index/*", "arn:aws:es:us-west-1:987654321098:domain/test-domain/_bulk" ] }, { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:user/test-user" ] }, "Action": [ "es:ESHttpGet" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/restricted-index/*" } ] }
Esta política otorga acceso test-user
total test-index
y OpenSearch masivoAPI. También permite solicitudes GET
a restricted-index
.
La siguiente solicitud de indexación, como cabría esperar, falla debido a un error de permisos:
PUT https://search-test-domain.us-west-1.es.amazonaws.com/restricted-index/movie/1 { "title": "Your Name", "director": "Makoto Shinkai", "year": "2016" }
A diferencia del índiceAPI, el API modo masivo te permite crear, actualizar y eliminar muchos documentos en una sola llamada. Sin embargo, estas operaciones suelen especificarse en el cuerpo de la solicitud y no en la solicitudURL. Como el OpenSearch Servicio se utiliza URLs para controlar el acceso a los subrecursos del dominio, test-user
puede, de hecho, utilizarlos de forma masiva API para realizar cambios en ellos. restricted-index
Aunque el usuario carezca de permisos POST
en el índice, la siguiente solicitud tiene éxito:
POST https://search-test-domain.us-west-1.es.amazonaws.com/_bulk { "index" : { "_index": "restricted-index", "_type" : "movie", "_id" : "1" } } { "title": "Your Name", "director": "Makoto Shinkai", "year": "2016" }
En esta situación, la política de acceso no consigue cumplir su objetivo. Para evitar que los usuarios omitan este tipo de restricciones, puede cambiar rest.action.multi.allow_explicit_index
a falso. Si este valor es falso, dejarán de funcionar todas las llamadas a bulk, mget y msearch APIs que especifiquen nombres de índice en el cuerpo de la solicitud. En otras palabras, las llamadas a _bulk
ya no funcionan, pero las llamadas a test-index/_bulk
sí. Este segundo punto de conexión contiene un nombre de índice, por lo que no es necesario especificar uno en el cuerpo de la solicitud.
OpenSearch Los paneles dependen en gran medida de mget y msearch, por lo que es poco probable que funcionen correctamente después de este cambio. Para una corrección parcial, puede dejar rest.action.multi.allow_explicit_index
como true y denegar a determinados usuarios el acceso a una o más de estas opciones. APIs
Para obtener más información acerca de cómo cambiar esta configuración, consulte Configuración avanzada de clústeres.
Del mismo modo, la siguiente política basada en recursos contiene dos problemas sutiles:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:user/test-user" }, "Action": "es:ESHttp*", "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*" }, { "Effect": "Deny", "Principal": { "AWS": "arn:aws:iam::123456789012:user/test-user" }, "Action": "es:ESHttp*", "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/restricted-index/*" } ] }
-
A pesar de la denegación explícita,
test-user
puede seguir realizando llamadas como, por ejemplo,GET https://search-test-domain.us-west-1.es.amazonaws.com/_all/_search
yGET https://search-test-domain.us-west-1.es.amazonaws.com/*/_search
para acceder a los documentos enrestricted-index
. -
Dado que el elemento
Resource
hace referencia arestricted-index/*
,test-user
no tiene permisos para acceder directamente a los documentos del índice. El usuario, sin embargo, tiene permisos para eliminar todo el índice. Para evitar el acceso y la eliminación, la política debe especificar en su lugarrestricted-index*
.
En lugar de combinar permisos amplios y denegaciones delimitadas, el enfoque más seguro consiste en seguir el principio de privilegio mínimo y conceder solo los permisos requeridos para realizar una tarea. Para obtener más información sobre cómo controlar el acceso a índices u OpenSearch operaciones individuales, consulte. Control de acceso detallado en Amazon Service OpenSearch
importante
Al especificar el comodín *, se permite el acceso anónimo a su dominio. No se recomienda utilizar el comodín. Además, inspeccione detenidamente las siguientes políticas para confirmar que no conceden un acceso amplio:
-
Políticas basadas en la identidad asociadas a los AWS directores asociados (por ejemplo, las funciones) IAM
-
Políticas basadas en recursos adjuntas a los AWS recursos asociados (por ejemplo, claves) AWS Key Management Service KMS
Configurar políticas de acceso
-
Para obtener instrucciones sobre cómo crear o modificar políticas basadas en recursos e IP en OpenSearch Service, consulte. Configurar políticas de acceso
-
Para obtener instrucciones sobre cómo crear o modificar políticas basadas en la identidadIAM, consulte Creación de IAM políticas en la IAM Guía del usuario.
Políticas de muestra adicionales
Si bien este capítulo incluye muchos ejemplos de políticas, el control de AWS acceso es un tema complejo que se entiende mejor con ejemplos. Para obtener más información, consulte Ejemplos de políticas IAM basadas en la identidad en la Guía del IAMusuario.