Accès au DAX sur plusieurs comptes AWS - Amazon DynamoDB
Configurer IAMConfiguration d’un VPCModifier le client DAX pour autoriser l’accès intercompte

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Accès au DAX sur plusieurs comptes AWS

Imaginez que vous avez un cluster DynamoDB Accelerator (DAX) exécuté sur AWS un compte (compte A) et que le cluster DAX doit être accessible depuis une instance Amazon Elastic Compute Cloud (Amazon EC2) d'un autre compte (compte B). AWS Dans ce didacticiel, vous pouvez accomplir cela en lançant une instance EC2 dans le compte B avec un rôle IAM du compte B. Vous utilisez ensuite des informations d’identification de sécurité temporaires de l’instance EC2 pour endosser un rôle IAM du compte A. Enfin, vous utilisez les informations d’identification de sécurité temporaires afin d’endosser le rôle IAM dans le compte A pour effectuer des appels d’application via une connexion d’appairage de VPC Amazon sur le cluster DAX dans le compte A. Pour effectuer ces tâches, vous devez disposer d’un accès administratif dans les deux comptes AWS .

Important

Il n’est pas possible de faire accéder un cluster DAX à une table DynamoDB d’un autre compte.

Configurer IAM

  1. Créez un fichier texte nommé AssumeDaxRoleTrust.json avec le contenu suivant pour permettre à Amazon EC2 de travailler pour vous.

    JSON
    {
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "ec2.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

  2. Dans le compte B, créez un rôle qu’Amazon EC2 peut utiliser lors du lancement d’instances.

    aws iam create-role \
    --role-name AssumeDaxRole \
    --assume-role-policy-document file://AssumeDaxRoleTrust.json

  3. Créez un fichier texte nommé AssumeDaxRolePolicy.json avec le contenu suivant, qui permet au code exécuté sur l'instance EC2 du compte B d'assumer un rôle IAM dans le compte A. Remplacez-le accountA par l'identifiant réel du compte A.

    JSON
    {
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::111122223333:role/DaxCrossAccountRole"
        }
    ]
}

  4. Ajoutez cette stratégie au rôle que vous venez de créer.

    aws iam put-role-policy \
    --role-name AssumeDaxRole \
    --policy-name AssumeDaxRolePolicy \
    --policy-document file://AssumeDaxRolePolicy.json

  5. Créez un profil d’instance pour autoriser les instances à utiliser le rôle.

    aws iam create-instance-profile \
    --instance-profile-name AssumeDaxInstanceProfile

  6. Associez le rôle au profil d’instance.

    aws iam add-role-to-instance-profile \
    --instance-profile-name AssumeDaxInstanceProfile \
    --role-name AssumeDaxRole

  7. Créez un fichier texte nommé DaxCrossAccountRoleTrust.json avec le contenu suivant, ce qui permet au compte B d’assumer un rôle du compte A. Remplacez accountB par l'identifiant réel du compte B.

    JSON
    {
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::111122223333:role/AssumeDaxRole"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

  8. Dans le compte A, créez le rôle que le compte B peut assumer.

    aws iam create-role \
    --role-name DaxCrossAccountRole \
    --assume-role-policy-document file://DaxCrossAccountRoleTrust.json

  9. Créez un fichier texte nommé DaxCrossAccountPolicy.json permettant l’accès au cluster DAX. dax-cluster-arnRemplacez-le par le nom de ressource Amazon (ARN) correct de votre cluster DAX.

    JSON
    {
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "dax:GetItem",
                "dax:BatchGetItem",
                "dax:Query",
                "dax:Scan",
                "dax:PutItem",
                "dax:UpdateItem",
                "dax:DeleteItem",
                "dax:BatchWriteItem",
                "dax:ConditionCheckItem"
            ],
            "Resource": "arn:aws:dax:us-east-1:111122223333:cache/dax-cluster-name"
        }
    ]
}

  10. Dans le compte A, ajoutez la stratégie au rôle.

    aws iam put-role-policy \
    --role-name DaxCrossAccountRole \
    --policy-name DaxCrossAccountPolicy \
    --policy-document file://DaxCrossAccountPolicy.json

