AWS Glue 자격 증명 기반 정책 예제 - AWS Glue

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

AWS Glue 자격 증명 기반 정책 예제

기본적으로 사용자 및 역할에는 AWS Glue 리소스를 생성하거나 수정할 수 있는 권한이 없습니다. 또한 AWS Management Console, AWS Command Line Interface(AWS CLI) 또는 AWS API를 사용해 작업을 수행할 수 없습니다. 사용자에게 사용자가 필요한 리소스에서 작업을 수행할 권한을 부여하려면 IAM 관리자가 IAM 정책을 생성하면 됩니다. 그런 다음 관리자가 IAM 정책을 역할에 추가하고, 사용자가 역할을 맡을 수 있습니다.

이러한 예제 JSON 정책 문서를 사용하여 IAM ID 기반 정책을 생성하는 방법을 알아보려면 IAM 사용 설명서IAM 정책 생성을 참조하세요.

각 리소스 유형에 대한 ARN 형식을 포함하여 AWS Glue에서 정의한 작업 및 리소스 유형에 대한 자세한 내용은 서비스 승인 참조AWS Glue에 사용되는 작업, 리소스 및 조건 키를 참조하세요.

참고

이 섹션에 제공된 예제는 모두 us-west-2 리전을 사용합니다. 이 리전을 사용하려는 AWS 리전으로 바꿀 수 있습니다.

정책 모범 사례

자격 증명 기반 정책에 따라 계정에서 사용자가 AWS Glue 리소스를 생성, 액세스 또는 삭제할 수 있는지 여부가 결정됩니다. 이 작업으로 인해 AWS 계정에 비용이 발생할 수 있습니다. ID 기반 정책을 생성하거나 편집할 때는 다음 지침과 권장 사항을 따릅니다.

  • AWS 관리형 정책으로 시작하고 최소 권한을 향해 나아가기: 사용자 및 워크로드에 권한 부여를 시작하려면 많은 일반 사용 사례에 대한 권한을 부여하는 AWS 관리형 정책을 사용합니다. 관리형 정책은 AWS 계정에서 사용할 수 있습니다. 사용 사례에 고유한 AWS고객 관리형 정책을 정의하여 권한을 줄이는 것이 좋습니다. 자세한 정보는 IAM 사용 설명서AWS managed policies(관리형 정책) 또는 AWS managed policies for job functions(직무에 대한 관리형 정책) 섹션을 참조하세요.

  • 최소 권한 적용: IAM 정책을 사용하여 권한을 설정하는 경우 태스크를 수행하는 데 필요한 권한만 부여합니다. 이렇게 하려면 최소 권한으로 알려진 특정 조건에서 특정 리소스에 대해 수행할 수 있는 작업을 정의합니다. IAM을 사용하여 권한을 적용하는 방법에 대한 자세한 정보는 IAM 사용 설명서IAM의 정책 및 권한을 참조하세요.

  • IAM 정책의 조건을 사용하여 액세스 추가 제한: 정책에 조건을 추가하여 작업 및 리소스에 대한 액세스를 제한할 수 있습니다. 예를 들어 SSL을 사용하여 모든 요청을 전송해야 한다고 지정하는 정책 조건을 작성할 수 있습니다. 특정 AWS 서비스(예: AWS CloudFormation)을(를) 통해 사용되는 경우에만 서비스 작업에 대한 액세스 권한을 부여할 수도 있습니다. 자세한 정보는 IAM 사용 설명서IAM JSON 정책 요소: 조건을 참조하세요.

  • IAM Access Analyzer를 통해 IAM 정책을 검증하여 안전하고 기능적인 권한 보장 – IAM Access Analyzer에서는 IAM 정책 언어(JSON)와 IAM 모범 사례가 정책에서 준수되도록 신규 및 기존 정책을 검증합니다. IAM Access Analyzer는 100개 이상의 정책 확인 항목과 실행 가능한 권장 사항을 제공하여 안전하고 기능적인 정책을 작성하도록 돕습니다. 자세한 정보는 IAM 사용 설명서IAM Access Analyzer 정책 검증을 참조하세요.

  • 다중 인증(MFA) 필요: AWS 계정 계정에 IAM 사용자 또는 루트 사용자가 필요한 시나리오가 있는 경우 추가 보안을 위해 MFA를 설정합니다. API 작업을 직접적으로 호출할 때 MFA가 필요하면 정책에 MFA 조건을 추가합니다. 자세한 정보는 IAM 사용 설명서 Configuring MFA-protected API access(MFA 보호 API 액세스 구성) 섹션을 참조하세요.

