검색

17.2. 튜토리얼: AWS STS를 사용하는 ROSA에 대해 설명합니다.

download PDF

이 튜토리얼에서는 ROSA(Red Hat OpenShift Service on AWS)가 사용자의 AWS(Amazon Web Service) 계정의 리소스와 상호 작용할 수 있도록 하는 두 가지 옵션에 대해 간단히 설명합니다. SDS(Security Token Service)가 필요한 인증 정보를 얻기 위해 사용하는 구성 요소 및 프로세스에 대해 자세히 설명합니다. 또한 STS를 사용하는 ROSA가 더 안전하고 선호되는 방법인 이유를 검토합니다.

참고

이 콘텐츠는 현재 AWS STS를 사용하여 ROSA Classic을 다룹니다. AWS STS를 사용하는 호스팅된 컨트롤 플레인(HCP)이 있는 ROSA의 경우 AWS STS 및 HCP를 사용하는 ROSA에 대해 설명합니다.

이 튜토리얼은 다음을 수행합니다.

  • 배포 옵션 중 두 개를 열거합니다.

    • ROSA( IAM 사용자 포함)
    • STS를 사용하는 ROSA
  • 두 옵션의 차이점 설명
  • STS를 사용하는 ROSA가 왜 더 안전하고 선호되는 옵션에 대해 설명합니다.
  • STS를 사용하는 ROSA의 작동 방식 설명

17.2.1. ROSA를 배포하는 다양한 인증 정보 방법

ROSA의 일환으로 Red Hat은 AWS 계정의 인프라 리소스를 관리하고 필요한 권한을 부여해야 합니다. 현재 이러한 권한을 부여하는 방법은 다음 두 가지가 있습니다.

  • AdministratorAccess 정책으로 정적 IAM 사용자 인증 정보 사용

    이 튜토리얼은 "OSA with IAM Users"라고 합니다. 기본 인증 정보 방법이 아닙니다.

  • 수명이 짧은 동적 토큰과 함께 AWS STS 사용

    이 튜토리얼은 이 튜토리얼에서 "ROSA with STS"라고 합니다. 기본 인증 정보 방법입니다.

17.2.1.1. IAM 사용자와 함께 Rosa

ROSA가 처음 릴리스되었을 때 유일한 인증 정보 방법은 IAM 사용자가 ROSA였습니다. 이 방법은 ROSA를 사용하는 AWS 계정에서 필요한 리소스를 생성하기 위해 AdministratorAccess 정책을 통해 IAM 사용자에게 전체 액세스 권한을 부여합니다. 그런 다음 클러스터는 필요에 따라 인증 정보를 생성하고 확장할 수 있습니다.

17.2.1.2. STS를 사용하는 ROSA

STS를 사용하는 ROSA는 사용자에게 AWS 계정의 리소스에 대한 단기 액세스를 제한합니다. STS 메서드는 사전 정의된 역할 및 정책을 사용하여 IAM 사용자 또는 인증된 페더레이션 사용자에게 임시 최소 권한 권한을 부여합니다. 인증 정보는 일반적으로 요청 후 1시간 후에 만료됩니다. 만료되면 AWS에서 더 이상 인식되지 않으며 해당 API 요청에서 더 이상 계정 액세스 권한이 없습니다. 자세한 내용은 AWS 설명서 를 참조하십시오. STS를 사용하는 IAM 사용자 및 ROSA를 사용하는 ROSA가 모두 활성화되어 있지만 STS를 사용하는 ROSA가 선호되고 권장되는 옵션입니다.

17.2.2. STS 보안이 포함된 ROSA

몇 가지 중요한 구성 요소가 STS를 사용하는 ROSA를 IAM 사용자의 ROSA보다 더 안전하게 만듭니다.

  • 사용자가 미리 생성하는 명시적 및 제한된 역할 및 정책 집합입니다. 사용자는 요청된 모든 권한과 사용된 모든 역할을 알고 있습니다.
  • 서비스는 해당 권한 외부에서는 아무 작업도 수행할 수 없습니다.
  • 서비스가 작업을 수행해야 할 때마다 1시간 이내에 만료되는 인증 정보를 가져옵니다. 즉, 인증 정보를 교체하거나 취소할 필요가 없습니다. 또한 인증 정보 만료를 사용하면 인증 정보 누출 및 재사용 위험이 줄어듭니다.

17.2.3. AWS STS 설명

ROSA는 AWS STS를 사용하여 단기 보안 인증 정보가 있는 최소 권한 권한을 특정 및 분리된 IAM 역할에 부여합니다. 인증 정보는 AWS API 호출을 수행하는 각 구성 요소 및 클러스터와 관련된 IAM 역할과 연결됩니다. 이 방법은 클라우드 서비스 리소스 관리에서 최소 권한 및 보안 관행의 원칙에 맞게 조정됩니다. ROSA CLI(명령줄 인터페이스) 툴은 고유한 작업에 할당된 STS 역할 및 정책을 관리하고 OpenShift 기능의 일부로 AWS 리소스에 대해 작업을 수행합니다.

