신뢰할 수 있는 프로파일을 보안 클라우드 환경의 기반으로 사용

이 튜토리얼에서는 비용이 발생할 수 있습니다. Cost Estimator를 사용하여 예상 사용량을 기반으로 비용 추정값을 생성하십시오.

IBM Cloud Identity and Access Management(IAM) 를 사용하면 클라우드 환경에서 리소스를 보고, 작성하고, 사용하고, 관리하는 사용자를 제어할 수 있습니다. 사용자 환경은 여러 계정 그룹 및 계정의 계층 구조가 있는 단일 IBM Cloud 계정, 다중 계정 또는 엔터프라이즈 일 수 있습니다. 계정 리소스를 사용하여 운영할 때 사용자 및 서비스 ID가 포함되는 경우가 많습니다. 그러나 액세스를 관리하고, 권한을 지정하고, 신뢰할 수 있는 프로파일 을 식별하는 데 사용할 수 있는 추가 옵션이 있습니다.

이 학습서에서는 신뢰할 수 있는 프로파일, 해당 유스 케이스 및 향상된 보안을 위해 이를 활용하는 방법에 대해 학습합니다. 신뢰할 수 있는 프로파일은 보안 클라우드 환경의 기반이 될 수 있으며 보안 클라우드 솔루션의 구성 요소가 될 수 있습니다. 이 학습서의 일부로, 관리 태스크를 수행하기 위해 앱에서 활용하는 신뢰할 수 있는 프로파일을 작성합니다.

목표

  • 신뢰할 수 있는 프로파일의 유스 케이스 학습
  • 신뢰할 수 있는 프로파일 작성 및 클라우드 리소스에 대한 액세스 관리
  • Identity and Access Management (IAM)에 대한 지식 심화

아키텍처
솔루션 아키텍처

  • 애플리케이션의 컨테이너 이미지를 Container Registry 에서 가져오고 Kubernetes 클러스터에 네임스페이스로 배치합니다.
  • 사용자가 애플리케이션에 연결합니다.
  • 애플리케이션은 Kubernetes 환경에서 특수 액세스 토큰을 읽고 이를 신뢰할 수 있는 프로파일의 IAM 액세스 토큰으로 전환합니다.
  • IAM은 감사 이벤트를 IBM Cloud Activity Tracker Event Routing 기록합니다.

시작하기 전에

이 튜토리얼에서는 설치가 필요하지 않으며 IBM Cloud 콘솔만 사용합니다.

IBM Cloud Activity Tracker Event Routing 감사 이벤트를 IBM Cloud Logs 대상 인스턴스로 라우팅하도록 구성해야 합니다. 현재 계정에 구성되지 않은 경우 IBM 로그 대상 구성에 설명된 대로 글로벌 감사 이벤트를 라우팅합니다.

개요: 신뢰할 수 있는 프로파일

사용자 및 서비스 ID와 유사하게 신뢰할 수 있는 프로파일 은 IAM 정책에서 액세스 권한을 부여할 수 있는 ID입니다. 신뢰할 수 있는 프로파일은 API키를 작성하고 소유할 수 없다는 점에서 다릅니다. 이는 API키를 사용하지 않고 해당 계정 내에서 작업하기 위해 특정 사용자 또는 다른 사용자의 "게이트웨이" 역할을 하는 특정 계정 내의 ID입니다. 신뢰할 수 있는 프로파일의 ID를 가정할 수 있습니다.

신뢰할 수 있는 프로파일 설정의 일부로 해당 사용자 또는 다른 사용자 (아래 참조) 를 구성합니다. IBM Cloud API, CLI, 사용 가능한 SDK, Terraform 또는 IBM Cloud 콘솔과 같은 모든 일반적인 옵션을 사용할 수 있습니다.

