목표

• 계정 간 자원 공유의 이점 이해
• 계정 간에 자원을 공유하기 위한 다양한 기술에 대해 알아보기

자원 공유 개요

여러 애플리케이션 액세스를 찾아 동일한 자원 또는 일부를 사용하는 것이 일반적입니다. 한 가지 예로 애플리케이션 및 컴퓨팅 환경이 동일한 회사 네트워크에서 작동해야 하는 경우가 있습니다. 또 다른 시나리오는 보안 로그가 중앙 스토리지에 수집되는 것입니다. 마이크로서비스 아키텍처에서는 외부 자원에 액세스하고 이를 사용하도록 서비스를 구성해야 합니다. 그런 다음 공유 자원은 액세스 권한을 부여해야 하며, 이들 간의 네트워크는 이러한 협업을 지원하도록 구성되어 있지만 더 이상 지원되지 않습니다.

자원 공유의 몇 가지 일반적인 유스 케이스는 다음과 같습니다.

• 보안 관련 인프라의 중앙 관리. 전용 계정에서 보안을 모니터하고 단일 위치에서 보안 로그를 집계합니다. 중앙 키 관리 시스템 (KMS) 에서 모든 암호화 키를 관리합니다.
• 네트워크 주소 및 서브넷 조정. 애플리케이션 및 컴퓨팅 환경은 동일한 네트워크에 맞아야 하며 주소 범위 및 도메인 이름을 공유해야 합니다.
• IBM Cloud Backup for Classic 와 같은 백업 서비스를 포함하여 재해 복구를 위한 자원의 중앙 관리. 애플리케이션 및 해당 서비스는 고가용성을 위해 설계될 수 있지만 최악의 경우 중앙에서 구성된 추가 자원을 사용하여 폴백할 수 있습니다. 여기에는 복제된 Object Storage 버킷 에 저장되는 등 전세계적으로 사용 가능한 여러 자원 사본 보유가 포함됩니다.
• 가능한 경우 비용이 더 많이 드는 서비스를 공유하여 비용을 제어 하십시오. 모든 개발 프로젝트에서 모든 서비스를 전용 인스턴스로 배치할 필요는 없습니다. 종종 계정 내에서 또는 전체에서 서비스 인스턴스를 공유하는 것으로 충분합니다. 프로덕션 환경의 경우에도 비용/값 요인 및 기술적 실행 가능성에 따라 서비스 인스턴스를 공유할 수 있습니다. 이는 개인용 카탈로그를 이용하고 공용 카탈로그를 제한하여 계정에서 사용 가능한 서비스를 제한한 후 제한된 서비스의 인스턴스를 중앙 집중식으로 제공하여 구성할 수 있습니다.
• 회사 레벨 또는 비즈니스 단위에 대한 자원의 중앙 관리. 이는 브랜딩 또는 중앙에서 관리되는 템플리트, 기본 이미지 (가상 머신, 컨테이너) 등에 필요한 자산일 수 있습니다. 개인용 카탈로그 및 Container Registry 은 일반적인 서비스입니다.
• 더 많은 사용자가 부족한 자원을 사용할 수 있도록 하십시오. 때때로 자원 유형은 제한된 수량으로만 사용 가능합니다. 공유를 통해 더 많은 애플리케이션에서 이점을 얻을 수 있습니다. 이 경우 속도 제한이 필요할 수 있습니다.

보안 자원 공유

보안은 회사 전체의 규칙이 적용된 회사 레벨에서 관리되는 경우가 많습니다. 따라서 강제 실행도 중앙에서 관리됩니다. 이는 워크로드가 클라우드 환경으로 이동하는 경우에도 마찬가지입니다. 자원 공유는 보안을 중앙에서 관리하고 준수를 평가하고 적용하는 기반이 됩니다.

위의 다이어그램은 다음 시나리오를 표시합니다.

1. 계정 A 및 계정 B 의 Object Storage 및 Databases for MongoDB 의 인스턴스는 Key Protect의 기본 계정 에서 관리되는 암호화 키를 사용합니다.
2. 기본 계정 의 Security and Compliance Center 는 세 계정 모두의 자원을 관리합니다 (위의 검은색 라인 참조).
3. 계정 A와 계정 B의 IBM Cloud Activity Tracker Event Routing 인스턴스는 감사 로그를 메인 계정의 IBM Cloud Logs 직접 전송합니다(위의 파란색 선 참조). IBM Cloud Logs 분석 및 기업 요구 사항을 충족하기 위해 감사 로그를 유지하도록 구성됩니다.