Configuration d’un VPC

  1. Recherchez le groupe de sous-réseaux du cluster DAX du compte A. cluster-nameRemplacez-le par le nom du cluster DAX auquel le compte B doit accéder.

    aws dax describe-clusters \
    --cluster-name cluster-name
    --query 'Clusters[0].SubnetGroup'

  2. À l'aide de celasubnet-group, trouvez le VPC du cluster.

    aws dax describe-subnet-groups \
    --subnet-group-name subnet-group \
    --query 'SubnetGroups[0].VpcId'

  3. À l'aide de celavpc-id, trouvez le CIDR du VPC.

    aws ec2 describe-vpcs \
    --vpc vpc-id \
    --query 'Vpcs[0].CidrBlock'

  4. À partir du compte B, créez un VPC à l’aide d’un CIDR sans chevauchement différent de celui trouvé à l’étape précédente. Ensuite, créez au moins un sous-réseau. Vous pouvez utiliser l'assistant de création de VPC dans le AWS Management Console ou le. AWS CLI

  5. À partir du compte B, demandez une connexion d’appairage au VPC du compte A, comme décrit dans Création et acceptation d’une connexion d’appairage de VPC. À partir du compte A, acceptez la connexion.

  6. Dans le compte B, recherchez la table de routage du nouveau VPC. Remplacez vpc-id par l'ID du VPC que vous avez créé dans le compte B.

    aws ec2 describe-route-tables \
    --filters 'Name=vpc-id,Values=vpc-id' \
    --query 'RouteTables[0].RouteTableId'

  7. Ajoutez une route pour envoyer le trafic destiné au CIDR du compte A à la connexion d’appairage du VPC. N'oubliez pas de user input placeholder remplacer chacune par les valeurs correctes pour vos comptes.

    aws ec2 create-route \
    --route-table-id accountB-route-table-id \
    --destination-cidr accountA-vpc-cidr \
    --vpc-peering-connection-id peering-connection-id

  8. À partir du compte A, recherchez la table de routage du cluster DAX à l'aide de celle vpc-id que vous avez trouvée précédemment.

    aws ec2 describe-route-tables \
    --filters 'Name=vpc-id, Values=accountA-vpc-id' \
    --query 'RouteTables[0].RouteTableId'

  9. À partir du compte A, ajoutez une route pour envoyer le trafic destiné au CIDR du compte B à la connexion d’appairage du VPC. Remplacez chacune user input placeholder par les valeurs correctes pour vos comptes.

    aws ec2 create-route \
    --route-table-id accountA-route-table-id \
    --destination-cidr accountB-vpc-cidr \
    --vpc-peering-connection-id peering-connection-id

  10. À partir du compte B, lancez une instance EC2 dans le VPC que vous avez créé précédemment. Attribuez-lui AssumeDaxInstanceProfile. Vous pouvez utiliser l'assistant de lancement dans le AWS Management Console ou le AWS CLI. Notez le groupe de sécurité de l’instance.

  11. Dans le compte A, recherchez le groupe de sécurité qu’utilise le cluster DAX. N'oubliez pas de cluster-name remplacer par le nom de votre cluster DAX.

    aws dax describe-clusters \
    --cluster-name cluster-name \
    --query 'Clusters[0].SecurityGroups[0].SecurityGroupIdentifier'

  12. Mettez à jour le groupe de sécurité du cluster DAX pour autoriser le trafic entrant en provenance du groupe de sécurité de l'instance EC2 que vous avez créée dans le compte B. N'oubliez pas de user input placeholders remplacer le par les valeurs correctes pour vos comptes.

    aws ec2 authorize-security-group-ingress \
    --group-id accountA-security-group-id \
    --protocol tcp \
    --port 8111 \
    --source-group accountB-security-group-id \
    --group-owner accountB-id

À ce stade, une application sur l’instance EC2 du compte B peut utiliser le profil d’instance pour endosser le rôle arn:aws:iam::accountA-id:role/DaxCrossAccountRole et utiliser le cluster DAX.

Modifier le client DAX pour autoriser l’accès intercompte

Note

AWS Security Token Service (AWS STS) les informations d'identification sont des informations d'identification temporaires. Certains clients gèrent l’actualisation automatiquement, tandis que d’autres nécessitent une logique supplémentaire pour actualiser les informations d’identification. Nous vous recommandons de suivre les instructions de la documentation appropriée.

Java

Cette section vous aide à modifier votre code client DAX existant pour autoriser l’accès DAX entre comptes. Si vous n’avez pas encore de code client DAX, vous pouvez trouver des exemples de codes fonctionnels dans le didacticiel Java et DAX.

  1. Ajoutez les importations suivantes.

    import com.amazonaws.auth.STSAssumeRoleSessionCredentialsProvider;
import com.amazonaws.services.securitytoken.AWSSecurityTokenService;
import com.amazonaws.services.securitytoken.AWSSecurityTokenServiceClientBuilder;

  2. Obtenez un fournisseur d'informations d'identification AWS STS et créez-en un objet client DAX. N'oubliez pas de user input placeholder remplacer chacune par les valeurs correctes pour vos comptes.

    AWSSecurityTokenService awsSecurityTokenService = AWSSecurityTokenServiceClientBuilder
     .standard()
     .withRegion(region)
     .build();

STSAssumeRoleSessionCredentialsProvider credentials =  new STSAssumeRoleSessionCredentialsProvider.Builder("arn:aws:iam::accountA:role/RoleName", "TryDax")
     .withStsClient(awsSecurityTokenService)
     .build();

DynamoDB client = AmazonDaxClientBuilder.standard()
    .withRegion(region)
    .withEndpointConfiguration(dax_endpoint)
    .withCredentials(credentials)
    .build();
.NET

Cette section vous aide à modifier votre code client DAX existant pour autoriser l’accès DAX entre comptes. Si vous n’avez pas encore de code client DAX, vous pouvez trouver des exemples de codes fonctionnels dans le didacticiel .NET et DAX.

  1. Ajoutez le AWSSDK. SecurityToken NuGet empaqueter vers la solution.

    <PackageReference Include="AWSSDK.SecurityToken" Version="latest version" />

  2. Utilisez les packages SecurityToken et SecurityToken.Model.

    using Amazon.SecurityToken;
