Identity and Access Management en Amazon OpenSearch Service

Amazon OpenSearch Service ofrece varias maneras de controlar el acceso a sus 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.

Tipos de políticas

OpenSearch Service 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). Entre los subrecursos se incluyen los índices y las API de OpenSearch. 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:

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 en OpenSearch Service, la políticas basadas en identidad se adjuntan a usuarios o roles mediante el servicio de 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. Normalmente, solo determinan las acciones de la API de configuración que un usuario puede realizar. Después de poner en vigor estas políticas, puede utilizar políticas basadas en recursos (o control de acceso detallado) en OpenSearch Service para ofrecer a los usuarios acceso a los índices y las API de OpenSearch.

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 completo a OpenSearch Service y 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"
        ]
      }
    }
  }]
}

Ahora puede utilizar etiquetas para controlar el acceso a la API de OpenSearch. Las políticas basadas en etiquetas para la API de OpenSearch solo se aplican a los métodos HTTP. Por ejemplo, la siguiente política permite a las entidades principales adjuntas enviar solicitudes GET y PUT a la API de OpenSearch si el dominio tiene la etiqueta environment:production:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Action": [
      "es:ESHttpGet",
      "es:ESHttpPut"
    ],
    "Effect": "Allow",
    "Resource": "*",
    "Condition": {
      "ForAnyValue:StringEquals": {
        "aws:ResourceTag/environment": [
          "production"
        ]
      }
    }
  }]
}

Para tener un control más detallado de la API de OpenSearch, considere utilizar el control de acceso detallado.

OpenSearch Service admite las claves de condición globales RequestTag y TagKeys para la API de configuración, pero no para la API de 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 atractivo principal de las políticas basadas en IP es que permiten solicitudes sin firmar en un dominio de OpenSearch Service, 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 OpenSearch servicio desde los paneles.

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/*"
  }]
}

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:

Por ejemplo, si una política basada en recursos concede acceso a un subrecurso del dominio (una API o índice de OpenSearch), pero una política basada en identidad deniega el acceso, se denegará 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.

Referencia de los elementos de las políticas

OpenSearch Service admite la mayoría de los elementos de las políticas de la Referencia de los elementos de políticas de IAM, a excepción de NotPrincipal. La siguiente tabla muestra los elementos más comunes.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "es:ESHttpGet",
        "es:DescribeDomain"
      ],
      "Resource": "*"
    }
  ]
}

"Condition": {
  "IpAddress": {
    "aws:SourceIp": [
      "192.0.2.0/32"
    ]
  }
}

Opciones avanzadas y consideraciones de la API

OpenSearch Service tiene varias opciones avanzadas, una de las cuales tiene implicaciones sobre 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 a test-user acceso completo a test-index y la API bulk de OpenSearch. 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. Como OpenSearch Service utiliza direcciones URL para controlar el acceso a subrecursos de dominio, test-user puede, de hecho, utilizar la API bulk para realizar cambios en 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 Dashboards depende en gran medida de mget y msearch, por lo que es improbable trabajar 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/*"
    }
  ]
}

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 operaciones de OpenSearch individuales, consulte Control de acceso detallado en Amazon OpenSearch Service.

Configurar políticas de acceso

Políticas de muestra adicionales

Aunque este capítulo incluye muchas políticas de muestra, el control de acceso de AWS es un tema complejo que se entiende mejor a través de ejemplos. Para más información, consulte Ejemplos de políticas de IAM basadas en identidad en la Guía del usuario de IAM.