Como configurar o acesso entre contas para o Amazon Keyspaces sem uma VPC compartilhada - Amazon Keyspaces (para Apache Cassandra)

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á.

Como configurar o acesso entre contas para o Amazon Keyspaces sem uma VPC compartilhada

Se a tabela do Amazon Keyspaces e o endpoint privado da VPC pertencerem a contas diferentes, mas não estiverem compartilhando uma VPC, os aplicativos ainda poderão se conectar entre contas usando endpoints da VPC. Como as contas não estão compartilhando os endpoints da VPC, Account A, Account B e Account C exigem seus próprios endpoints da VPC. Para o driver do cliente Cassandra, o Amazon Keyspaces aparece como um único nó em vez de um cluster de vários nós. Após a conexão, o driver do cliente chega ao servidor DNS, que retorna um dos endpoints disponíveis na VPC da conta.

Você também pode acessar tabelas do Amazon Keyspaces em contas diferentes sem um VPC endpoint compartilhado usando os endpoints públicos ou implantando um endpoint VPC privado em cada conta. Quando não está usando uma VPC compartilhada, cada conta exige seu próprio endpoint da VPC. Neste exemplo, Account A, Account B e Account C exigem seus próprios endpoints da VPC para acessar a tabela em Account A. Ao usar endpoints da VPC nessa configuração, o Amazon Keyspaces aparece como um cluster de nó único para o driver do cliente Cassandra em vez de um cluster de vários nós. Após a conexão, o driver do cliente chega ao servidor DNS, que retorna um dos endpoints disponíveis na VPC da conta. Mas o driver do cliente não consegue acessar a tabela system.peers para descobrir endpoints adicionais. Como há menos hosts disponíveis, o driver faz menos conexões. Para ajustar isso, aumente a configuração do pool de conexões do driver em um fator de três.

Diagrama mostrando três contas diferentes pertencentes à mesma organização, na mesma Região da AWS sem uma VPC compartilhada.

Account Aé a conta que contém os recursos (uma tabela do Amazon Keyspaces) que Account B Account C você precisa acessar, assim como Account A a conta confiável. Account Be Account C são as contas com os diretores que precisam acessar os recursos (uma tabela do Amazon Keyspaces)Account A, ou Account B seja, Account C as contas confiáveis. A conta confiável concede as permissões às contas confiáveis compartilhando um perfil do IAM. O procedimento a seguir descreve as etapas de configuração necessárias em Account A.

Configuração para a Account A
  1. Crie um keyspace do Amazon Keyspaces e insira uma tabela. Account A

  2. Crie uma função do IAM Account A que tenha acesso total à tabela Amazon Keyspaces e acesso de leitura às tabelas do sistema Amazon Keyspaces.

    { "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action":[ "cassandra:Select", "cassandra:Modify" ], "Resource":[ "arn:aws:cassandra:region:Account-A:/keyspace/mykeyspace/table/mytable", "arn:aws:cassandra:region:Account-A:/keyspace/system*" ] } ] }
  3. Configure uma política de confiança para a função do IAM em Account A para que os diretores Account C possam assumir a função como contas confiáveis. Account B Isso é mostrado no exemplo a seguir.

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::AccountB:role/Cross-Account-Role-B", "AWS": "arn:aws:iam::AccountC:role/Cross-Account-Role-C" }, "Action": "sts:AssumeRole", "Condition": {} } ] }

    Para ver mais informações sobre as políticas do IAM entre contas, consulte Políticas entre contas no Guia do usuário do IAM.

  4. Configure o VPC endpoint Account A e anexe permissões ao endpoint que permitem que as funções de Account B e assumam Account C a função no uso Account A do VPC endpoint. Essas permissões são válidas para o VPC endpoint ao qual elas estão conectadas. Para obter mais informações sobre as políticas de endpoint da VPC, consulte Como controlar o acesso aos endpoints da VPC de interface para o Amazon Keyspaces.

    { "Version": "2012-10-17", "Statement": [ { "Sid": "Allow-access-from-specific-IAM-roles", "Effect": "Allow", "Principal": "*", "Action": "cassandra:*", "Resource": "*", "Condition": { "ArnEquals": { "aws:PrincipalArn": "arn:aws:iam::AccountB:role/Cross-Account-Role-B", "aws:PrincipalArn": "arn:aws:iam::AccountC:role/Cross-Account-Role-C" } } } ] }
Configuração em Account B e Account C
  1. Em Account B e Account C, crie novos perfis e anexe a seguinte política que permite que a entidade principal assuma o perfil compartilhado criado em Account A.

    { "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::Account-A:role/keyspaces_access" } }

    Permitir que o diretor assuma a função compartilhada é implementado usando a AssumeRole API do AWS Security Token Service (AWS STS). Para obter mais informações, consulte Fornecer acesso a um usuário do IAM em outro Conta da AWS de sua propriedade no Guia do usuário do IAM.

  2. Em Account B eAccount C, você pode criar aplicativos que utilizam o plug-in de SIGV4 autenticação, que permite que um aplicativo assuma a função compartilhada para se conectar à tabela Amazon Keyspaces localizada em. Account A Para obter mais informações sobre o plug-in de SIGV4 autenticação, consulteCrie credenciais para acesso programático ao Amazon Keyspaces . Para obter mais informações sobre como configurar um aplicativo para assumir uma função em outra AWS conta, consulte Autenticação e acesso no AWS SDKs Guia de referência de ferramentas.