콘솔에서 IAM 카테고리의 일부로 신뢰할 수 있는 프로파일 에는 자체 섹션이 있습니다. 이를 쉽게 작성하고 관리할 수 있습니다. 다음 스크린샷은 신뢰할 수 있는 프로파일을 작성하기 위한 대화 상자의 두 번째 단계를 보여줍니다. 신뢰할 수 있는 프로파일의 ID를 가정할 수 있는 엔티티인 신뢰 설정 방법을 구성 할 수 있습니다. 다음 중 하나 이상입니다.

  • 연합 사용자
  • 컴퓨팅 자원
  • IBM Cloud 서비스
  • 서비스 ID

신뢰할 수 있는 프로파일 엔티티 유형
신뢰할 수 있는 엔티티 유형

신뢰할 수 있는 프로파일 유스 케이스

신뢰할 수 있는 프로파일은 IBM Cloud내의 ID입니다. IAM 액세스 그룹의 구성원이 될 수 있으므로 액세스 권한이 지정됩니다. 사용자 및 서비스 ID와 유사하게 신뢰할 수 있는 프로파일에 직접 액세스를 지정할 수도 있습니다. 구별되는 기능은 특정 ID 또는 자원이 해당 ID로 작동할 수 있도록 신뢰할 수 있는 프로파일을 구성하는 기능입니다. 이러한 ID및 자원은 다른 계정에도 있을 수 있습니다. 따라서 상위 레벨에서 신뢰할 수 있는 프로파일을 사용하기 위한 유스 케이스는 관리 작업을 허용하는 것입니다.

  • 지정된 특권 세트를 사용하여
  • 특정 ID하에서
  • 신뢰할 수 있는 프로파일의 일부로 구성된 특성 세트로 식별되는 ID 또는 자원의 경우.

다음 시나리오는 신뢰가 설정되는 방식에 따라 다른 신뢰할 수 있는 프로파일에 대한 유스 케이스입니다.

  • 연합 사용자 및 해당 그룹 멤버십을 IBM Cloud 권한에 맵핑: 연합 ID 제공자의 사용자가 해당 ID를 가정할 수 있도록 신뢰할 수 있는 프로파일을 구성합니다. 고려할 IdP 및 사용자 속성을 정의할 수 있습니다.
  • 전용 컴퓨팅 리소스에서 관리 태스크 수행: 잘 알려진 컴퓨팅 리소스를 통해 신뢰를 설정하도록 신뢰할 수 있는 프로파일을 구성할 수 있습니다. 이러한 리소스는 Kubernetes 클러스터의 특정 팟 (Pod) ( Red Hat OpenShift on IBM Cloud포함) 또는 가상 프라이빗 클라우드의 가상 서버 인스턴스 (VSI) (IBM Cloud VPC) 일 수 있습니다.
  • 잘 알려진 서비스 ID에서 관리 태스크 수행: 동일하거나 다른 계정의 서비스 ID는 신뢰할 수 있는 프로파일의 ID를 가정할 수 있습니다.
  • 특수 클라우드 서비스의 인스턴스에서 클라우드 리소스 배치: 신뢰할 수 있는 프로파일의 ID를 가정할 수 있도록 CRN (클라우드 리소스 이름) 으로 식별되는 IBM Cloud 서비스의 인스턴스를 구성합니다. 일반적인 시나리오는 아키텍처를 배치하는 엔터프라이즈 프로젝트 에 대한 것입니다.

신뢰 설정

개요에 요약된 대로, 신뢰를 설정하는 방법, 엔티티가 신뢰할 수 있는 프로파일의 ID를 가정할 수 있는 방법에 대해 사용 가능한 여러 가지 옵션이 있습니다.

연합 ID

회사 또는 엔터프라이즈 싱글 사인온 ID를 사용하여 IBM Cloud 에 로그인하는 사용자를 연합 ID라고 합니다. 싱글 사인온 (SSO) 제공자는 ID 제공자 (IdP) 역할을 합니다. 연합 ID를 활용하면 사용자가 IBM Cloud 에서 사용하기 위해 새 신임 정보가 필요하지 않으며 회사의 IdP 를 인증 에 계속 사용할 수 있다는 장점이 있습니다.

연합 ID는 IAM 액세스 그룹의 동적 규칙에서 신뢰할 수 있는 프로파일 및 와 함께 사용할 수 있습니다.

계산 자원

