AWS Kontenübergreifender Zugriff auf DAX - Amazon DynamoDB

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

AWS Kontenübergreifender Zugriff auf DAX

Stellen Sie sich vor, Sie haben einen DynamoDB Accelerator (DAX) -Cluster, der in einem AWS Konto (Konto A) läuft, und der DAX-Cluster muss von einer Amazon Elastic Compute Cloud (Amazon EC2) -Instance in einem anderen AWS Konto (Konto B) aus zugänglich sein. In diesem Tutorial erreichen Sie dies, indem Sie eine EC2-Instance in Konto B mit einer IAM-Rolle in Konto B starten. Anschließend verwenden Sie temporäre Sicherheitsanmeldeinformationen von der EC2-Instance, um eine IAM-Rolle in Konto A zu übernehmen. Schließlich verwenden Sie die temporären Sicherheitsanmeldeinformationen von der übernommenen IAM-Rolle in Konto A, um Anwendungsaufrufe über eine VPC-Peering-Verbindung an den DAX-Cluster in Konto A auszugeben. Um diese Aufgaben ausführen zu können, benötigen Sie Administratorzugriff in beiden AWS Konten.

Wichtig

Es ist nicht möglich, dass ein DAX-Cluster von einem anderen Konto aus auf eine DynamoDB-Tabelle zugreift.

