As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Identity and Access Management no Amazon OpenSearch Service
O Amazon OpenSearch Service oferece várias maneiras de controlar o acesso aos seus domínios. Esta seção aborda os diversos tipos de políticas, como elass interagem entre si e como você pode criar suas próprias políticas personalizadas.
Importante
VPCO suporte introduz algumas considerações adicionais sobre o controle de acesso ao OpenSearch serviço. Para obter mais informações, consulte Sobre políticas de acesso em VPC domínios.
Tipos de políticas
OpenSearch O serviço oferece suporte a três tipos de políticas de acesso:
Políticas baseadas no recurso
Quando um domínio é criado, uma política baseada em recurso é adicionada, muitas vezes chamada de política de acesso ao domínio. Essas políticas especificam que ações uma entidade principal pode executar nos sub-recursos do domínio (com exceção da pesquisa entre clusters). Os sub-recursos incluem OpenSearch índices e. APIs O elemento Principal especifica as contas, os usuários ou as funções com acesso permitido. O elemento Resource especifica quais sub-recursos essas entidades principais podem acessar.
Por exemplo, a política baseada em recurso a seguir concede ao test-user
(es:*
) acesso total aos sub-recursos em 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/*" } ] }
Duas considerações importantes se aplicam a essa política:
-
Esses privilégios se aplicam apenas a esse domínio. A menos que você crie políticas semelhantes em outros domínios,
test-user
só poderá acessartest-domain
. -
O terminador
/*
no elementoResource
é significativo e indica que as políticas baseadas em recursos só se aplicam aos sub-recursos do domínio, e não ao próprio domínio. Em políticas baseadas em recursos, a açãoes:*
é equivalente aes:ESHttp*
.Por exemplo, o
test-user
pode fazer solicitações em relação a um índice (GET https://search-test-domain.us-west-1.es.amazonaws.com/test-index
), mas não pode atualizar a configuração do domínio (POST https://es.us-west-1.amazonaws.com/2021-01-01/opensearch/domain/test-domain/config
). Observe a diferença entre os dois endpoints. O acesso à configuração API requer uma política baseada em identidade.
Você pode especificar um nome de índice parcial adicionando um curinga. Este exemplo identifica todos os índices que começam com commerce
:
arn:aws:es:us-west-1:987654321098:domain/test-domain/commerce*
Nesse caso, o curinga significa que o test-user
pode fazer solicitações para índices em test-domain
que tenham nomes que comecem com commerce
.
Para restringir ainda mais o test-user
, você pode aplicar a seguinte 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" } ] }
Agora, o test-user
só pode executar uma operação: pesquisar no índice commerce-data
. Todos os outros índices no domínio estão inacessíveis, e sem permissões para usar as ações es:ESHttpPut
ou es:ESHttpPost
, o test-user
não pode adicionar ou modificar documentos.
Em seguida, você pode optar por configurar uma função para usuários avançados. Essa política dá power-user-role
acesso aos PUT métodos HTTP GET e para todos URIs no í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/*" } ] }
Se seu domínio estiver em um VPC ou usar um controle de acesso refinado, você poderá usar uma política de acesso de domínio aberto. Caso contrário, sua diretiva de acesso ao domínio deverá conter alguma restrição, seja por endereço IP ou principal.
Para obter informações sobre todas as ações disponíveis, consulte Referência de elementos da política. Para obter um controle muito mais granular sobre seus dados, use uma política de acesso a domínio aberto com controle de acesso refinado.
Políticas baseadas em identidade
Ao contrário das políticas baseadas em recursos, que fazem parte de cada domínio do OpenSearch Serviço, você anexa políticas baseadas em identidade aos usuários ou funções usando o AWS Identity and Access Management serviço (). IAM Assim como nas políticas baseadas em recursos, as políticas baseadas em identidade especificam quem pode acessar um serviço, quais ações podem ser executadas e, se aplicável, em quais recursos essas ações podem ser executadas.
As políticas baseadas em identidade tendem a ser mais genéricas, embora não exista essa exigência. Eles geralmente controlam somente as API ações de configuração que um usuário pode realizar. Depois de implementar essas políticas, você pode usar políticas baseadas em recursos (ou controle de acesso refinado) no OpenSearch Service para oferecer aos usuários acesso a índices e. OpenSearch APIs
nota
Os usuários com a AmazonOpenSearchServiceReadOnlyAccess
política AWS gerenciada não conseguem ver o status de integridade do cluster no console. Para permitir que eles vejam o status de integridade do cluster (e outros OpenSearch dados), adicione a es:ESHttpGet
ação a uma política de acesso e anexe-a às suas contas ou funções.
Como as políticas baseadas em identidade são vinculadas a usuários ou funções (diretores), elas JSON não especificam um diretor. A política a seguir concede acesso a ações que começam com Describe
e List
. Essa combinação de ações fornece acesso somente leitura a configurações de domínio, mas não aos dados armazenados no próprio domínio:
{ "Version": "2012-10-17", "Statement": [ { "Action": [ "es:Describe*", "es:List*" ], "Effect": "Allow", "Resource": "*" } ] }
Um administrador pode ter acesso total ao OpenSearch Serviço e a todos os dados armazenados em todos os domínios:
{ "Version": "2012-10-17", "Statement": [ { "Action": [ "es:*" ], "Effect": "Allow", "Resource": "*" } ] }
As políticas baseadas em identidade permitem que você use tags para controlar o acesso à configuração. API A seguinte política, por exemplo, permitirá que os principais anexados visualizem e atualizem a configuração de um domínio se o domínio tiver a tag team:devops
:
{ "Version": "2012-10-17", "Statement": [{ "Action": [ "es:UpdateDomainConfig", "es:DescribeDomain", "es:DescribeDomainConfig" ], "Effect": "Allow", "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "aws:ResourceTag/team": [ "devops" ] } } }] }
Você também pode usar tags para controlar o acesso ao OpenSearch API. As políticas baseadas em tags OpenSearch API só se aplicam aos HTTP métodos. Por exemplo, a política a seguir permite que os diretores anexados enviem GET e PUT solicitem OpenSearch API se o domínio tiver a environment:production
tag:
{ "Version": "2012-10-17", "Statement": [{ "Action": [ "es:ESHttpGet", "es:ESHttpPut" ], "Effect": "Allow", "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "aws:ResourceTag/environment": [ "production" ] } } }] }
Para um controle mais granular do OpenSearch API, considere usar um controle de acesso refinado.
nota
Depois de adicionar uma ou mais OpenSearch APIs políticas baseadas em tags, você deve realizar uma única operação de tag (como adicionar, remover ou modificar uma tag) para que as alterações entrem em vigor em um domínio. Você deve usar o software de serviço R20211203 ou posterior para incluir OpenSearch API operações em políticas baseadas em tags.
OpenSearch O serviço suporta as chaves de condição TagKeys
globais RequestTag
e as chaves de condição para a configuraçãoAPI, não OpenSearch API o. Essas condições se aplicam somente às API chamadas que incluem tags na solicitaçãoCreateDomain
, comoAddTags
, RemoveTags
e. A política a seguir permite que os principais anexados criem domínios, mas somente se incluírem a tag team:it
na solicitação:
{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "es:CreateDomain", "es:AddTags" ], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/team": [ "it" ] } } } }
Políticas baseadas em IP
As políticas baseadas em IP restringem o acesso a um domínio a um ou mais endereços IP ou CIDR blocos. Tecnicamente, as políticas baseadas em IP não são um tipo de política diferente. Na verdade, elas são apenas políticas baseadas em recursos que especificam uma entidade principal anônima e incluem um elemento Condition especial.
O principal atrativo das políticas baseadas em IP é que elas permitem solicitações não assinadas a um domínio de OpenSearch serviço, o que permite usar clientes como curl
nota
Se você habilitou o VPC acesso ao seu domínio, não poderá configurar uma política baseada em IP. Em vez disso, você poderá usar grupos de segurança para controlar quais endereços IP poderão acessar o domínio. Para obter mais informações, consulte Sobre políticas de acesso em VPC domínios.
A política a seguir concede acesso a todas as HTTP solicitações originadas do intervalo 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/*" } ] }
Se seu domínio tem um endpoint público e não usa controle de acesso refinado, recomendamos combinar endereços IAM principais e IP. Essa política concede test-user
HTTP acesso somente se a solicitação for originada do intervalo 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/*" }] }
Fazendo e assinando solicitações OpenSearch de serviço
Mesmo se você configurar uma política de acesso totalmente aberta baseada em recursos, todas as solicitações para a configuração do OpenSearch Serviço API devem ser assinadas. Se suas políticas especificarem IAM funções ou usuários, as solicitações para o OpenSearch APIs também deverão ser assinadas usando o AWS Signature Version 4. O método de assinatura difere emAPI:
-
Para fazer chamadas para a configuração do OpenSearch ServiçoAPI, recomendamos que você use um dos AWS SDKs
. SDKsIsso simplifica muito o processo e pode economizar uma quantidade significativa de tempo em comparação com a criação e assinatura de suas próprias solicitações. Os API endpoints de configuração usam o seguinte formato: es.
region
.amazonaws.com/2021-01-01/Por exemplo, a seguinte solicitação faz uma alteração de configuração no domínio
movies
, mas é necessário que você a assine (não recomendado):POST https://es.
us-east-1
.amazonaws.com/2021-01-01/opensearch/domain/movies
/config { "ClusterConfig": { "InstanceType": "c5.xlarge.search" } }Se você usar um dosSDKs, como o Boto 3
, o manipula SDK automaticamente a assinatura da solicitação: import boto3 client = boto3.client(es) response = client.update_domain_config( DomainName='
movies
', ClusterConfig={ 'InstanceType': 'c5.xlarge.search' } )Para obter um código de exemplo Java, consulte Uso de AWS SDKs para interagir com o Amazon OpenSearch Service.
-
Para fazer chamadas para o OpenSearch APIs, você deve assinar suas próprias solicitações. OpenSearch APIsUse o seguinte formato:
domain-id
.region
.es.amazonaws.com.rproxy.goskope.comPor exemplo, a seguinte solicitação procura o índice
movies
para thor:GET https://
my-domain
.us-east-1
.es.amazonaws.com/movies/_search?q=thor
nota
O serviço ignora os parâmetros passados URLs para HTTP POST solicitações assinadas com o Signature Version 4.
Quando há colisão de políticas
Quando as políticas discordam entre si ou não fazem nenhuma referência explícita a um usuário, surgem complexidades. Entender como IAM funciona o Guia IAM do Usuário fornece um resumo conciso da lógica de avaliação de políticas:
-
Por padrão, todas as solicitações são negadas.
-
Uma permissão explícita substitui esse padrão.
-
Uma negar explícito substitui todas as permissões.
Por exemplo, se uma política baseada em recursos conceder acesso a um sub-recurso de domínio (um OpenSearch índice ouAPI), mas uma política baseada em identidade negar seu acesso, você terá acesso negado. Se uma política baseada em identidade concede acesso e uma política baseada em recursos não especifica se você deve ou não ter acesso, esse acesso é concedido. Consulte a tabela a seguir com o cruzamento de políticas para obter um resumo completo dos resultados para sub-recursos de domínios.
Permitido na política baseada em recursos | Negado na política baseada em recursos | Nem permitido nem negado na política baseada em recursos | |
---|---|---|---|
Allowed in identity-based policy |
Permitir |
Deny | Permitir |
Denied in identity-based policy | Deny | Deny | Deny |
Neither allowed nor denied in identity-based policy | Permitir | Deny | Deny |
Referência de elementos da política
OpenSearch O serviço oferece suporte à maioria dos elementos de IAMpolítica na Referência de Elementos de Política, com exceção deNotPrincipal
. A tabela a seguir mostra os elementos mais comuns.
JSONelemento político | Resumo |
---|---|
Version |
Versão atual da linguagem de política é |
Effect |
Esse elemento especifica se a declaração permite ou nega o acesso às ações especificadas. Os valores válidos são |
Principal |
Esse elemento especifica a IAM função Conta da AWS ou o usuário que tem acesso permitido ou negado a um recurso e pode assumir várias formas:
ImportanteEspecificar o
|
Action
|
OpenSearch O serviço usa Determinadas ações Para obter uma lista de todas as ações disponíveis e se elas se aplicam aos sub-recursos do domínio ( Embora as permissões no nível de recurso para Naturalmente, nada impede que você inclua ações juntamente com elementos de recursos menos restritivos, como estes:
Para saber mais sobre o emparelhamento de ações e recursos, consulte o elemento |
Condition |
OpenSearch O serviço oferece suporte à maioria das condições descritas nas chaves de contexto de condição AWS global no Guia IAM do usuário. Exceções notáveis incluem a Ao configurar uma política baseada em IP, você especifica os endereços IP ou o CIDR bloco como uma condição, como a seguinte:
Conforme observado em Políticas baseadas em identidade |
Resource |
OpenSearch O serviço usa
Para obter detalhes sobre quais ações dão suporte a permissões no nível do recurso, consulte o elemento |
Opções e API considerações avançadas
OpenSearch O serviço tem várias opções avançadas, uma das quais tem implicações de controle de acesso:rest.action.multi.allow_explicit_index
. Como sua configuração padrão é verdadeiro, ela permite que os usuários ignorem as permissões de sub-recursos em determinadas circunstâncias.
Por exemplo, considere a seguinte política baseada em recurso:
{ "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/*" } ] }
Essa política concede acesso test-user
total test-index
e OpenSearch em massaAPI. Ela também permite solicitações GET
ao restricted-index
.
A seguinte solicitação de indexação, como você pode esperar, falha devido a um erro de permissão:
PUT https://search-test-domain.us-west-1.es.amazonaws.com/restricted-index/movie/1 { "title": "Your Name", "director": "Makoto Shinkai", "year": "2016" }
Ao contrário do índiceAPI, o volume API permite criar, atualizar e excluir vários documentos em uma única chamada. No entanto, você geralmente especifica essas operações no corpo da solicitação, e não na solicitaçãoURL. Como o OpenSearch Service usa URLs para controlar o acesso aos sub-recursos do domínio, test-user
pode, na verdade, usar a massa API para fazer alterações em. restricted-index
Embora o usuário não tenha permissões POST
no índice, a seguinte solicitação é bem-sucedida:
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" }
Nesta situação, a política de acesso não consegue cumprir o que pretendia. Para evitar que os usuários ignorem esses tipos de restrições, você pode alterar o rest.action.multi.allow_explicit_index
para o valor falso. Se esse valor for falso, todas as chamadas para bulk, mget e msearch APIs que especificam nomes de índice no corpo da solicitação deixarão de funcionar. Em outras palavras, as chamadas para _bulk
não funcionam mais, mas as chamadas para o test-index/_bulk
funcionam. Este segundo endpoint contém um nome de índice, portanto, você não precisa especificar um no corpo da solicitação.
OpenSearch Os painéis dependem muito de mget e msearch, portanto, é improvável que funcionem corretamente após essa alteração. Para remediação parcial, você pode deixar rest.action.multi.allow_explicit_index
como verdadeiro e negar a determinados usuários o acesso a um ou mais delesAPIs.
Para obter informações sobre como alterar essa configuração, consulte Configurações avançadas do cluster.
Da mesma forma, a seguinte política baseada em recursos contém dois problemas sutis:
{ "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/*" } ] }
-
Apesar da negação explícita, o
test-user
ainda pode fazer chamadas, comoGET https://search-test-domain.us-west-1.es.amazonaws.com/_all/_search
eGET https://search-test-domain.us-west-1.es.amazonaws.com/*/_search
para acessar os documentos norestricted-index
. -
Como o elemento
Resource
faz referência aorestricted-index/*
, otest-user
não tem permissões para acessar diretamente os documentos do índice. O usuário, no entanto, tem permissões para excluir todo o índice. Para evitar o acesso e a exclusão, a política deve especificarrestricted-index*
.
Em vez de misturar permissões amplas e negações focadas, a abordagem mais segura é seguir o princípio do privilégio mínimo e conceder apenas as permissões necessárias para executar uma tarefa. Para obter mais informações sobre como controlar o acesso a índices ou OpenSearch operações individuais, consulteControle de acesso refinado no Amazon Service OpenSearch .
Importante
Especificar o caractere curinga * permite acesso anônimo ao seu domínio. Não é recomendável usar o caractere curinga. Além disso, inspecione cuidadosamente as seguintes políticas para confirmar se elas não concedem amplo acesso:
-
Políticas baseadas em identidade vinculadas aos AWS diretores associados (por exemplo, funções) IAM
-
Políticas baseadas em recursos anexadas aos AWS recursos associados (por exemplo, AWS Key Management Service KMS chaves)
Configuração de políticas de acesso
-
Para obter instruções sobre como criar ou modificar políticas baseadas em recursos e IP no OpenSearch Service, consulte. Configuração de políticas de acesso
-
Para obter instruções sobre como criar ou modificar políticas baseadas em identidade emIAM, consulte Criação de IAM políticas no Guia do IAM usuário.
Exemplos adicionais de políticas
Embora este capítulo inclua muitos exemplos de políticas, o controle de AWS acesso é um assunto complexo que é melhor compreendido por meio de exemplos. Para obter mais informações, consulte Exemplos de políticas IAM baseadas em identidade no Guia do IAMusuário.