IAM의 모범 사례에 대한 자세한 내용은 IAM 사용 설명서IAM의 보안 모범 사례 섹션을 참조하세요.

리소스 수준 권한은 특정 AWS Glue 객체에만 적용됨

AWS Glue에서 특정 객체에 대한 세분화된 제어만 정의할 수 있습니다. 따라서 Resource 문에 대한 Amazon 리소스 이름(ARN)을 허용하는 API 작업이 ARN을 허용하지 않는 API 작업과 혼합되지 않도록 클라이언트의 IAM 정책을 작성해야 합니다.

예를 들어, 다음 IAM 정책은 GetClassifierGetJobRun에 대한 API 작업을 허용합니다. AWS Glue는 식별자와 작업 실행에 ARN을 허용하지 않기 때문에 이 정책은 Resource*로 정의합니다. ARN은 GetDatabaseGetTable 같은 특정 API 작업에 대해 허용이 되기 때문에 정책의 후반부에서 ARN을 지정할 수 있습니다.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "glue:GetClassifier*", "glue:GetJobRun*" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "glue:Get*" ], "Resource": [ "arn:aws:glue:us-east-1:123456789012:catalog", "arn:aws:glue:us-east-1:123456789012:database/default", "arn:aws:glue:us-east-1:123456789012:table/default/e*1*", "arn:aws:glue:us-east-1:123456789012:connection/connection2" ] } ] }

ARN을 허용하는 AWS Glue 객체 목록은 리소스 ARN 단원을 참조하십시오.

AWS Glue Console에서 사용

AWS Glue Console에 액세스하려면 최소 권한 집합이 있어야 합니다. 이러한 권한은 AWS 계정에서 AWS Glue 리소스에 대한 세부 정보를 나열하고 볼 수 있도록 허용해야 합니다. 최소 필수 권한보다 더 제한적인 자격 증명 기반 정책을 만들면 콘솔이 해당 정책에 연결된 엔터티(사용자 또는 역할)에 대해 의도대로 작동하지 않습니다.

AWS CLI 또는 AWS API만 호출하는 사용자에게 최소 콘솔 권한을 허용할 필요가 없습니다. 그 대신, 수행하려는 API 작업과 일치하는 작업에만 액세스할 수 있도록 합니다.

사용자와 역할이 AWS Glue Console을 여전히 사용할 수 있도록 하려면 AWS Glue ConsoleAccess 또는 ReadOnly AWS 관리형 정책을 엔터티에 추가합니다. 자세한 내용은 IAM 사용 설명서의 사용자에게 권한 추가를 참조하세요.

사용자가 AWS Glue 콘솔로 작업하려면 해당 사용자는 AWS 계정에 대한 AWS Glue 리소스로 작업하도록 허용하는 최소 권한 집합이 있어야 합니다. 이 AWS Glue 권한 이외에 콘솔은 다음 서비스로부터 권한을 필요로 합니다.

  • 로그를 표시할 수 있는 Amazon CloudWatch Logs 권한.

  • 역할을 나열하고 전달할 수 있는 AWS Identity and Access Management(IAM) 권한.

  • 스택으로 작업할 수 있는 AWS CloudFormation 권한.

  • VPC, 서브넷, 보안 그룹, 인스턴스 및 기타 객체를 나열할 수 있는 Amazon Elastic Compute Cloud(Amazon EC2) 권한.

  • 버킷과 객체를 나열하고 스크립트를 검색하고 저장할 수 있는 Amazon Simple Storage Service(Amazon S3) 권한.

  • 클러스터 작업을 위한 Amazon Redshift 권한.

  • 인스턴스를 나열할 수 있는 Amazon Relational Database Service(Amazon RDS) 권한.