IAM-einrichten

  1. Erstellen Sie die Textdatei AssumeDaxRoleTrust.json mit dem folgenden Inhalt, der es Amazon EC2 ermöglicht, in Ihrem Auftrag zu arbeiten.

    JSON
    { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }
  2. Erstellen Sie in Konto B eine Rolle, die von Amazon EC2 beim Starten von Instances verwendet werden kann.

    aws iam create-role \ --role-name AssumeDaxRole \ --assume-role-policy-document file://AssumeDaxRoleTrust.json
  3. Erstellen Sie eine Textdatei AssumeDaxRolePolicy.json mit dem folgenden Inhalt, die es Code ermöglicht, der auf der EC2-Instance in Konto B ausgeführt wird, eine IAM-Rolle in Konto A anzunehmen. accountA Ersetzen Sie sie durch die tatsächliche ID von Konto A.

    JSON
    { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::111122223333:role/DaxCrossAccountRole" } ] }
  4. Fügen Sie diese Richtlinie der gerade erstellten Rolle hinzu.

    aws iam put-role-policy \ --role-name AssumeDaxRole \ --policy-name AssumeDaxRolePolicy \ --policy-document file://AssumeDaxRolePolicy.json
  5. Erstellen Sie ein Instance-Profil, damit Instances die Rolle verwenden können.

    aws iam create-instance-profile \ --instance-profile-name AssumeDaxInstanceProfile
  6. Ordnen Sie die Rolle dem Instance-Profil zu.

    aws iam add-role-to-instance-profile \ --instance-profile-name AssumeDaxInstanceProfile \ --role-name AssumeDaxRole
  7. Erstellen Sie die Textdatei DaxCrossAccountRoleTrust.json mit dem folgenden Inhalt, der es Konto B gestattet, eine Rolle von Kontos A zu übernehmen. accountBDurch die tatsächliche ID von Konto B ersetzen.

    JSON
    { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:role/AssumeDaxRole" }, "Action": "sts:AssumeRole" } ] }
  8. Erstellen Sie in Konto A die Rolle, die Konto B übernehmen kann.

    aws iam create-role \ --role-name DaxCrossAccountRole \ --assume-role-policy-document file://DaxCrossAccountRoleTrust.json
  9. Erstellen Sie eine Textdatei mit dem Namen DaxCrossAccountPolicy.json, die den Zugriff auf den DAX-Cluster ermöglicht. dax-cluster-arnErsetzen Sie es durch den richtigen Amazon-Ressourcennamen (ARN) Ihres DAX-Clusters.

    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. Fügen Sie in Konto A die Richtlinie zur Rolle hinzu.

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

Einrichten einer VPC

  1. Suchen Sie die Subnetzgruppe des DAX-Clusters von Konto A. cluster-nameErsetzen Sie es durch den Namen des DAX-Clusters, auf den Konto B zugreifen muss.

    aws dax describe-clusters \ --cluster-name cluster-name --query 'Clusters[0].SubnetGroup'
  2. Suchen Sie damit subnet-group die VPC des Clusters.

    aws dax describe-subnet-groups \ --subnet-group-name subnet-group \ --query 'SubnetGroups[0].VpcId'
  3. Suchen Sie damit vpc-id den CIDR der VPC.

    aws ec2 describe-vpcs \ --vpc vpc-id \ --query 'Vpcs[0].CidrBlock'
  4. Erstellen Sie in Konto B eine VPC mit einer anderen, nicht überlappenden CIDR als der, die im im vorherigen Schritt gefunden wurde. Erstellen Sie dann mindestens ein Subnetz. Sie können entweder den VPC-Erstellungsassistenten in AWS-Managementkonsole oder in verwenden. AWS CLI

  5. Fordern Sie in Konto B eine Peering-Verbindung mit der VPC von Konto A an, wie unter Erstellen und Akzeptieren einer VPC-Peering-Verbindung beschrieben. Akzeptieren Sie die Verbindung in Konto A.

  6. Suchen Sie in Konto B die Routingtabelle der neuen VPC. vpc-idErsetzen Sie durch die ID der VPC, die Sie in Konto B erstellt haben.

    aws ec2 describe-route-tables \ --filters 'Name=vpc-id,Values=vpc-id' \ --query 'RouteTables[0].RouteTableId'
  7. Fügen Sie eine Route hinzu, um Datenverkehr für die CIDR von Konto A an die VPC-Peering-Verbindung zu senden. Denken Sie daran, jeden Wert user input placeholder durch die richtigen Werte für Ihre Konten zu ersetzen.

    aws ec2 create-route \ --route-table-id accountB-route-table-id \ --destination-cidr accountA-vpc-cidr \ --vpc-peering-connection-id peering-connection-id
  8. Suchen Sie von Konto A aus nach der Routing-Tabelle des DAX-Clusters, indem vpc-id Sie die zuvor gefundene Tabelle verwenden.

    aws ec2 describe-route-tables \ --filters 'Name=vpc-id, Values=accountA-vpc-id' \ --query 'RouteTables[0].RouteTableId'
  9. Fügen Sie in Konto A eine Route hinzu, um Datenverkehr für die CIDR von Konto B an die VPC-Peering-Verbindung zu senden. Ersetzen Sie jeden user input placeholder Wert durch die richtigen Werte für Ihre Konten.

    aws ec2 create-route \ --route-table-id accountA-route-table-id \ --destination-cidr accountB-vpc-cidr \ --vpc-peering-connection-id peering-connection-id
  10. Starten Sie in Konto B eine EC2-Instance in der zuvor von Ihnen erstellten VPC. Ordnen Sie ihr das AssumeDaxInstanceProfile zu. Sie können entweder den Startassistenten im AWS-Managementkonsole oder im verwenden AWS CLI. Notieren Sie sich die Sicherheitsgruppe der Instance.

  11. Suchen Sie in Konto A die Sicherheitsgruppe, die vom DAX-Cluster verwendet wird. Denken Sie daran, es cluster-name durch den Namen Ihres DAX-Clusters zu ersetzen.

    aws dax describe-clusters \ --cluster-name cluster-name \ --query 'Clusters[0].SecurityGroups[0].SecurityGroupIdentifier'
  12. Aktualisieren Sie die Sicherheitsgruppe des DAX-Clusters, um eingehenden Datenverkehr von der Sicherheitsgruppe der EC2-Instance zuzulassen, die Sie in Konto B erstellt haben. Denken Sie daran, die durch die user input placeholders richtigen Werte für Ihre Konten zu ersetzen.

    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

An dieser Stelle kann eine Anwendung auf der EC2-Instance von Konto B mithilfe des Instance-Profils die Rolle arn:aws:iam::accountA-id:role/DaxCrossAccountRole übernehmen und den DAX-Cluster nutzen.

Ändern des DAX-Clients, um den kontoübergreifenden Zugriff zu erlauben

Anmerkung

AWS -Security-Token-Service (AWS STS) Anmeldeinformationen sind temporäre Anmeldeinformationen. Einige Clients nehmen automatisch Aktualisierungen vor, während andere zusätzliche Logik benötigen, um die Anmeldeinformationen zu aktualisieren. Wir empfehlen Ihnen, die Anleitung der entsprechenden Dokumentation zu befolgen.

Java

Dieser Abschnitt unterstützt Sie beim Ändern Ihres vorhandenen DAX-Clientcodes, um kontoübergreifenden DAX-Zugriff zu ermöglichen. Wenn Sie noch keinen DAX-Clientcode haben, finden Sie Beispiele von funktionierendem Code im Tutorial Java und DAX.

  1. Fügen Sie die folgenden Importe hinzu.

    import com.amazonaws.auth.STSAssumeRoleSessionCredentialsProvider; import com.amazonaws.services.securitytoken.AWSSecurityTokenService; import com.amazonaws.services.securitytoken.AWSSecurityTokenServiceClientBuilder;
  2. Rufen Sie einen Anbieter für Anmeldeinformationen von ab AWS STS und erstellen Sie ein DAX-Client-Objekt. Denken Sie daran, jeden Wert user input placeholder durch die richtigen Werte für Ihre Konten zu ersetzen.

    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

Dieser Abschnitt unterstützt Sie beim Ändern Ihres vorhandenen DAX-Clientcodes, um kontoübergreifenden DAX-Zugriff zu ermöglichen. Wenn Sie noch keinen DAX-Clientcode haben, finden Sie Beispiele von funktionierendem Code im Tutorial .NET und DAX.

  1. Füge das hinzu AWSSDK. SecurityToken NuGet Paket zur Lösung.

    <PackageReference Include="AWSSDK.SecurityToken" Version="latest version" />
  2. Verwenden Sie die Pakete SecurityToken und SecurityToken.Model.

    using Amazon.SecurityToken; using Amazon.SecurityToken.Model;
  3. Fordern Sie temporäre Anmeldeinformationen von AmazonSimpleTokenService an und erstellen Sie ein ClusterDaxClient-Objekt. Denken Sie daran, jeden Wert user input placeholder durch die richtigen Werte für Ihre Konten zu ersetzen.

    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

Dieser Abschnitt unterstützt Sie beim Ändern Ihres vorhandenen DAX-Clientcodes, um kontoübergreifenden DAX-Zugriff zu ermöglichen. Falls Sie noch keinen DAX-Client-Code haben, finden Sie funktionierende Codebeispiele unter GitHub.

  1. Importieren Sie die Pakete AWS STS und die Sitzungspakete.

    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. Fordern Sie temporäre Anmeldeinformationen von AmazonSimpleTokenService an und erstellen Sie ein DAX-Clientobjekt. Denken Sie daran, jeden Wert user input placeholder durch die richtigen Werte für Ihre Konten zu ersetzen.

    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

Dieser Abschnitt unterstützt Sie beim Ändern Ihres vorhandenen DAX-Clientcodes, um kontoübergreifenden DAX-Zugriff zu ermöglichen. Wenn Sie noch keinen DAX-Clientcode haben, finden Sie Beispiele von funktionierendem Code im Tutorial Python und DAX.

  1. Importieren Sie boto3.

    import boto3
  2. Fordern Sie temporäre Anmeldeinformationen von sts an und erstellen Sie ein AmazonDaxClient-Objekt. Denken Sie daran, jeden Wert user input placeholder durch die richtigen Werte für Ihre Konten zu ersetzen.

    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

Dieser Abschnitt unterstützt Sie beim Ändern Ihres vorhandenen DAX-Clientcodes, um kontoübergreifenden DAX-Zugriff zu ermöglichen. Wenn Sie noch keinen DAX-Clientcode haben, finden Sie Beispiele von funktionierendem Code im Tutorial Node.js und DAX. Denken Sie daran, jeden Wert user input placeholder durch die richtigen Werte für Ihre Konten zu ersetzen.

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); });