using Amazon.SecurityToken.Model;

  3. Obtenez des informations d’identification temporaires auprès de AmazonSimpleTokenService et créez un objet ClusterDaxClient. N'oubliez pas de user input placeholder remplacer chacune par les valeurs correctes pour vos comptes.

    IAmazonSecurityTokenService sts = new AmazonSecurityTokenServiceClient();

var assumeRoleResponse = sts.AssumeRole(new AssumeRoleRequest
{
    RoleArn = "arn:aws:iam::accountA:role/RoleName",
                RoleSessionName = "TryDax"
});

Credentials credentials = assumeRoleResponse.Credentials;

var clientConfig = new DaxClientConfig(dax_endpoint, port)
{
    AwsCredentials = assumeRoleResponse.Credentials
                   
};

var client = new ClusterDaxClient(clientConfig);
Go

Cette section vous aide à modifier votre code client DAX existant pour autoriser l’accès DAX entre comptes. Si vous n'avez pas encore de code client DAX, vous pouvez trouver des exemples de code fonctionnel sur GitHub.

  1. Importez les packages de session AWS STS et.

    import (
    "github.com/aws/aws-sdk-go/aws/session"
    "github.com/aws/aws-sdk-go/service/sts"
    "github.com/aws/aws-sdk-go/aws/credentials/stscreds"
)

  2. Obtenez des informations d’identification temporaires auprès de AmazonSimpleTokenService et créez un objet client DAX. N'oubliez pas de user input placeholder remplacer chacune par les valeurs correctes pour vos comptes.

    sess, err := session.NewSession(&aws.Config{
    Region: aws.String(region)},
)
if err != nil {
    return nil, err
}

stsClient := sts.New(sess)
arp := &stscreds.AssumeRoleProvider{
                Duration:     900 * time.Second,
                ExpiryWindow: 10 * time.Second,
                RoleARN:      "arn:aws:iam::accountA:role/role_name",
                Client:       stsClient,
                RoleSessionName: "session_name",
        }cfg := dax.DefaultConfig()

cfg.HostPorts = []string{dax_endpoint}
cfg.Region = region
cfg.Credentials = credentials.NewCredentials(arp)
daxClient := dax.New(cfg)
Python

Cette section vous aide à modifier votre code client DAX existant pour autoriser l’accès DAX entre comptes. Si vous n’avez pas encore de code client DAX, vous pouvez trouver des exemples de codes fonctionnels dans le didacticiel Python et DAX.

  1. Importez boto3.

    import boto3

  2. Obtenez des informations d’identification temporaires auprès de sts et créez un objet AmazonDaxClient. N'oubliez pas de user input placeholder remplacer chacune par les valeurs correctes pour vos comptes.

    sts = boto3.client('sts')
stsresponse = sts.assume_role(RoleArn='arn:aws:iam::accountA:role/RoleName',RoleSessionName='tryDax')
credentials = botocore.session.get_session()['Credentials']

dax = amazondax.AmazonDaxClient(session, region_name=region, endpoints=[dax_endpoint], aws_access_key_id=credentials['AccessKeyId'], aws_secret_access_key=credentials['SecretAccessKey'], aws_session_token=credentials['SessionToken'])
client = dax
Node.js

Cette section vous aide à modifier votre code client DAX existant pour autoriser l’accès DAX entre comptes. Si vous n’avez pas encore de code client DAX, vous pouvez trouver des exemples de codes fonctionnels dans le didacticiel Node.js et DAX. N'oubliez pas de user input placeholder remplacer chacune par les valeurs correctes pour vos comptes.

const AmazonDaxClient = require('amazon-dax-client');
const AWS = require('aws-sdk');
const region = 'region';
const endpoints = [daxEndpoint1, ...];

const getCredentials = async() => {
  return new Promise((resolve, reject) => {
    const sts = new AWS.STS();
    const roleParams = {
      RoleArn: 'arn:aws:iam::accountA:role/RoleName',
      RoleSessionName: 'tryDax',
    };
    sts.assumeRole(roleParams, (err, session) => {
      if(err) {
        reject(err);
      } else {
        resolve({
          accessKeyId: session.Credentials.AccessKeyId,
          secretAccessKey: session.Credentials.SecretAccessKey,
          sessionToken: session.Credentials.SessionToken,
        });
      }
    });
  });
};

const createDaxClient = async() => {
  const credentials = await getCredentials();
  const daxClient = new AmazonDaxClient({endpoints: endpoints, region: region, accessKeyId: credentials.accessKeyId, secretAccessKey: credentials.secretAccessKey, sessionToken: credentials.sessionToken});
  return new AWS.DynamoDB.DocumentClient({service: daxClient});
};

createDaxClient().then((client) => {
  client.get(...);
  ...
}).catch((error) => {
  console.log('Caught an error: ' + error);
});