2.4. SRE 및 서비스 계정 액세스
2.4.1. ID 및 액세스 관리
대부분의 SRE(사이트 안정성 엔지니어링) 팀은 자동화된 구성 관리를 통해 클러스터 Operator를 사용하여 수행됩니다.
Workload Identify Federation (WIF) 인증 유형으로 생성된 GCP(Google Cloud Platform) 클러스터의 OpenShift Dedicated에서는 SRE 액세스에 Operator를 사용하지 않습니다. 대신 SRE 계정 액세스에 필요한 필수 역할은 WIF 구성 생성의 일부로 sd-sre-platform-gcp-access 그룹에 할당되며 OpenShift Cluster Manager에서 클러스터를 배포하기 전에 유효성을 검사합니다. WIF 구성에 대한 자세한 내용은 추가 리소스를 참조하십시오.
2.4.1.1. 하위 프로세서
사용 가능한 하위 프로세서 목록은 Red Hat 고객 포털의 Red Hat 하위 프로세서 목록을 참조하십시오.
2.4.1.2. 모든 OpenShift Dedicated 클러스터에 대한 SRE 액세스
SRES는 프록시를 통해 OpenShift Dedicated 클러스터에 액세스합니다. 프록시는 로그인할 때 SREs에 대한 OpenShift Dedicated 클러스터에서 서비스 계정을 mints합니다. OpenShift Dedicated 클러스터에 대해 구성된 ID 공급자가 없으므로 SREs는 로컬 웹 콘솔 컨테이너를 실행하여 프록시에 액세스합니다. SRES는 클러스터 웹 콘솔에 직접 액세스하지 않습니다. SRES는 감사 가용성을 보장하기 위해 개별 사용자로 인증해야 합니다. 모든 인증 시도가 SIEM(Security Information and Event Management) 시스템에 기록됩니다.
2.4.1.3. OpenShift Dedicated에서 권한 있는 액세스 제어
Red Hat SRE는 OpenShift Dedicated 및 퍼블릭 클라우드 공급자 구성 요소에 액세스할 때 최소 권한 원칙을 따릅니다. 수동 SRE 액세스의 네 가지 기본 카테고리가 있습니다.
- 일반적인 2 단계 인증으로 Red Hat Customer Portal을 통한 SRE 관리자 액세스 권한 없음
- 정상적인 2 단계 인증으로 Red Hat 기업 SSO를 통한 SRE 관리자 액세스 및 권한 없는 고도.
- Red Hat SSO를 사용한 수동 승격인 OpenShift 승격. 모든 운영 SREs make에 대해 완전히 감사되고 관리 승인이 필요합니다.
- 클라우드 공급자 콘솔 또는 CLI 액세스를 위한 수동 승격인 클라우드 공급자 액세스 또는 승격. 액세스는 60분으로 제한되며 완전히 감사됩니다.
이러한 액세스 유형에는 각각 다른 구성 요소에 대한 액세스 수준이 있습니다.
| 구성 요소 | 일반적인 SRE 관리자 액세스(Red Hat 고객 포털) | 일반적인 SRE 관리자 액세스(Red Hat SSO) | OpenShift 고도 | 클라우드 공급자 액세스 |
|---|---|---|---|---|
| OpenShift Cluster Manager | R/W | 액세스 권한 없음 | 액세스 권한 없음 | 액세스 권한 없음 |
| OpenShift 웹 콘솔 | 액세스 권한 없음 | R/W | R/W | 액세스 권한 없음 |
| 노드 운영 체제 | 액세스 권한 없음 | 승격된 OS 및 네트워크 권한의 특정 목록입니다. | 승격된 OS 및 네트워크 권한의 특정 목록입니다. | 액세스 권한 없음 |
| AWS Console | 액세스 권한 없음 | 액세스 권한은 없지만 클라우드 공급자 액세스를 요청하는 데 사용되는 계정입니다. | 액세스 권한 없음 | SRE ID를 사용하는 모든 클라우드 공급자 권한. |
2.4.1.4. 클라우드 인프라 계정에 대한 SRE 액세스
Red Hat 직원은 일상적인 OpenShift Dedicated 작업 과정에서 클라우드 인프라 계정에 액세스하지 않습니다. 긴급 문제 해결을 위해 Red Hat SRE는 클라우드 인프라 계정에 액세스하기 위한 잘 정의되고 감사 가능한 절차가 있습니다.
AWS에서 SREs는 AWS STS(보안 토큰 서비스)를 사용하여 BYOCAdminAccess 사용자에 대한 단기 AWS 액세스 토큰을 생성합니다. STS 토큰에 대한 액세스는 감사 기록 및 개별 사용자로 추적할 수 있습니다. BYOCAdminAccess 에는 AdministratorAccess IAM 정책이 연결되어 있습니다.
Google Cloud에서 SREs 액세스 리소스는 Red Hat SAML ID 공급자(IDP)에 대해 인증됩니다. IDP는 라이브 만료 기간이 있는 토큰을 인증합니다. 토큰 발행은 기업 Red Hat IT에서 감사할 수 있으며 개별 사용자와 다시 연결됩니다.
2.4.1.5. Red Hat 지원 액세스
Red Hat CEE 팀의 구성원은 일반적으로 클러스터의 일부에 대한 읽기 전용 액세스 권한을 갖습니다. 특히 CEE는 핵심 및 제품 네임스페이스에 대한 액세스를 제한하고 고객 네임스페이스에 대한 액세스 권한이 없습니다.
| Role | 코어 네임스페이스 | 계층화된 제품 네임스페이스 | 고객 네임스페이스 | 클라우드 인프라 계정* |
|---|---|---|---|---|
| OpenShift SRE | 읽기: 모두 쓰기: Very 제한된 [1] | 읽기: 모두 쓰기: 없음 | 읽기: None[2] 쓰기: 없음 | 읽기: 모두 [3] 모두 쓰기 [3] |
| CEE | 읽기: 모두 쓰기: 없음 | 읽기: 모두 쓰기: 없음 | 읽기: None[2] 쓰기: 없음 | 읽기: 없음 쓰기: 없음 |
| 고객 관리자 | 읽기: 없음 쓰기: 없음 | 읽기: 없음 쓰기: 없음 | 읽기: 모두 쓰기: 모두 | 읽기: Limited[4] 쓰기: 제한됨[4] |
| 고객 사용자 | 읽기: 없음 쓰기: 없음 | 읽기: 없음 쓰기: 없음 | 읽기: 제한됨[5] 쓰기: 제한됨[5] | 읽기: 없음 쓰기: 없음 |
| 다른 모든 사람 | 읽기: 없음 쓰기: 없음 | 읽기: 없음 쓰기: 없음 | 읽기: 없음 쓰기: 없음 | 읽기: 없음 쓰기: 없음 |
Cloud Infrastructure Account는 기본 AWS 또는 Google Cloud 계정을 나타냅니다.
- 실패한 배포, 클러스터 업그레이드, 잘못된 작업자 노드 교체와 같은 일반적인 사용 사례 처리로 제한됩니다.
- Red Hat 직원은 기본적으로 고객 데이터에 액세스할 수 없습니다.
- 클라우드 인프라 계정에 대한 SRE 액세스는 문서화된 문제 발생 시 예외적인 문제 해결을 위한 "중요" 절차입니다.
- 고객 관리자는 Cloud Infrastructure Access를 통해 클라우드 인프라 계정 콘솔에 대한 액세스가 제한되어 있습니다.
- 고객 관리자가 RBAC를 통해 부여한 항목 및 사용자가 생성한 네임스페이스로 제한됩니다.
2.4.1.6. 고객 액세스
고객 액세스는 고객이 생성한 네임스페이스 및 고객 관리자 역할에서 RBAC를 사용하여 부여하는 권한으로 제한됩니다. 기본 인프라 또는 제품 네임스페이스에 대한 액세스는 일반적으로 cluster-admin 액세스없이 허용되지 않습니다. 고객 액세스 및 인증에 대한 자세한 내용은 설명서의 인증 이해 섹션에서 확인할 수 있습니다.
2.4.1.7. 액세스 승인 및 검토
새로운 SRE 사용자 액세스에는 관리 승인이 필요합니다. 분리되거나 전송된 SRE 계정은 자동화된 프로세스를 통해 권한 있는 사용자로 제거됩니다. 또한 SRE는 권한 있는 사용자 목록의 관리 서명을 포함하여 정기적인 액세스 검토를 수행합니다.
2.4.2. SRE 클러스터 액세스
OpenShift Dedicated 클러스터에 대한 SRE 액세스는 여러 필수 인증 계층을 통해 제어되며, 모두 엄격한 회사 정책에 의해 관리됩니다. 모든 인증 시도는 클러스터에 액세스하려고 하며 클러스터 내의 변경 사항은 해당 작업을 담당하는 SRE의 특정 계정 ID와 함께 감사 로그 내에 기록됩니다. 이러한 감사 로그는 고객의 클러스터에 대한 모든 변경 사항이 Red Hat의 관리 서비스 지침을 구성하는 엄격한 정책과 절차를 준수하는지 확인하는 데 도움이 됩니다.
아래에 제시된 정보는 SRE가 고객의 클러스터에 액세스하기 위해 수행해야 하는 프로세스에 대한 개요입니다.
- SRE는 Red Hat SSO(Cloud Services)에서 새로 고침 ID 토큰을 요청합니다. 이 요청이 인증됩니다. 토큰은 15분 동안 유효합니다. 토큰이 만료되면 토큰을 다시 새로고침하여 새 토큰을 수신할 수 있습니다. 새 토큰으로 새로 고침하는 기능은 무제한입니다. 그러나 새 토큰으로 새로 고침하는 기능은 비활성화 후 30일 후에 취소됩니다.
- SRE는 Red Hat VPN에 연결됩니다. VPN에 대한 인증은 Red Hat Corporate Identity and Access Management 시스템(RH IAM)에 의해 완료됩니다. RH IAM을 사용하면 SRE는 다중 요소이며 그룹 및 기존 온보딩 및 오프보딩 프로세스를 통해 조직당 내부적으로 관리할 수 있습니다. SRE가 인증 및 연결되면 SRE가 클라우드 서비스 플릿 관리 플레인에 액세스할 수 있습니다. 클라우드 서비스 플릿 관리 플레인을 변경하려면 많은 승인 계층이 필요하며 엄격한 회사 정책에 의해 유지 관리됩니다.
- 권한 부여가 완료되면 플릿 관리 플레인에 SRE 로그가 기록되고 플릿 관리 플레인에서 생성한 서비스 계정 토큰이 수신됩니다. 토큰은 15분 동안 유효합니다. 토큰이 더 이상 유효하지 않으면 삭제됩니다.
플릿 관리 플레인에 대한 액세스 권한이 부여된 SRE는 네트워크 구성에 따라 다양한 방법을 사용하여 클러스터에 액세스합니다.
- 프라이빗 또는 공용 클러스터에 액세스: 포트 6443에서 암호화된 HTTP 연결을 사용하여 요청이 특정 NLB(Network Load Balancer)를 통해 전송됩니다.
- PrivateLink 클러스터에 액세스: 요청이 Red Hat Transit Gateway로 전송되어 리전당 Red Hat VPC에 연결됩니다. 요청을 수신하는 VPC는 대상 프라이빗 클러스터 리전에 따라 달라집니다. VPC에는 고객의 PrivateLink 클러스터에 대한 PrivateLink 엔드포인트가 포함된 프라이빗 서브넷이 있습니다.
2.4.3. 서비스 계정에서 SRE 보유 프로젝트에서 AWS IAM 역할을 가정하는 방법
AWS STS(Security Token Service)를 사용하는 OpenShift Dedicated 클러스터를 설치하면 클러스터별 Operator AWS IAM(Identity and Access Management) 역할이 생성됩니다. 이러한 IAM 역할을 사용하면 OpenShift Dedicated 클러스터 Operator가 핵심 OpenShift 기능을 실행할 수 있습니다.
클러스터 Operator는 서비스 계정을 사용하여 IAM 역할을 가정합니다. 서비스 계정에서 IAM 역할을 가정하면 서비스 계정에서 클러스터 Operator의 Pod에서 사용할 임시 STS 인증 정보가 제공됩니다. assumed 역할에 필요한 AWS 권한이 있는 경우 서비스 계정에서 Pod에서 AWS SDK 작업을 실행할 수 있습니다.
SRE 보유 프로젝트에서 AWS IAM 역할을 가정하기 위한 워크플로우
다음 다이어그램은 SRE 보유 프로젝트에서 AWS IAM 역할을 가정하는 워크플로우를 보여줍니다.
그림 2.1. SRE 보유 프로젝트에서 AWS IAM 역할을 가정하기 위한 워크플로우
워크플로우에는 다음 단계가 있습니다.
클러스터 Operator가 실행하는 각 프로젝트 내에서 Operator의 배포 사양에는 예상 서비스 계정 토큰에 대한 볼륨 마운트와 Pod에 대한 AWS 인증 정보 구성이 포함된 시크릿이 있습니다. 토큰은 오디언스 바인딩 및 시간 바인딩입니다. OpenShift Dedicated는 매시간 새 토큰을 생성하고 AWS SDK는 AWS 인증 정보 구성이 포함된 마운트된 시크릿을 읽습니다. 이 구성에는 마운트된 토큰 및 AWS IAM 역할 ARN의 경로가 있습니다. 시크릿의 인증 정보 구성에는 다음이 포함됩니다.
-
AWS SDK 작업을 실행하는 데 필요한 권한이 있는 IAM 역할에 대한 ARN이 있는
$AWS_ARN_ROLE변수. -
서비스 계정의 OpenID Connect(OIDC) 토큰으로 Pod의 전체 경로가 있는
$AWS_LOAD_IDENTITY_TOKEN_FILE변수. 전체 경로는/var/run/secrets/openshift/serviceaccount/token입니다.
-
AWS SDK 작업을 실행하는 데 필요한 권한이 있는 IAM 역할에 대한 ARN이 있는
-
클러스터 Operator에서 AWS IAM 역할로 간주하여 AWS IAM 역할(예: EC2)을 가정해야 하는 경우 Operator에서 실행되는 AWS SDK 클라이언트 코드는
AssumeRoleWithWebIdentityAPI 호출을 호출합니다. OIDC 토큰은 Pod에서 OIDC 공급자로 전달됩니다. 다음 요구 사항이 충족되면 공급자는 서비스 계정 ID를 인증합니다.
- ID 서명은 유효하며 개인 키로 서명됩니다.
sts.amazonaws.com대상은 OIDC 토큰에 나열되며 OIDC 공급자에 구성된 대상과 일치합니다.참고STS 클러스터를 사용하는 OpenShift Dedicated에서는 설치 중에 OIDC 공급자가 생성되고 기본적으로 서비스 계정 발행자로 설정됩니다.
sts.amazonaws.com대상은 OIDC 공급자에 기본적으로 설정됩니다.- OIDC 토큰이 만료되지 않았습니다.
- 토큰의 발행자 값에는 OIDC 공급자의 URL이 있습니다.
- 프로젝트 및 서비스 계정이 가정 중인 IAM 역할에 대한 신뢰 정책 범위에 있는 경우 권한 부여가 성공합니다.
- 인증 및 권한 부여에 성공하면 AWS 액세스 토큰, 시크릿 키 및 세션 토큰 형식의 임시 AWS STS 인증 정보가 서비스 계정에서 사용할 수 있도록 Pod에 전달됩니다. 인증 정보를 사용하면 서비스 계정에 IAM 역할에 활성화된 AWS 권한이 일시적으로 부여됩니다.
- 클러스터 Operator가 실행되면 Pod에서 AWS SDK를 사용하는 Operator는 예상 서비스 계정에 대한 경로가 있는 시크릿과 AWS IAM 역할 ARN을 사용하여 OIDC 공급자에 대해 인증합니다. OIDC 공급자는 AWS API에 대한 인증에 대한 임시 STS 자격 증명을 반환합니다.
2.4.4. 추가 리소스
WIF 구성 및 SRE 액세스 역할에 대한 자세한 내용은 WIF 구성 생성을 참조하십시오.