사용자가 AWS Glue 콘솔을 보고 작업하는 데 필요한 권한에 대한 자세한 내용은 3단계: AWS Glue에 액세스하는 사용자 또는 그룹에 정책 연결 단원을 참조하세요.

최소 필수 권한보다 더 제한적인 IAM 정책을 만들면 콘솔은 해당 IAM 정책에 연결된 사용자에 대해 의도대로 작동하지 않습니다. 이 사용자가 AWS Glue Console을 사용할 수 있도록 하려면 AWSGlueConsoleFullAccess 관리형 정책을 사용자에게 연결합니다(AWS Glue에 대한 AWS 관리형(미리 정의된) 정책 참조).

사용자가 자신의 고유한 권한을 볼 수 있도록 허용

이 예시는 IAM 사용자가 자신의 사용자 자격 증명에 연결된 인라인 및 관리형 정책을 볼 수 있도록 허용하는 정책을 생성하는 방법을 보여줍니다. 이 정책에는 콘솔에서 또는 AWS CLI나 AWS API를 사용하여 프로그래밍 방식으로 이 작업을 완료할 수 있는 권한이 포함됩니다.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "ViewOwnUserInfo", "Effect": "Allow", "Action": [ "iam:GetUserPolicy", "iam:ListGroupsForUser", "iam:ListAttachedUserPolicies", "iam:ListUserPolicies", "iam:GetUser" ], "Resource": ["arn:aws:iam::*:user/${aws:username}"] }, { "Sid": "NavigateInConsole", "Effect": "Allow", "Action": [ "iam:GetGroupPolicy", "iam:GetPolicyVersion", "iam:GetPolicy", "iam:ListAttachedGroupPolicies", "iam:ListGroupPolicies", "iam:ListPolicyVersions", "iam:ListPolicies", "iam:ListUsers" ], "Resource": "*" } ] }

테이블에 대한 읽기 전용 권한 부여

다음 정책은 데이터베이스 db1에 있는 테이블 books에 대한 읽기 전용 권한을 부여합니다. Amazon 리소스 이름(ARN)에 대한 자세한 내용은 Data Catalog ARN 단원을 참조하십시오.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "GetTablesActionOnBooks", "Effect": "Allow", "Action": [ "glue:GetTables", "glue:GetTable" ], "Resource": [ "arn:aws:glue:us-west-2:123456789012:catalog", "arn:aws:glue:us-west-2:123456789012:database/db1", "arn:aws:glue:us-west-2:123456789012:table/db1/books" ] } ] }

이 정책은 데이터베이스 db1에 있는 테이블 books에 읽기 전용 권한을 부여합니다. 테이블에 Get 권한을 부여하려면 카탈로그 및 데이터베이스 리소스에 대한 권한도 필요합니다.

다음 정책은 데이터베이스 db1에서 테이블 tb1을 생성하기 위해 필요한 최소 권한을 부여합니다.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "glue:CreateTable" ], "Resource": [ "arn:aws:glue:us-west-2:123456789012:table/db1/tbl1", "arn:aws:glue:us-west-2:123456789012:database/db1", "arn:aws:glue:us-west-2:123456789012:catalog" ] } ] }

GetTables 권한으로 테이블 필터링

데이터베이스 db1customers, storesstore_sales와 같은 3개의 테이블이 있다고 가정합니다. 다음 정책은 customers는 제외하고 storesstore_sales에 대한 GetTables 권한을 부여합니다. 이 정책으로 GetTables을 호출하면 결과에는 인증된 테이블 두 개만 포함됩니다. customers 테이블은 반환되지 않습니다.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "GetTablesExample", "Effect": "Allow", "Action": [ "glue:GetTables" ], "Resource": [ "arn:aws:glue:us-west-2:123456789012:catalog", "arn:aws:glue:us-west-2:123456789012:database/db1", "arn:aws:glue:us-west-2:123456789012:table/db1/store_sales", "arn:aws:glue:us-west-2:123456789012:table/db1/stores" ] } ] }

store로 시작하는 모든 테이블 이름과 일치하도록 store*를 사용하여 이전 정책을 간소화할 수 있습니다.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "GetTablesExample2", "Effect": "Allow", "Action": [ "glue:GetTables" ], "Resource": [ "arn:aws:glue:us-west-2:123456789012:catalog", "arn:aws:glue:us-west-2:123456789012:database/db1", "arn:aws:glue:us-west-2:123456789012:table/db1/store*" ] } ] }

