Tipos de políticas Realizar y firmar solicitudes de servicio OpenSearch Cuando las políticas chocan Referencia de los elementos de las políticas Opciones avanzadas y consideraciones de la API Configurar políticas de acceso Políticas de muestra adicionales

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

La compatibilidad con VPC introduce algunas consideraciones adicionales en el control de acceso al OpenSearch servicio. Para obtener más información, consulte Acerca de las políticas de acceso en los dominios de VPC.

Tipos de políticas

OpenSearch El servicio admite tres tipos de políticas de acceso:

Políticas basadas en recursos
Políticas basadas en identidad
Políticas basadas en IP

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 API. 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 a test-domain.
El /* final en el elemento Resource 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ón es:* es equivalente a es: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 API de configuración requiere una política basada en 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 concede a power-user-role acceso a los métodos HTTP GET y PUT para todos los URI del í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 el dominio se encuentra en una VPC o utiliza un control de acceso detallado, puede utilizar una política de acceso al dominio abierto. 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, las políticas basadas en la identidad se asocian a los usuarios o roles que utilizan el servicio (IAM). AWS Identity and Access Management 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. Normalmente, solo determinan las acciones de la API 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 Service para ofrecer a los usuarios acceso a los índices y las OpenSearch API. OpenSearch

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.

Dado que las políticas basadas en identidad se adjuntan a usuarios o roles (entidades principales), el JSON no especifica 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 identidad permiten utilizar etiquetas para controlar el acceso a la API de configuración. 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 puedes usar etiquetas para controlar el acceso a la OpenSearch API. Las políticas basadas en etiquetas para la OpenSearch API solo se aplican a los métodos HTTP. Por ejemplo, la siguiente política permite a los directores adjuntos enviar solicitudes GET y PUT a la 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 de la OpenSearch API, considera la posibilidad de utilizar un control de acceso más detallado.

nota

Tras añadir una o más OpenSearch API a cualquier política basada 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 las operaciones de la OpenSearch API 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 API de configuración, no de la API. OpenSearch Estas condiciones solo se aplican a las llamadas a la API que incluyen etiquetas dentro de la solicitud, como CreateDomain, AddTags y RemoveTags. 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"
        ]
      }
    }
  }
}

Para conocer más detalles sobre la utilización de etiquetas para el control de acceso y las diferencias entre las políticas basadas en recursos y las políticas basadas en identidad, consulte la Guía del usuario de IAM.

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 de 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 y OpenSearch Dashboards o acceder al dominio a través de un servidor proxy. Para más información, consulte Uso de un proxy para acceder al servicio desde los paneles OpenSearch OpenSearch .

nota

Si ha habilitado acceso VPC para su dominio, no puede 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 más información, consulte Acerca de las políticas de acceso en los dominios de VPC.

La siguiente política concede a todas las solicitudes HTTP que se originan en el intervalo de IP especificado acceso a test-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 su dominio tiene un punto de conexión público y no utiliza un control de acceso detallado, recomendamos combinar direcciones IP y entidades principales de IAM. Esta política concede acceso HTTP test-user únicamente si la solicitud se origina en el intervalo 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 de servicio OpenSearch

Incluso si configura una política de acceso completamente abierta y basada en recursos, todas las solicitudes a la API de configuración del OpenSearch servicio deben estar firmadas. Si sus políticas especifican funciones o usuarios de IAM, las solicitudes a las OpenSearch API también deben firmarse con la versión 4 de AWS Signature. El método de firma difiere en función de la API:

Para realizar llamadas a la API OpenSearch de configuración del servicio, le recomendamos que utilice uno de los AWS SDK. Los SDK simplifican en gran medida el proceso y pueden ahorrar mucho tiempo en comparación con la creación y firma de sus propias solicitudes. Los puntos de enlace de la API 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 los SDK como Boto 3, el SDK se encarga automáticamente de la firma de solicitudes:
```
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 a las OpenSearch API, debes firmar tus propias solicitudes. Las OpenSearch API utilizan el siguiente formato:
```
domain-id.region.es.amazonaws.com
```
Por 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 pasados en las direcciones URL de las solicitudes HTTP POST firmadas con Signature Version 4.

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. Entender cómo funciona IAM en la Guía del usuario de IAM ofrece un breve resumen 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 o una API), 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 es compatible con la mayoría de los elementos de política de la Referencia de elementos de política de IAM, con la excepción de. NotPrincipal La siguiente tabla muestra los elementos más comunes.

Elemento de política JSON	Resumen
`Version`	La versión actual del idioma de la política es `2012-10-17`. Todas las políticas de acceso deben especificar este valor.
`Effect`	Este elemento especifica si la instrucción permite o deniega el acceso a las acciones especificadas. Los valores válidos son `Allow` o `Deny`.
`Principal`	Este elemento especifica el rol Cuenta de AWS o el usuario de IAM al que se le permite o deniega el acceso a un recurso y puede adoptar varias formas: AWS cuentas: `"Principal":{"AWS": ["123456789012"]}` o `"Principal":{"AWS": ["arn:aws:iam::123456789012:root"]}` Usuarios de IAM: `"Principal":{"AWS": ["arn:aws:iam::123456789012:user/test-user"]}` Roles de IAM: `"Principal":{"AWS": ["arn:aws:iam::123456789012:role/test-role"]}` importante Especificar el comodín `*` habilita el acceso anónimo al dominio, lo que no se recomienda a menos que agregue una condición basada en IP, utilice la compatibilidad con la VPC o habilite un control de acceso detallado. Además, inspeccione cuidadosamente las siguientes políticas para confirmar que no otorgan un acceso amplio: Políticas basadas en identidad asociadas a las entidades principales de AWS vinculadas (por ejemplo, los roles de IAM) Políticas basadas en recursos asociadas a AWS los recursos asociados (por ejemplo, las claves de AWS Key Management Service KMS)
`Action`	OpenSearch El servicio usa `ESHttp` acciones para los métodos OpenSearch HTTP. El resto de las acciones se aplican a la API de configuración. Determinadas acciones `es:` admiten permisos de nivel de recursos. Por ejemplo, puede otorgar a un usuario permisos para eliminar un dominio particular sin dar a dicho usuario permisos para eliminar cualquier* dominio. Otras acciones se aplican solo al propio servicio. Por ejemplo, `es:ListDomainNames` no tiene sentido en el contexto de un dominio único y, por lo tanto, requiere un comodín. Para obtener una lista de todas las acciones disponibles y saber si se aplican a los subrecursos del dominio (`test-domain/`), a la configuración del dominio (`test-domain`) o solo al servicio (``), consulte Acciones, recursos y claves de condición de Amazon OpenSearch Service en la Referencia de autorización de servicios Las políticas basadas en recursos difieren de los permisos en el nivel de recursos. Las políticas basadas en recursos son políticas JSON completas que se adjuntan a dominios. Los permisos de nivel de recurso permiten restringir acciones a dominios o subrecursos particulares. En la práctica, puede pensar en permisos de nivel de recursos como parte opcional de una política basada en recursos o identidades. Aunque los permisos de nivel de recurso para `es:CreateDomain` puedan parecer poco intuitivos (después de todo, ¿por qué darle a un usuario permisos para crear un dominio que ya existe?), la utilización de un comodín permite aplicar un esquema de nomenclatura sencillo para sus dominios, por ejemplo `"Resource": "arn:aws:es:us-west-1:987654321098:domain/my-team-name-"`. Por supuesto, nada impide que incluya acciones junto a elementos de recursos menos restrictivos, como las siguientes: `{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "es:ESHttpGet", "es:DescribeDomain" ], "Resource": "" } ] }` Para obtener más información acerca de las acciones y recursos de emparejamiento, consulte el elemento `Resource` en esta tabla.
`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 usuario de IAM. Entre las excepciones más destacables se incluye la `aws:PrincipalTag` clave, que el OpenSearch servicio no admite. Al configurar una política basada en IP, debe especificar las direcciones IP o bloque de CIDR como condición, como en el ejemplo siguiente: `"Condition": { "IpAddress": { "aws:SourceIp": [ "192.0.2.0/32" ] } }` Como se indica en Políticas basadas en identidad `aws:ResourceTagaws:RequestTag`, las claves de `aws:TagKeys` condición y las claves de condición se aplican tanto a la API de configuración como a las OpenSearch API.
`Resource`	OpenSearch El servicio utiliza `Resource` los elementos de tres formas básicas: Para las acciones que se aplican al propio OpenSearch Servicio, por ejemplo`es:ListDomainNames`, o para permitir el acceso total, utilice la siguiente sintaxis: `"Resource": ""` Para las acciones que implican la configuración de un dominio, como `es:DescribeDomain`, puede utilizar la siguiente sintaxis: `"Resource": "arn:aws:es:region:aws-account-id:domain/domain-name"` Para las acciones que se aplican a los subrecursos de un dominio, como `es:ESHttpGet`, puede utilizar la siguiente sintaxis: `"Resource": "arn:aws:es:region:aws-account-id:domain/domain-name/"` No es necesario utilizar un comodín. OpenSearch El servicio le permite definir una política de acceso diferente para cada OpenSearch índice o API. Por ejemplo, podría limitar los permisos de un usuario al índice `test-index`: `"Resource": "arn:aws:es:region:aws-account-id:domain/domain-name/test-index"` En lugar de acceso completo a `test-index`, quizá prefiera limitar la política a solo la API de búsqueda: `"Resource": "arn:aws:es:region:aws-account-id:domain/domain-name/test-index/_search"` Incluso puede controlar el acceso a documentos individuales: `"Resource": "arn:aws:es:region:aws-account-id:domain/domain-name/test-index/test-type/1"` Básicamente, si OpenSearch expresa el subrecurso como un URI, puede controlar el acceso a él mediante una política de acceso. Para obtener un mayor control sobre los recursos a los que puede obtener acceso un usuario, consulte Control de acceso detallado en Amazon Service OpenSearch . Para conocer detalles sobre qué acciones admiten los permisos en el nivel de recursos, consulte el elemento `Action` en esta tabla.

Opciones avanzadas y consideraciones de la API

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 completo a la API OpenSearch masiva test-index y a la misma. 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 de la API index, la API bulk permite crear, actualizar y eliminar muchos documentos en una única llamada. Sin embargo, con frecuencia especifica estas operaciones en el cuerpo de la solicitud, en lugar de la URL de solicitud. Dado que OpenSearch Service utiliza las URL para controlar el acceso a los subrecursos del dominio, test-user puede, de hecho, utilizar la API masiva para realizar cambios en ellas. 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, todas las llamadas a las API bulk, mget y msearch que especifican nombres de índice en el cuerpo de la solicitud dejan de funcionar. 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. Como remedio parcial, puede dejar rest.action.multi.allow_explicit_index como verdadero y denegar a determinados usuarios el acceso a una o varias de estas API.

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 y GET https://search-test-domain.us-west-1.es.amazonaws.com/*/_search para acceder a los documentos en restricted-index.
Dado que el elemento Resource hace referencia a restricted-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 lugar restricted-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 de IAM)
Políticas basadas en recursos asociadas a los AWS recursos asociados (por ejemplo, claves de KMS) AWS Key Management Service

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 la creación o modificación de políticas basadas en identidad en IAM, consulte Crear políticas de IAM en la Guía del usuario de IAM.

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 más información, consulte Ejemplos de políticas de IAM basadas en identidad en la Guía del usuario de IAM.

Aviso JavaScript está desactivado o no está disponible en su navegador.

Para utilizar la documentación de AWS, debe estar habilitado JavaScript. Para obtener más información, consulte las páginas de ayuda de su navegador.

Convenciones del documento

Sin ode-to-node cifrado

Referencia de permisos de la API