이 경우 ID 제공자가 제공하는 사용자 특성을 사용하는 대신 계산 자원의 속성 을 통해 신뢰가 설정됩니다. 예를 들어, Kubernetes 클러스터의 특정 네임스페이스 및 팟 (Pod) 에서 실행 중인 앱만 신뢰하도록 구성하거나 리소스 그룹, 지역, 서브넷 및 구역에 대한 값의 특정 조합을 사용하여 VPC의 가상 서버 인스턴스를 신뢰하도록 구성할 수 있습니다. 해당 신뢰할 수 있는 앱은 신뢰할 수 있는 프로파일의 ID를 가정하고 지정된 권한으로 태스크를 수행할 수 있습니다.

계산 자원을 기반으로 신뢰할 수 있는 프로파일을 활용하는 이점은 이 솔루션이 API키를 사용하지 않는다는 점입니다. 따라서 공유 API키를 작성, 저장 및 보호하는 방법, 권한을 지정하고 관리하는 방법에 대한 요구사항과 인증 확인이 없습니다. 신뢰할 수 있는 프로파일의 ID를 가정하는 앱은 단순히 특수 계산 리소스 토큰을 페치한 후 이를 신뢰할 수 있는 프로파일에 대한 일반 IAM 액세스 토큰으로 전환합니다. 그 후에, 의도된 태스크들은 인증을 위해 제공된 토큰으로 수행될 수 있다.

컴퓨팅 리소스 토큰에 대한 배경 정보는 블로그 게시물 개발자 요령: 로컬 앱 개발을 위한 클라우드 보안 시뮬레이션 을 참조하십시오. 해당 토큰을 활용하여 앱을 로컬에서 개발하고 테스트하는 방법을 학습합니다.

서비스 ID

신뢰를 설정하는 또 다른 방법은 서비스 ID를 지정하는 것입니다. 서비스 ID는 동일한 계정 또는 다른 계정에서 가져올 수 있습니다. 서비스 ID는 모든 IBM Cloud 계정에서 고유한 ID이므로 추가 속성을 구성할 필요가 없습니다. 해당 설정을 사용하여 계정 A의 서비스 ID는 이제 계정 B에서 신뢰할 수 있는 프로파일의 ID를 가정하고 (관리) 태스크를 수행하도록 요청할 수 있습니다.

클라우드 서비스 인스턴스

서비스 ID와 유사하게, 인스턴스가 신뢰할 수 있는 리소스가 되도록 IBM Cloud 서비스 인스턴스의 클라우드 리소스 이름 (CRN) 을 지정할 수 있습니다. 해당 서비스 인스턴스는 동일한 계정 또는 다른 계정에 있을 수 있습니다. 현재 지원되는 유일한 시나리오는 아키텍처를 배치하기 위한 엔터프라이즈 프로젝트 에 대한 것입니다. 배치 가능한 아키텍처가 있는 프로젝트를 서비스 인스턴스로 한 계정에서 중앙 집중식으로 관리할 수 있습니다. 프로젝트의 CRN을 통해 신뢰를 설정하여 동일한 또는 다른 엔터프라이즈 계정 계층 구조의 다른 계정에 있는 신뢰할 수 있는 프로파일의 ID를 가정한 후 해당 자원을 사용하여 솔루션 패턴을 배치할 수 있습니다.

컴퓨팅 리소스가 있는 신뢰할 수 있는 프로파일

이론을 실제로 적용하기 위해 컨테이너화된 앱이 IBM Cloud 계정에서 작업을 수행할 수 있도록 권한을 부여합니다. 이 앱은 Kubernetes 클러스터에 배포됩니다. 이는 신뢰할 수 있는 프로파일을 사용하기 위해 신뢰를 설정하는 데 사용될 계산 자원 역할을 합니다. 여러 개의 탭이 열려 있는 웹 브라우저에서 다음 단계를 모두 수행할 수 있습니다. 지시된 대로 브라우저 탭을 열어 두어야 합니다.