마찬가지로, db1의 모든 테이블과 일치하도록 /db1/*을 사용하면 다음 정책은 db1의 모든 테이블에 대한 GetTables 액세스 권한을 부여합니다.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "GetTablesReturnAll", "Effect": "Allow", "Action": [ "glue:GetTables" ], "Resource": [ "arn:aws:glue:us-west-2:123456789012:catalog", "arn:aws:glue:us-west-2:123456789012:database/db1", "arn:aws:glue:us-west-2:123456789012:table/db1/*" ] } ] }

테이블 ARN을 제공하지 않으면 GetTables 호출은 성공하지만 빈 목록이 반환됩니다.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "GetTablesEmptyResults", "Effect": "Allow", "Action": [ "glue:GetTables" ], "Resource": [ "arn:aws:glue:us-west-2:123456789012:catalog", "arn:aws:glue:us-west-2:123456789012:database/db1" ] } ] }

데이터베이스 ARN이 정책에 누락된 경우에는 GetTables 호출이 실패하고 AccessDeniedException이 발생합니다.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "GetTablesAccessDeny", "Effect": "Allow", "Action": [ "glue:GetTables" ], "Resource": [ "arn:aws:glue:us-west-2:123456789012:catalog", "arn:aws:glue:us-west-2:123456789012:table/db1/*" ] } ] }

테이블 및 모든 파티션에 전체 액세스 권한 부여

다음 정책은 데이터베이스 db1에 있는 books 테이블에 대한 모든 권한을 부여합니다. 여기에는 테이블 자체, 테이블의 보관된 버전 및 테이블의 모든 파티션에 대한 읽기 및 쓰기 권한이 포함됩니다.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "FullAccessOnTable", "Effect": "Allow", "Action": [ "glue:CreateTable", "glue:GetTable", "glue:GetTables", "glue:UpdateTable", "glue:DeleteTable", "glue:BatchDeleteTable", "glue:GetTableVersion", "glue:GetTableVersions", "glue:DeleteTableVersion", "glue:BatchDeleteTableVersion", "glue:CreatePartition", "glue:BatchCreatePartition", "glue:GetPartition", "glue:GetPartitions", "glue:BatchGetPartition", "glue:UpdatePartition", "glue:DeletePartition", "glue:BatchDeletePartition" ], "Resource": [ "arn:aws:glue:us-west-2:123456789012:catalog", "arn:aws:glue:us-west-2:123456789012:database/db1", "arn:aws:glue:us-west-2:123456789012:table/db1/books" ] } ] }

실제로 이전 정책은 다음과 같이 간소화할 수 있습니다.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "FullAccessOnTable", "Effect": "Allow", "Action": [ "glue:*Table*", "glue:*Partition*" ], "Resource": [ "arn:aws:glue:us-west-2:123456789012:catalog", "arn:aws:glue:us-west-2:123456789012:database/db1", "arn:aws:glue:us-west-2:123456789012:table/db1/books" ] } ] }

세분화된 액세스 제어의 최소 세부 수준은 테이블 수준입니다. 즉, 사용자에게 테이블의 파티션 중 일부 또는 테이블 열 중 일부에 대한 권한을 부여할 수는 없습니다. 사용자는 테이블 전체에 대한 액세스 권한을 갖거나 해당 테이블에 대한 권한을 갖지 못하거나 둘 중 하나입니다.

이름 접두사 및 명시적 거부로 액세스 제어

이 예제에서는 AWS Glue Data Catalog의 데이터베이스 및 테이블이 이름 접두사를 사용하여 구성되었다고 가정합니다. 개발 스테이지의 데이터 베이스에 이름 접두사 dev-가 있고, 프로덕션 스테이지의 데이터베이스에는 이름 접두사 prod-가 있습니다. 다음 정책을 사용하여 이름 접두사가 dev-인 모든 데이터베이스, 테이블, UDF 등에 대한 모든 액세스를 개발자에게 부여할 수 있습니다. 하지만 이름 접두사가 prod-인 모든 항목에는 읽기 전용 액세스 권한을 부여합니다.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "DevAndProdFullAccess", "Effect": "Allow", "Action": [ "glue:*Database*", "glue:*Table*", "glue:*Partition*", "glue:*UserDefinedFunction*", "glue:*Connection*" ], "Resource": [ "arn:aws:glue:us-west-2:123456789012:catalog", "arn:aws:glue:us-west-2:123456789012:database/dev-*", "arn:aws:glue:us-west-2:123456789012:database/prod-*", "arn:aws:glue:us-west-2:123456789012:table/dev-*/*", "arn:aws:glue:us-west-2:123456789012:table/*/dev-*", "arn:aws:glue:us-west-2:123456789012:table/prod-*/*", "arn:aws:glue:us-west-2:123456789012:table/*/prod-*", "arn:aws:glue:us-west-2:123456789012:userDefinedFunction/dev-*/*", "arn:aws:glue:us-west-2:123456789012:userDefinedFunction/*/dev-*", "arn:aws:glue:us-west-2:123456789012:userDefinedFunction/prod-*/*", "arn:aws:glue:us-west-2:123456789012:userDefinedFunction/*/prod-*", "arn:aws:glue:us-west-2:123456789012:connection/dev-*", "arn:aws:glue:us-west-2:123456789012:connection/prod-*" ] }, { "Sid": "ProdWriteDeny", "Effect": "Deny", "Action": [ "glue:*Create*", "glue:*Update*", "glue:*Delete*" ], "Resource": [ "arn:aws:glue:us-west-2:123456789012:database/prod-*", "arn:aws:glue:us-west-2:123456789012:table/prod-*/*", "arn:aws:glue:us-west-2:123456789012:table/*/prod-*", "arn:aws:glue:us-west-2:123456789012:userDefinedFunction/prod-*/*", "arn:aws:glue:us-west-2:123456789012:userDefinedFunction/*/prod-*", "arn:aws:glue:us-west-2:123456789012:connection/prod-*" ] } ] }

이전 정책의 두 번째 문에서는 명시적 deny를 사용합니다. 명시적 deny를 사용해 보안 주체에 부여된 모든 allow 권한을 덮어쓸 수 있습니다. 그러면 중요한 리소스에 대한 액세스를 잠그고 다른 정책이 이러한 리소스에 대해 실수로 액세스 권한을 부여하지 않도록 방지할 수 있습니다.

이전 예제에서는 첫 번째 문이 prod- 리소스에 대한 모든 액세스 권한을 부여하더라도 두 번째 문이 리소스에 대한 쓰기 액세스 권한을 명시적으로 취소해 prod- 리소스에 대해 일기 전용 액세스만 남아 있게 됩니다.

태그를 사용한 액세스 권한 부여

예를 들어 트리거 t2에 대한 액세스를 계정에 있는 Tom이라는 특정 사용자로 제한하려 한다고 가정합니다. Sam을 포함해 다른 모든 사용자들은 t1을 트리거하기 위한 액세스 권한을 갖습니다. 트리거 t1t2는 다음과 같은 속성을 갖추고 있습니다.

aws glue get-triggers { "Triggers": [ { "State": "CREATED", "Type": "SCHEDULED", "Name": "t1", "Actions": [ { "JobName": "j1" } ], "Schedule": "cron(0 0/1 * * ? *)" }, { "State": "CREATED", "Type": "SCHEDULED", "Name": "t2", "Actions": [ { "JobName": "j1" } ], "Schedule": "cron(0 0/1 * * ? *)" } ] }

t2를 트리거하기 위한 태그 값 Tom(aws:ResourceTag/Name": "Tom")에 AWS Glue 관리자가 연결되어 있습니다. 또한 AWS Glue 관리자는 태그를 기준으로 조건 문과 함께 IAM 정책을 Tom에게 제공했습니다. 결과적으로 Tom은 태그 값 Tom으로 리소스에서 수행되는 AWS Glue 작업만 사용할 수 있습니다.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "glue:*", "Resource": "*", "Condition": { "StringEquals": { "aws:ResourceTag/Name": "Tom" } } } ] }

Tom이 트리거 t1에 대한 액세스를 시도하면 액세스 거부 메시지가 수신됩니다. 한편, Tom은 트리거 t2를 성공적으로 검색할 수 있습니다.

aws glue get-trigger --name t1 An error occurred (AccessDeniedException) when calling the GetTrigger operation: User: Tom is not authorized to perform: glue:GetTrigger on resource: arn:aws:glue:us-east-1:123456789012:trigger/t1 aws glue get-trigger --name t2 { "Trigger": { "State": "CREATED", "Type": "SCHEDULED", "Name": "t2", "Actions": [ { "JobName": "j1" } ], "Schedule": "cron(0 0/1 * * ? *)" } }

이 작업은 태그에 대한 필터링을 지원하지 않기 때문에 Tom은 여러 개의 GetTriggers API 작업을 사용하여 트리거를 나열할 수 없습니다.

Tom에게 GetTriggers에 대한 액세스 권한을 부여하기 위해 AWS Glue 관리자는 권한을 두 개의 섹션으로 분할하는 정책을 생성합니다. 첫 번째 섹션에서는 Tom에게 GetTriggers API 작업에서 모든 트리거에 액세스할 수 있도록 허용합니다. 두 번째 섹션에서는 Tom에게 Tom으로 태그 값이 지정된 API 작업에 액세스할 수 있도록 허용합니다. 이 정책에 따라 Tom에게는 트리거 t2에 대한 GetTriggersGetTrigger 액세스가 모두 허용됩니다.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "glue:GetTriggers", "Resource": "*" }, { "Effect": "Allow", "Action": "glue:*", "Resource": "*", "Condition": { "StringEquals": { "aws:ResourceTag/Name": "Tom" } } } ] }

태그를 사용한 액세스 거부

또 다른 리소스 정책 접근 방식은 리소스에 대한 액세스를 명시적으로 거부하는 것입니다.

중요

명시적 거부 정책은 GetTriggers와 같은 여러 개의 API 작업에 적용되지 않습니다.

다음 예제 정책에서는 모든 AWS Glue 작업이 허용됩니다. 그러나 두 번째 Effect 명령문은 Team 키와 Special 값으로 태그가 지정된 작업에 대한 액세스를 명시적으로 거부합니다.

관리자가 자격 증명에 다음 정책을 연결하면 해당 자격 증명은 Team 키와 Special 값이 태그로 지정된 작업을 제외한 모든 작업에 액세스할 수 있습니다.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "glue:*", "Resource": "arn:aws:glue:us-east-1:123456789012:job/*" }, { "Effect": "Deny", "Action": "glue:*", "Resource": "arn:aws:glue:us-east-1:123456789012:job/*", "Condition": { "StringEquals": { "aws:ResourceTag/Team": "Special" } } } ] }

목록 및 배치 API 작업과 함께 태그 사용

리소스 정책을 작성하는 세 번째 접근 방식은 태그 값에 대해 리소스를 나열하도록 List API 작업을 사용해 리소스에 대한 액세스를 허용하는 것입니다. 그런 다음, 해당되는 Batch API 작업을 사용하여 특정 리소스의 세부 정보에 대한 액세스를 허용합니다. 이러한 접근 방식에서는 관리자가 여러 개의 GetCrawlers, GetDevEndpoints, GetJobs 또는 GetTriggers API 작업에 대한 액세스를 허용할 필요가 없습니다. 대신에 다음 API 작업을 통해 리소스를 나열할 수 있도록 허용할 수 있습니다.

  • ListCrawlers

  • ListDevEndpoints

  • ListJobs

  • ListTriggers

그리고 다음 API 작업을 통해 개별 리소스에 대한 세부 정보를 확인할 수 있도록 허용할 수 있습니다.

  • BatchGetCrawlers

  • BatchGetDevEndpoints

  • BatchGetJobs

  • BatchGetTriggers

관리자는 이러한 접근 방식을 사용하기 위해 다음을 수행할 수 있습니다.

  1. 크롤러, 개발 엔드포인트, 작업 및 트리거에 태그를 추가합니다.

  2. GetCrawlers, GetDevEndponts, GetJobs, GetTriggers 같은 Get API 작업에 대한 사용자 액세스를 거부합니다.

  3. 사용자가 액세스 권한을 가진 태그 지정 리소스를 확인할 수 있도록 ListCrawlers, ListDevEndponts, ListJobs, ListTriggers 같은 List API 작업에 대한 사용자 액세스를 허용합니다.

  4. TagResourceUntagResource 같은 AWS Glue 태그 지정 API에 대한 사용자 액세스를 거부합니다.

  5. BatchGetCrawlers, BatchGetDevEndponts, BatchGetJobs, BatchGetTriggers 같은 BatchGet API 작업을 통해 리소스 세부 정보에 대한 사용자 액세스를 허용합니다.

예를 들어, ListCrawlers 작업을 호출할 때 사용자 이름과 일치하도록 태그 값을 제공합니다. 그러면 결과는 제공된 태그 값과 일치하는 크롤러의 목록이 됩니다. 주어진 태그를 사용해 각 크롤러에 대한 세부 정보를 얻을 수 있도록 BatchGetCrawlers에 이름 목록을 제공합니다.

예를 들어 Tom이 Tom으로 태그가 지정된 트리거의 세부 정보만 검색할 수 있도록 하려면 관리자가 Tom에서 트리거에 태그를 추가하고, 모든 사용자에 대해 GetTriggers API 작업 액세스를 거부하고, 모든 사용자에 대해 ListTriggersBatchGetTriggers 액세스를 허용할 수 있습니다.

다음은 AWS Glue 관리자가 Tom에게 부여하는 리소스 정책입니다. 이 정책의 첫 번째 섹션에서는 GetTriggers에 대한 AWS Glue API 작업이 거부됩니다. 정책의 두 번째 섹션에서는 모든 리소스에 대해ListTriggers가 허용됩니다. 그러나 세 번째 섹션에서는 Tom이라고 태그가 지정된 리소스에게 BatchGetTriggers 액세스가 허용됩니다.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "glue:GetTriggers", "Resource": "*" }, { "Effect": "Allow", "Action": [ "glue:ListTriggers" ], "Resource": [ "*" ] }, { "Effect": "Allow", "Action": [ "glue:BatchGetTriggers" ], "Resource": [ "*" ], "Condition": { "StringEquals": { "aws:ResourceTag/Name": "Tom" } } } ] }

Tom은 이전 예제와 똑같은 트리거를 사용하여 트리거 t2에 액세스할 수 있지만, 트리거 t1에는 액세스할 수 없습니다. 다음 예제는 Tom이 BatchGetTriggers를 통해 t1t2에 액세스를 시도할 때의 결과를 보여줍니다.

aws glue batch-get-triggers --trigger-names t2 { "Triggers": { "State": "CREATED", "Type": "SCHEDULED", "Name": "t2", "Actions": [ { "JobName": "j2" } ], "Schedule": "cron(0 0/1 * * ? *)" } } aws glue batch-get-triggers --trigger-names t1 An error occurred (AccessDeniedException) when calling the BatchGetTriggers operation: No access to any requested resource.

다음 예제는 Tom이 동일한 BatchGetTriggers 호출에서 트리거 t2와 트리거 t3(존재하지 않음) 모두에 액세스를 시도할 때의 결과를 보여줍니다. Tom은 트리거 t2에 대한 액세스 권한을 가지고 있고 이 트리거가 존재하기 때문에 t2만 반환됩니다. Tom에게 트리거 t3에 대한 액세스가 허용되지만 트리거 t3가 존재하지 않기 때문에 "TriggersNotFound": [] 목록에서 응답으로 t3가 반환됩니다.

aws glue batch-get-triggers --trigger-names t2 t3 { "Triggers": { "State": "CREATED", "Type": "SCHEDULED", "Name": "t2", "Actions": [ { "JobName": "j2" } ], "TriggersNotFound": ["t3"], "Schedule": "cron(0 0/1 * * ? *)" } }

조건 키 또는 컨텍스트 키를 사용하여 설정 제어

작업 생성 및 업데이트 권한을 부여할 때 조건 키 또는 컨텍스트 키를 사용할 수 있습니다. 다음 섹션에서는 키에 대해 설명합니다.

조건 키를 사용하여 설정을 제어하는 정책 제어

AWS Glue는 glue:VpcIds, glue:SubnetIdsglue:SecurityGroupIds의 세 가지 IAM 조건 키를 제공합니다. 작업 생성 및 업데이트 권한을 부여할 때 조건 키를 IAM 정책에 사용할 수 있습니다. 이 설정을 사용하여 원하는 VPC 환경 외부에서 실행하려는 경우 작업 또는 세션을 생성하거나 업데이트하지 않도록 할 수 있습니다. VPC 설정 정보는 CreateJob 요청에서 직접 입력하지 않고 AWS Glue 연결을 가리키는 작업 '연결' 필드에서 유추됩니다.

사용 예

원하는 VpcId 'vpc-id1234', SubnetIds, SecurityGroupIds를 사용하여 '트래픽 모니터링 연결'이라는 AWS Glue 네트워크 유형 연결을 생성합니다.

IAM 정책에서 CreateJobUpdateJob 작업에 대한 조건 키 조건을 지정합니다.

{ "Effect": "Allow", "Action": [ "glue:CreateJob", "glue:UpdateJob" ], "Resource": [ "*" ], "Condition": { "ForAnyValue:StringLike": { "glue:VpcIds": [ "vpc-id1234" ] } } }

연결 정보를 지정하지 않고 AWS Glue 작업을 생성할 수 없도록 하는 유사한 IAM 정책을 생성할 수 있습니다.

VPC의 세션 제한

지정된 VPC 내에서 생성된 세션을 실행하도록 하려면 glue:vpc-id가 vpc-<123>이 아니라는 조건에서 glue:CreateSession 작업에 Deny 적용을 추가하여 역할 권한을 제한합니다. 예제:

"Effect": "Deny", "Action": [ "glue:CreateSession" ], "Condition": { "StringNotEquals" : {"glue:VpcIds" : ["vpc-123"]} }

또한 glue:vpc-id가 null이라는 조건에서 glue:CreateSession 작업에 Deny 적용을 추가하여 VPC 내에서 생성된 세션을 실행하도록 할 수도 있습니다. 예제:

{ "Effect": "Deny", "Action": [ "glue:CreateSession" ], "Condition": { "Null": {"glue:VpcIds": true} } }, { "Effect": "Allow", "Action": [ "glue:CreateSession" ], "Resource": ["*"] }

컨텍스트 키를 사용하여 설정을 제어하는 정책 제어

AWS Glue는 작업 및 개발자 엔드포인트에서 AWS Glue를 통해 사용할 수 있는 각 역할 세션에 컨텍스트 키(glue:CredentialIssuingService= glue.amazonaws.com)를 제공합니다. 이렇게 하면 AWS Glue 스크립트에서 수행하는 작업에 대한 보안 제어를 구현할 수 있습니다. AWS Glue는 고객을 대신하여 AWS Glue가 다른 AWS 서비스를 호출(작업/개발 엔드포인트가 아닌 AWS Glue 서비스를 통해 직접 호출)하는 각 역할 세션에 다른 컨텍스트 키(glue:RoleAssumedBy=glue.amazonaws.com)를 제공합니다.

사용 예

IAM 정책에서 조건부 권한을 지정하고 AWS Glue 작업에서 사용할 역할에 이 권한을 연결합니다. 이렇게 하면 역할 세션이 AWS Glue 작업 런타임 환경에 사용되는지 여부에 따라 특정 작업이 허용/거부됩니다.

{ "Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::confidential-bucket/*", "Condition": { "StringEquals": { "glue:CredentialIssuingService": "glue.amazonaws.com" } } }

ID가 데이터 미리 보기 세션을 생성하지 못하게 하기

이 섹션에는 ID가 데이터 미리 보기 세션을 생성하지 못하게 하는 데 사용되는 IAM 정책 예제가 포함되어 있습니다. 실행 중 데이터 미리 보기 세션에서 사용되는 역할과 별개인 ID에 이 정책을 연결합니다.

{ "Sid": "DatapreviewDeny", "Effect": "Deny", "Action": [ "glue:CreateSession" ], "Resource": [ "arn:aws:glue:*:*:session/glue-studio-datapreview*" ] }