IBM Cloud Enterprise 환경 의 계정 간에 또는 공식 엔터프라이즈 조직 없이 공유할 수 있습니다.

네트워크 자원 공유

엔터프라이즈 컨텍스트에서 클라우드 네이티브 앱을 디자인하고 개발하는 작업에는 종종 주소 범위 및 서브넷, 도메인 이름 및 트래픽 라우팅과 같은 네트워크 자원과 관련하여 조정하는 작업이 포함됩니다. 서로 다른 계정과 해당 애플리케이션 및 컴퓨팅 환경은 네트워크 및 해당 구조에 맞아야 합니다. 이 경우 네트워크 자원을 공유해야 합니다.

1. Transit Gateway 서비스는 세 개의 계정에서 VPC 환경과 클래식 인프라를 상호 연결하는 데 사용됩니다.
2. 각 계정에는 개인용 도메인 이름을 관리하기 위한 DNS Services 인스턴스가 있습니다. 인스턴스는 DNS 구역을 공유하기 위해 연결됩니다.

자원 공유 구현

소개에서 설명한 대로 하나의 (클라우드) 계정 외부에서 서비스에 액세스하는 것이 일반적인 사례입니다. 통합 레벨에 따라 서비스 액세스 권한을 부여하고 인증을 구현하는 여러 가지 방법이 있습니다. 이러한 사용 가능한 옵션은 아래에 설명되어 있습니다.

서비스 대 서비스 권한

한 서비스가 다른 서비스에 액세스하기 위한 보다 엄격한 통합 접근 방식은 서비스 대 서비스 권한 부여(s2s 권한 부여)를 설정 하는 것입니다. 소스 서비스에 대상 서비스에 액세스할 수 있는 권한을 부여하는 IBM Cloud Identity and Access Management 정책을 작성합니다. 액세스를 요청하는 소스 서비스를 식별하여 인증을 수행하므로 비밀번호 또는 API키 양식의 신임 정보가 필요하지 않습니다. 인증 및 권한 모두 작성된 IAM 정책으로 인해 자동으로 처리됩니다.

교차 계정 권한

IAM은 다른 IBM Cloud 계정의 소스 서비스와 현재 계정의 대상 간에 서비스 대 서비스 권한 설정을 지원합니다. 따라서 IAM 권한 부여 정책을 작성하여 계정 간에 리소스를 공유할 수 있습니다. 이러한 정책은 아래에 표시된 대로 브라우저 콘솔의 를 포함하여 CLI를 활용하거나 Terraform 코드를 실행하여 여러 방식으로 작성할 수 있습니다.

다음 예제에서 소스 계정의 특정 Object Storage 인스턴스에는 현재 계정의 식별된 Key Protect 인스턴스에 대한 독자 역할이 부여됩니다.

다음은 동일한 IAM 권한 부여 정책이 있는 리소스를 작성하기 위한 Terraform 코드를 표시합니다.

resource "ibm_iam_authorization_policy" "cross_account_policy" {
  source_service_account      = data.ibm_iam_account_settings.account_a_settings.account_id
  source_service_name         = "cloud-object-storage"
  source_resource_instance_id = data.ibm_resource_instance.cos_resource_instance.guid

  target_service_name         = "kms"
  target_resource_instance_id = data.ibm_resource_instance.kms_resource_instance.guid

  roles                       = ["Reader"]
  description                 = "read access on Key Protect in Main Account for Account A"
}

iam service-policy-create 명령을 사용한 IBM Cloud CLI 를 사용하여 동일한 권한 부여 정책을 작성할 수 있습니다.

ibmcloud iam authorization-policy-create cloud-object-storage kms Reader --source-service-account source_account_id --source-service-instance-id cos_instance_id --target-service-instance-id kms_instance_id

콘솔, Terraform 제공자 및 CLI는 모두 IAM 정책 관리 API 를 사용하여 정책을 작성합니다.

권한 부여 정책이 있는 다음 단계에서는 Key Protect 루트 키를 사용하여 암호화된 스토리지 버킷을 작성할 수 있습니다. 다음은 ibm_cos_bucket리소스를 활용하는 Terraform 코드를 표시합니다. key_protect 속성은 루트 키의 CRN을 보유합니다.