보안상의 이유로 앱이 읽기 전용 모드에서 작동 중입니다. 배치된 자원의 목록을 수집하려고 시도합니다. 읽을 수 있는 자원을 판별하는 권한을 앱에 지정합니다. 또한 공용 인터넷이 아닌 Kubernetes 클러스터 내에서만 액세스할 수 있도록 앱을 배치합니다.

블로그 게시물 컨테이너를 신뢰할 수 있는 Cloud Identity 에서 동일한 시나리오에 대해 설명합니다.

컴퓨팅 리소스로서의 Kubernetes 클러스터

Kubernetes Service에서는 Kubernetes 클러스터에서 실행되는 컨테이너에 고가용성 앱을 배치하는 데 필요한 환경을 제공합니다.

이 튜토리얼에서 재사용하려는 기존 클러스터가 있는 경우 이 섹션을 건너뛰십시오. 이 튜토리얼의 나머지 부분에서 클러스터 이름은 mycluster-tpcr로 참조되므로, 클러스터 이름으로 간단히 대체하십시오. 1.21 의 최소 요구 버전인 Kubernetes 에 유의하십시오.

이 튜토리얼을 수행하는 데는 하나의 구역과 하나의 작업자 노드가 있고 사용 가능한 크기가 가장 작은(특성) 최소 클러스터로 충분합니다. 최소 Kubernetes 버전의 1.21 가 필요합니다. 클러스터를 작성할 때 적합한 버전을 선택해야 합니다.

Kubernetes 클러스터 를 열고 클러스터 작성을 클릭하십시오. 클러스터 유형에 따른 세부사항은 아래 참조된 문서를 참조하십시오. 요약:

  • 클릭 표준 계층 클러스터
  • VPC 인프라의 Kubernetes 의 경우 참조 문서 VPC 클러스터 작성 을 참조하십시오.
    • VPC 작성을 클릭하십시오.
      • VPC의 이름을 입력하세요.
      • 클러스터와 동일한 자원 그룹을 선택하십시오.
      • 작성을 클릭하십시오.
    • 작성하는 각 서브넷에 Public Gateway 를 연결하십시오.
      • 가상 프라이빗 클라우드 로 이동하십시오.
      • 클러스터에 사용되는 이전에 작성된 VPC를 클릭하십시오.
      • 서브넷 섹션으로 스크롤 다운하고 서브넷을 클릭하십시오.
      • Public Gateway 섹션에서 분리됨 을 클릭하여 상태를 연결됨으로 변경하십시오.
      • VPC 세부사항 페이지로 돌아가려면 브라우저 뒤로 단추를 클릭하십시오.
      • 이전 세 단계를 반복하여 퍼블릭 게이트웨이를 각 서브넷에 연결하십시오.
  • 클래식 인프라의 Kubernetes 에 대해서는 클래식 클러스터 작성 참조 문서를 참조하십시오.
  • 자원 그룹을 선택하십시오.
  • 하나를 제외한 모든 구역을 선택 취소하십시오.
  • 구역당 하나의 작업자 노드로 축소하십시오.
  • 가장 작은 작업자 풀 특성을 선택하십시오.
  • 클러스터 이름 의 경우 mycluster-tpcr 을 사용하십시오.
  • 이 튜토리얼을 완료한 후 삭제될 이 데모 클러스터의 모든 보안 옵션을 끕니다. 생성하는 다른 클러스터에 대해서도 이를 신중하게 평가하는 것이 중요합니다.

클러스터가 프로비저닝되면 브라우저 (클러스터 개요) 탭을 열어 두고 나중에 사용할 수 있도록 하십시오. 그럼에도 불구하고 다음 단계로 이동할 수 있다.

