공유 VPC 없이 Amazon Keyspaces에 대한 교차 계정 액세스 구성 - Amazon Keyspaces(Apache Cassandra용)

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

공유 VPC 없이 Amazon Keyspaces에 대한 교차 계정 액세스 구성

Amazon Keyspaces 테이블과 프라이빗 VPC 엔드포인트를 서로 다른 계정에서 소유하고 있지만 VPC를 공유하지는 않는 경우에도 애플리케이션은 VPC 엔드포인트를 사용하여 크로스 계정을 연결할 수 있습니다. 계정이 VPC 엔드포인트를 공유하지 않으므로 Account A, Account B, Account C에 자체 VPC 엔드포인트가 필요합니다. Cassandra 클라이언트 드라이버에게 Amazon Keyspaces는 다중 노드 클러스터가 아닌 단일 노드처럼 보입니다. 연결 시 클라이언트 드라이버는 DNS 서버에 도달하여 계정의 VPC에서 사용 가능한 엔드포인트 중 하나를 반환합니다.

퍼블릭 엔드포인트를 사용하거나 각 계정에 프라이빗 VPC 엔드포인트를 배포하여 공유 VPC 엔드포인트 없이 여러 계정의 Amazon Keyspaces 테이블에 액세스할 수도 있습니다. 공유 VPC를 사용하지 않는 경우 각 계정에는 자체 VPC 엔드포인트가 필요합니다. 이 예제에서는 Account A, Account B, Account C에 자체 VPC 엔드포인트가 있어야 Account A의 테이블에 액세스할 수 있습니다. 이 구성에서 VPC 엔드포인트를 사용하는 경우 Amazon Keyspaces는 Cassandra 클라이언트 드라이버에 다중 노드 클러스터 대신 단일 노드 클러스터로 나타납니다. 연결 시 클라이언트 드라이버는 DNS 서버에 도달하여 계정의 VPC에서 사용 가능한 엔드포인트 중 하나를 반환합니다. 하지만 클라이언트 드라이버는 system.peers 테이블에 액세스하여 추가 엔드포인트를 검색할 수 없습니다. 사용 가능한 호스트가 적기 때문에 드라이버의 연결 수가 줄어듭니다. 이를 조정하려면 드라이버의 연결 풀 설정을 3배 늘립니다.

공유 VPC가 없는 동일한 AWS 리전 에서 동일한 조직이 소유한 세 개의 계정을 보여주는 다이어그램입니다.

Account A는 Account B 및가 액세스Account C해야 하는 리소스(Amazon Keyspaces 테이블)가 포함된 계정이고, Account A는 신뢰할 수 있는 계정입니다. Account B 및 Account C는의 리소스(Amazon Keyspaces 테이블)에 액세스해야 하는 보안 주체가 있는 계정Account A이므로 Account B 및 Account C는 신뢰할 수 있는 계정입니다. 신뢰하는 계정은 IAM 역할을 공유하여 신뢰 받는 계정에 권한을 부여합니다. 다음 절차에서는 Account A에서 필요한 구성 단계를 간략하게 설명합니다.

Account A에 대한 구성

  1. 에서 Amazon Keyspaces 키스페이스 및 테이블을 생성합니다Account A.

  2. Amazon Keyspaces 테이블에 대한 전체 액세스 권한과 Amazon Keyspaces 시스템 테이블에 대한 읽기 액세스 권한이 Account A 있는에서 IAM 역할을 생성합니다.

    {
   "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. Account B 및의 보안 주체가 역할을 신뢰할 수 있는 계정으로 수임할 Account C 수 Account A 있도록에서 IAM 역할에 대한 신뢰 정책을 구성합니다. 방법은 다음 예제와 같습니다.

    {
    "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": {}
        }
    ]
}

    크로스 계정 IAM 정책에 대한 자세한 내용은 IAM 사용 설명서의 크로스 계정 정책을 참조하세요.

  4. 에서 VPC 엔드포인트를 구성Account A하고의 역할을 허용Account B하고 VPC 엔드포인트를 Account A 사용하여에서 역할을 수임Account C할 수 있는 권한을 엔드포인트에 연결합니다. 이러한 권한은 연결된 VPC 엔드포인트에 유효합니다. VPC 엔드포인트 정책에 대한 자세한 내용은 Amazon Keyspaces의 인터페이스 VPC 엔드포인트에 대한 액세스 제어 섹션을 참조하세요.

    {
   "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"
            }
         }
      }
   ]
}
Account B 및 Account C에서의 구성

  1. Account B및 Account C에서 새 역할을 만들고 Account A에서 생성된 공유 역할을 주체가 맡도록 허용하는 다음 정책을 연결합니다.

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

    보안 주체가 공유 역할을 수임하도록 허용하는 것은 AWS Security Token Service ()의 AssumeRole API를 사용하여 구현됩니다AWS STS. 자세한 내용은 IAM 사용 설명서의 소유한 다른의 IAM 사용자에게 액세스 권한 제공을 참조 AWS 계정 하세요.

  2. Account B 및에서 SIGV4 인증 플러그인을 활용하는 애플리케이션을 생성할 Account C수 있습니다. 그러면 애플리케이션이 공유 역할을 수임하여에 있는 Amazon Keyspaces 테이블에 연결할 수 있습니다Account A. SIGV4에 대한 자세한 내용은 Amazon Keyspaces에 프로그래밍 방식으로 액세스하기 위한 자격 증명 만들기 섹션을 참조하세요. 다른 AWS 계정의 역할을 수임하도록 애플리케이션을 구성하는 방법에 대한 자세한 내용은 SDK 및 도구 참조 안내서의 인증 및 액세스를 참조하세요. AWS SDKs