각 ROSA 클러스터에 대해 STS 역할 및 정책을 생성해야 합니다. 이를 더 쉽게하기 위해 설치 툴은 역할을 생성하는 데 필요한 모든 명령과 파일을 정책으로 제공하고 CLI가 역할 및 정책을 자동으로 생성할 수 있도록 하는 옵션을 제공합니다. 다른 --mode 옵션에 대한 자세한 내용은 사용자 지정을 사용하여 STS를 사용하여 ROSA 클러스터 생성 을 참조하십시오.

17.2.4. STS를 사용하여 ROSA와 관련된 구성 요소

  • AWS 인프라 - 클러스터에 필요한 인프라를 제공합니다. 실제 EC2 인스턴스, 스토리지 및 네트워킹 구성 요소를 포함합니다. 컴퓨팅 노드에 대해 지원되는 인스턴스 유형 및 컨트롤 플레인 및 인프라 노드 구성에 대해 프로비저닝된 AWS 인프라 를 보려면 AWS 컴퓨팅 유형을 참조하십시오.
  • AWS STS - 위의 인증 정보 방법 섹션을 참조하십시오.
  • OpenID Connect(OIDC) - 클러스터 Operator가 AWS로 인증하는 메커니즘을 제공하고, 신뢰 정책을 통해 클러스터 역할을 가정하고, STS에서 임시 인증 정보를 가져와 필요한 API 호출을 수행할 수 있도록 합니다.
  • 역할 및 정책 - 역할과 정책은 STS를 사용한 ROSA와 IAM 사용자와 ROSA의 주요 차이점 중 하나입니다. STS를 사용하는 ROSA의 경우 ROSA에서 사용하는 역할과 정책은 계정 전체 역할 및 정책 및 Operator 역할 및 정책으로 나뉩니다.

    정책에 따라 각 역할에 허용되는 작업이 결정됩니다. 개별 역할 및 정책에 대한 자세한 내용은 STS를 사용하는 ROSA 클러스터의 IAM 리소스 정보를 참조하십시오.

    • 계정 전체 역할은 다음과 같습니다.

      • ManagedOpenShift-Installer-Role
      • ManagedOpenShift-ControlPlane-Role
      • ManagedOpenShift-Worker-Role
      • ManagedOpenShift-Support-Role
    • 계정 전체 정책은 다음과 같습니다.

      • ManagedOpenShift-Installer-Role-Policy
      • ManagedOpenShift-ControlPlane-Role-Policy
      • ManagedOpenShift-Worker-Role-Policy
      • ManagedOpenShift-Support-Role-Policy
      • ManagedOpenShift-openshift-ingress-operator-cloud-credentials [1]
      • ManagedOpenShift-openshift-cluster-csi-drivers-ebs-cloud-credent [1]
      • ManagedOpenShift-openshift-cloud-network-config-controller-cloud [1]
      • ManagedOpenShift-openshift-machine-api-aws-cloud-credentials [1]
      • ManagedOpenShift-openshift-cloud-credential-operator-cloud-crede [1]
      • ManagedOpenShift-openshift-image-registry-installer-cloud-creden [1]

        1. 이 정책은 아래에 나열된 클러스터 Operator 역할에서 사용합니다. Operator 역할은 기존 클러스터 이름에 따라 달라지며 계정 전체 역할과 동시에 생성할 수 없기 때문에 두 번째 단계에서 생성됩니다.
    • Operator 역할은 다음과 같습니다.

      • <cluster-name\>-xxxx-openshift-cluster-csi-drivers-ebs-cloud-credent
      • <cluster-name\>-xxxx-openshift-cloud-network-config-controller-cloud
      • <cluster-name\>-xxxx-openshift-machine-api-aws-cloud-credentials
      • <cluster-name\>-xxxx-openshift-cloud-credential-operator-cloud-crede
      • <cluster-name\>-xxxx-openshift-image-registry-installer-cloud-creden
      • <cluster-name\>-xxxx-openshift-ingress-operator-cloud-credentials
    • 계정 전체 및 Operator 역할에 대한 신뢰 정책이 생성됩니다.

17.2.5. ROSA STS 클러스터 배포

아래 단계에 나열된 리소스를 처음부터 생성하지 않아야 합니다. ROSA CLI는 필요한 JSON 파일을 생성하고 필요한 명령을 출력합니다. ROSA CLI는 이 작업을 한 단계 더 진행하여 원하는 경우 명령을 실행할 수도 있습니다.

STS 클러스터를 사용하여 ROSA를 배포하는 단계

  1. 계정 전체 역할 및 정책을 생성합니다.
  2. 해당 계정 전체 역할에 권한 정책을 할당합니다.
  3. 클러스터를 생성합니다.
  4. Operator 역할 및 정책을 생성합니다.
  5. 해당 Operator 역할에 권한 정책을 할당합니다.
  6. OIDC 공급자를 생성합니다.