resource "ibm_cos_bucket" "cos_bucket" {
  bucket_name          = "cos-bucket"
  resource_instance_id = data.ibm_resource_instance.cos_resource_instance.id
  region_location      = var.region
  key_protect          = data.ibm_kms_key.central_kms_root_key.id
  storage_class        = "smart"
}

GitHub 저장소 cross-account-resource-sharing에서 추가 예제를 찾을 수 있습니다.

일반적인 서비스 대 서비스 권한

Key Protect 및 Hyper Protect Crypto Services 와 같은 키 관리 서비스 (KMS) 에 대한 종속성은 클라우드 기반 솔루션의 일반적인 종속성입니다. KMS 인스턴스는 고객 관리 암호화를 위한 루트 키를 보유합니다. 대부분의 서비스는 고객이 제어하는 암호화 키를 지원합니다. 위의 예에서 cloud-object-storage (Object Storage) 대신 다른 많은 서비스가 계정 간에 공유되는 KMS 인스턴스를 사용할 수 있습니다.

서비스 대 서비스 권한 부여를 위한 기타 일반적인 (대상) 서비스 및 자원 공유 후보는 다음과 같습니다.

• Object Storage: 여러 서비스에서 스토리지 버킷에 데이터 및 로그 파일을 저장해야 하거나 저장할 수 있습니다. 여기에는 액세스 로그 및 모니터링 데이터의 아카이브가 포함됩니다. 기타 서비스는 데이터 분석을 수행하기 위해 버킷에 액세스해야 합니다. 또한 다른 카테고리의 서비스는 조치 실행을 트리거하기 위해 알림을 변경하기 위해 등록할 수 있는 액세스 권한이 필요합니다.
• Event Notifications: 이벤트에 대한 정보를 구독자에게 푸시하려면 서비스 인스턴스가 Event Notifications 인스턴스에 액세스해야 합니다.
• Secrets Manager: 이 서비스는 다른 서비스 IAM API키, SSL/TLS 인증서 및 기타 시크릿을 저장하고 제공합니다. 따라서 종속 (소스) 서비스는 Secrets Manager에 액세스해야 합니다.
• Cloud Internet Services (CIS): 도메인 이름 및 기타 네트워크 데이터를 관리하므로 인증서 유효성 검증에 사용할 수 있습니다.
• {IBM Cloud Logs Routing 및 IBM Cloud Activity Tracker Event Routing: IBM Cloud Logs 같은 타겟에 대한 서비스 액세스가 필요합니다.

위의 목록은 완전하지 않습니다.

요약

다른 계정의 자원에 액세스하는 경우에도 자원을 공유하는 것이 일반적인 사례입니다. 사용자가 자원 공유에서 이점을 얻는 몇 가지 유스 케이스가 있습니다. 개요에서 설명되었습니다. 자원에 액세스하기 위한 사용자 ID및 비밀번호 또는 API키의 조합은 종종 인증 역할을 합니다. 액세스는 권한 세트로 범위가 지정될 수 있습니다. 예를 들어, 읽기 액세스 또는 일부 기타 제한된 조치만 허용할 수 있습니다. 때때로 이러한 유형의 인증 정보는 애플리케이션 또는 컴퓨팅 환경 ("서비스 바인딩") 과 같은 액세스 자원에 의해 작성되고 관리될 수 있습니다. 신임 정보가 필요하지 않은 더 엄격한 통합은 IBM Cloud 서비스 대 서비스 권한 부여의 개념입니다. 액세스 자원 (소스) 및 액세스된 자원 (대상) 은 해당 특성 (인증) 으로 식별되며 액세스 역할이 지정됩니다 (권한 부여). 이러한 관계는 계정 경계에서도 설정될 수 있습니다. 이를 통해 단순하게 구성할 수 있지만 계정 간 자원 공유를 보호할 수 있습니다.

GitHub 저장소 cross-account-resource-sharing에서 이러한 서비스 중 일부에 대한 리소스 공유를 설정하는 방법에 대한 코드 예제를 찾을 수 있습니다.

관련 리소스

다음 문서는 일부 교차 계정 시나리오에 대한 세부사항을 제공합니다.

• 사용자에 대한IBM Cloud API키는 여러 계정에서 범위를 가질 수 있습니다.

여러 계정에서 자원을 공유하는 것과 관련된 블로그 게시물:

• IBM Cloud
• IBM Cloud CLI 사용에 대한 팁 및 요령 에서는 CLI에서 여러 계정에 대해 작업하는 데 사용할 수 있는 IBMCLOUD_HOME 에 대해 설명합니다.