신뢰 프로파일 작성

  1. 새 브라우저 탭 (IAM 신뢰할 수 있는 프로파일) 에서 맨 위 탐색 관리 > 액세스 (IAM) 를 사용한 후 왼쪽에 있는 신뢰할 수 있는 프로파일 을 사용하여 신뢰할 수 있는 프로파일 개요로 이동하십시오. 그런 다음 새로운 신뢰 프로필을 만듭니다.
  2. TPwithCR이름 으로 사용하고 간단한 설명(예: Test trusted profile with compute resource) 을 입력하십시오. 그런 다음 계속을 클릭하십시오.
  3. 신뢰할 수 있는 엔티티 유형 선택 아래의 두 번째 양식 탭에서 계산 자원 을 선택하면 신뢰 관계 작성 대화 상자가 표시됩니다. 여기서 Kubernetes컴퓨팅 서비스 유형으로 선택하십시오.
  4. 다음으로 모든 서비스 자원 또는 특정 서비스 자원 중 하나를 결정할 수 있습니다.
    • 특정 자원 을 클릭하면 다음 양식 필드가 표시됩니다.
    • 인스턴스 입력 또는 선택에서 자원 추가를 클릭하십시오. 그런 다음 액세스 허용 필드에서 Kubernetes 클러스터 mycluster-tpcr 을 선택하십시오.
    • 그런 다음 네임스페이스의 값으로 tptest 를 입력하십시오. 서비스 계정 의 필드를 그대로 두고 기본값을 사용하십시오.
    • 계속을 클릭하여 완료하십시오.
  5. 그런 다음 액세스 정책을 클릭하십시오. 서비스 목록에서 모든 ID및 액세스 사용 서비스 를 선택하고 다음을 클릭하십시오. 모든 자원으로 이동하고 다음 을 다시 클릭한 후 뷰어를 선택하고 다음을 다시 클릭하십시오. 역할 및 조치섹션에서 서비스 액세스 에 대해 독자 를 선택하고 플랫폼 액세스에 대해 뷰어 를 선택하십시오. 완료되면 다음 을 클릭하고 마지막으로 추가를 클릭하십시오.
  6. 오른쪽에서 요약 을 검토한 후 표시된 신뢰 관계 및 나열된 액세스 권한으로 신뢰할 수 있는 프로파일을 작성 하십시오. 나중을 위해 브라우저 탭을 열린 상태로 두십시오.

액세스 그룹을 사용하여 액세스를 지정하는 것이 우수 사례입니다. 단순성을 위해 직접 액세스 정책을 통해 읽기 전용 액세스를 지정하도록 선택했습니다. 권장사항은 지정된 특권으로 액세스 그룹을 작성한 후 신뢰할 수 있는 프로파일을 구성원으로 만드는 것입니다.

앱 배치

Kubernetes 클러스터 및 신뢰할 수 있는 프로파일이 제 위치에 있는 경우에는 단순 테스트 앱을 배치해야 합니다. 앱 및 구성의 소스 코드는 GitHub 저장소 trusted-profile-enterprise-security에 있습니다. 배치에는 필요하지 않지만, 그럼에도 불구하고 작동하는 방식에 관심이 있을 수 있습니다.

  1. 브라우저 탭 클러스터 개요에서 클러스터가 완전히 배치되었는지 확인하십시오. 단일 노드 구성에서는 인그레스 상태가 경고를 보고할 수 있습니다. 브라우저를 새로 고치고 다른 확인 표시가 녹색으로 표시되어 있는지 확인하는 것이 좋습니다. 이 경우 Kubernetes 대시보드 를 클릭하면 새 브라우저 탭 (Kubernetes 대시보드) 이 열립니다.

  2. 왼쪽 상단에서 네임스페이스 선택기를 찾아 모든 네임스페이스로 전환하십시오.

  3. 오른쪽 상단에서 + 를 클릭하여 새 자원을 작성하십시오. 다음 컨텐츠를 텍스트 양식 입력에서 작성에 붙여넣으십시오.

    apiVersion: v1
    kind: Namespace
    metadata:
      name: tptest
      labels:
        name: tptest
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: trustedprofile-test
      namespace: tptest
    spec:
      ports:
      - port: 8080
        targetPort: 8080
        protocol: TCP
      type: ClusterIP
      selector:
        app: tptest
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: trustedprofile-test-deployment
      namespace: tptest
    spec:
      selector:
        matchLabels:
          app: tptest
      replicas: 1
      template:
        metadata:
          labels:
            app: tptest
        spec:
          containers:
          - name: tptest-container
            image: icr.io/solution-tutorials/tutorial-trusted-profile-enterprise-security:v1.0.3
            imagePullPolicy: Always
            ports:
            - containerPort: 8080
            volumeMounts:
            - mountPath: /var/run/secrets/tokens
              name: sa-token
          serviceAccountName: default
          volumes:
          - name: sa-token
            projected:
              sources:
              - serviceAccountToken:
                  path: sa-token
                  expirationSeconds: 3600
                  audience: iam
    

    그런 다음 업로드 를 클릭하여 앱에 대한 리소스를 작성하십시오. 여기에는 새 Kubernetes 네임스페이스 tptest, 배치 및 팟 (Pod) 이 있는 서비스가 포함됩니다.

    GitHub 의 위 YAML 구성에 대한 소스 코드를 찾을 수 있습니다.

  4. 왼쪽 탐색 열에서 배치 를 클릭하여 새 배치 trustedprofile-test-deployment 의 상태를 확인하십시오. 그런 다음, 동일한 탐색 열에서 팟 (Pod) 을 클릭하고 이름이 trustedprofile-test-deployment 로 시작하는 팟 (Pod) 을 확인하십시오. 상태가 녹색으로 표시되면 다음 섹션으로 이동하십시오.