ROSA CLI에서 역할 및 정책을 자동으로 생성하거나 ROSA CLI에서 --mode 수동 또는 --mode 자동 플래그를 사용하여 수동으로 생성할 수 있습니다. 배포에 대한 자세한 내용은 사용자 지정으로 클러스터 생성 또는 클러스터 배포 튜토리얼을 참조하십시오.

17.2.6. STS 워크플로우를 사용하는 ROSA

사용자는 필요한 계정 전체 역할 및 계정 전체 정책을 생성합니다. 자세한 내용은 이 튜토리얼의 구성 요소 섹션을 참조하십시오. 역할 생성 중에 교차 계정 신뢰 정책이라는 신뢰 정책이 생성되어 Red Hat 소유 역할이 역할을 수행할 수 있습니다. EC2 인스턴스의 워크로드가 역할을 가정하고 인증 정보를 얻을 수 있는 EC2 서비스에 대한 신뢰 정책도 생성됩니다. 그러면 사용자는 각 역할에 해당 권한 정책을 할당할 수 있습니다.

계정 전체 역할 및 정책이 생성되면 사용자가 클러스터를 생성할 수 있습니다. 클러스터 생성이 시작되면 Operator 역할이 생성되어 클러스터 Operator가 AWS API 호출을 수행할 수 있습니다. 그런 다음 이러한 역할은 이전에 생성된 해당 권한 정책과 OIDC 공급자를 사용하는 신뢰 정책에 할당됩니다. Operator 역할은 궁극적으로 AWS 리소스에 액세스해야 하는 Pod를 나타내는 계정 전체 역할과 다릅니다. 사용자는 IAM 역할을 Pod에 연결할 수 없으므로 Operator와 Pod가 필요한 역할에 액세스할 수 있도록 OIDC 공급자를 사용하여 신뢰 정책을 생성해야 합니다.

사용자가 해당 정책 권한에 역할을 할당하면 최종 단계는 OIDC 공급자를 생성합니다.

클라우드 전문가가 생성 흐름에 대해 설명합니다.

새 역할이 필요한 경우 현재 Red Hat 역할을 사용하는 워크로드는 AWS 계정에서 역할을 수행하고, AWS STS에서 임시 인증 정보를 가져오고, 가정된 역할의 권한 정책에서 허용하는 대로 고객의 AWS 계정 내에서 API 호출을 사용하여 작업을 수행하기 시작합니다. 인증 정보는 임시이며 최대 1시간 동안 지속됩니다.

클라우드 전문가가 상위 수준에 대해 설명합니다.

전체 워크플로우는 다음 그래픽에 표시됩니다.

클라우드 전문가가 전체 흐름에 대해 설명합니다.

Operator는 다음 프로세스를 사용하여 작업을 수행하는 데 필요한 자격 증명을 가져옵니다. 각 Operator에는 Operator 역할, 권한 정책 및 OIDC 공급자가 있는 신뢰 정책이 할당됩니다. Operator는 역할이 포함된 JSON 웹 토큰과 토큰 파일(web_identity_token_file)을 OIDC 공급자에 전달하여 역할을 가정하고 공개 키로 서명된 키를 인증합니다. 공개 키는 클러스터 생성 중에 생성되어 S3 버킷에 저장됩니다. 그런 다음 Operator는 서명된 토큰 파일의 주체가 역할 신뢰 정책의 역할과 일치하는지 확인하여 OIDC 공급자가 허용된 역할만 가져올 수 있도록 합니다. 그런 다음 OIDC 공급자는 Operator가 AWS API 호출을 수행할 수 있도록 임시 인증 정보를 Operator에 반환합니다. 시각적 표현의 경우 아래를 참조하십시오.

클라우드 전문가 sts explained oidc op roles

17.2.7. STS 사용 사례가 있는 ROSA

클러스터 설치 시 노드 생성

Red Hat 설치 프로그램은 RH-Managed-OpenShift-Installer 역할 및 신뢰 정책을 사용하여 고객 계정에서 Managed-OpenShift-Installer-Role 역할을 가정합니다. 이 프로세스에서는 AWS STS에서 임시 인증 정보를 반환합니다. 설치 프로그램은 STS에서 방금 수신한 임시 인증 정보를 사용하여 필요한 API 호출을 시작합니다. 설치 프로그램은 AWS에 필요한 인프라를 생성합니다. 인증 정보는 1시간 이내에 만료되며 설치 프로그램은 더 이상 고객 계정에 액세스할 수 없습니다.

동일한 프로세스가 지원 케이스에도 적용됩니다. 지원 사례에서 Red Hat 사이트 안정성 엔지니어(SRE)는 설치 프로그램을 대체합니다.

클러스터 스케일링

machine-api-operatorAssumeRoleWithWebIdentity 를 사용하여 machine-api-aws-cloud-credentials 역할을 가정합니다. 그러면 클러스터 Operator의 순서에 따라 인증 정보가 수신됩니다. machine-api-operator 역할은 관련 API 호출을 통해 클러스터에 EC2 인스턴스를 추가할 수 있습니다.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.