신뢰할 수 있는 프로파일 테스트

신뢰할 수 있는 프로파일 및 실행 중인 앱이 있는 Kubernetes 클러스터를 사용하여 테스트할 시간입니다. 먼저 브라우저 기반 셸을 열어 명령을 실행하고, 컨테이너 로그용 탭과 IBM Cloud Logs 로그용 탭을 엽니다.

  1. 팟 (Pod) 이 있는 현재 활성 탭 Kubernetes 대시보드 에서 오른쪽에 세 개의 점이 있는 메뉴를 클릭하고 해당 메뉴에서 실행마우스 오른쪽 단추로 클릭 하십시오. 새 탭에서 링크를 열도록 선택하십시오 (컨테이너 쉘). 실행 중인 컨테이너에 대한 쉘을 엽니다. 여전히 브라우저 탭 Kubernetes 대시보드에서 세 개의 점 메뉴를 다시 클릭한 후 로그를 마우스 왼쪽 단추로 클릭하십시오. 새 세 개의 점 메뉴에서 자동으로 새로 고치기를 사용으로 설정하십시오.

    마지막으로 IBM Cloud Logs 서비스가 있는 탭을 열고 클라우드 로그 탭을 선택한 다음 감사 이벤트를 수신하는 인스턴스의 이름을 클릭합니다.

  2. 브라우저 탭 컨테이너 쉘의 쉘에서 다음 명령을 실행하여 앱을 테스트하십시오.

    curl -s localhost:8080
    

    위에서는 codeversionresult 와 함께 JSON 오브젝트를 리턴해야 합니다. Kubernetes 대시보드 탭에 로그와 함께 일부 새 로그 활동이 표시되어야 합니다. 그런 다음 컨테이너 쉘 탭에서 다음 명령을 실행하십시오.

    curl -s localhost:8080/api/listresources_crn | jq
    

    명령이 앱을 호출하여 계정의 리소스 목록을 검색하려고 하지만 신뢰할 수 있는 프로파일 이름이 제공되지 않았습니다. 결과는 오류 메시지가 있는 형식화된 JSON 오브젝트여야 합니다.

  3. 위의 명령을 반복하되, 이제 사용할 신뢰할 수 있는 프로파일을 지정하십시오.

    curl -s localhost:8080/api/listresources_crn?tpname=TPwithCR | jq
    

    이제 결과는 계정의 리소스에 대한 정보가 있는 형식화된 JSON 오브젝트여야 합니다. 가독성을 위해 자원 CRN만 리턴됩니다. 전체 오브젝트 세부사항을 보려면 localhost:8080/api/listresources 를 사용하십시오. 존재하지 않는 다른 신뢰할 수 있는 프로파일 이름을 시도하고 오류 메시지를 검사할 수도 있습니다.

    호출되면 앱은 먼저 계산 자원에 대한 토큰을 읽습니다. 그런 다음 지정된 신뢰할 수 있는 프로파일에 대해 토큰을 IAM 액세스 토큰으로 전환 합니다. 마지막으로 IBM Cloud 리소스 제어기 API 를 호출하여 서비스 인스턴스에 대한 정보를 검색합니다. 결과는 신뢰할 수 있는 프로파일의 구성된 특권에 따라 다릅니다. 관심이 있는 경우 앱 소스 코드를 검사하십시오.

  4. IBM Cloud Logs 브라우저 탭으로 전환하고 하단의 검색창을 사용하여 프로필이라는 용어를 찾습니다. 감사 이벤트 대상으로 구성된 인스턴스여야 합니다. It should return at least one line with IAM Identity Service: login.computeresource-token TPwithCR. Open the info panel to expand the record to examine details, look for the 개시자 section. 여기에는 요청에 사용된 신뢰할 수 있는 프로파일과 계산 자원에 대한 정보가 나열됩니다. authName Kubernetes 대시보드 브라우저 탭에서 배포와 일치해야 합니다.

    IBM Cloud Logs showing details of the trusted profile request
    Details in the activity log

  5. 이제 브라우저 탭 Kubernetes 대시보드 를 방문하여 컨테이너 로그를 확인하십시오. 이 앱은 자원 나열을 위해 인증하는 데 사용하는 JWT 액세스 토큰 에 대한 세부사항을 인쇄합니다. sub (주제) 를 포함하여 개별 키/값 쌍을 두 번 검사하십시오. 이는 신뢰할 수 있는 프로파일 및 계산 리소스와 관련되어 있습니다.

  6. TPwithCR 에 대한 구성을 사용하여 브라우저 탭 IAM 신뢰 프로파일 로 전환하십시오. 양식에서 액세스 탭을 클릭한 후 모든 ID및 액세스 사용 서비스에 대한 세 개의 점 메뉴에서 편집을 선택하십시오. 이제 TPwithCR에 대한 정책 편집을 표시해야 합니다. 자원 에 대해 편집 을 클릭하고 특정 자원을 선택하십시오. 지역속성 유형으로 선택하십시오 (예: 프랑크푸르트). 저장을 눌러 완료하십시오.

  7. 브라우저 탭 컨테이너 쉘 로 다시 이동하고 이 명령을 다시 실행하여 자원을 나열하십시오.

    curl -s localhost:8080/api/listresources?tpname=TPwithCR | jq
    

    결과는 계정에서 다른 리소스를 배치한 위치에 따라 위와 다를 수 있습니다. IBM Cloud Logs 로그Kubernetes 대시보드 브라우저 탭을 다시 방문하여 새 로그 활동을 확인합니다.

  8. 6단계로 돌아가서 액세스 정책을 다시 편집한 후 7단계로 다시 테스트할 수 있습니다. 액세스 정책을 편집하기 위한 몇 가지 아이디어는 모든 ID및 액세스 사용 서비스대신 지역을 추가하거나 특정 서비스로 제한하는 것입니다.

자원 제거

신뢰할 수 있는 프로파일 및 컴퓨팅 리소스를 사용하여 위의 시나리오 테스트를 완료하면 다음 단계를 수행하여 리소스를 제거할 수 있습니다.

  1. Kubernetes 클러스터를 삭제하려면 브라우저 탭 클러스터 개요의 맨 위 오른쪽에 있는 조치 를 클릭한 후 클러스터 삭제를 클릭하십시오.
  2. IAM 신뢰할 수 있는 프로필 탭에서 신뢰할 수 있는 프로필 TPwithCR 이 있는 경우 작업제거를 클릭하여 신뢰할 수 있는 프로필을 삭제합니다.

리소스에 따라 즉시 삭제되지 않고 보유될 수 있습니다(기본 7일 동안). 리소스를 영구적으로 삭제하여 재확보하거나 보유 기간 내에 리소스를 복원할 수 있습니다. 리소스 재확보 사용 방법은 이 문서를 참조하십시오.