11.3. Zero Trust Workload Identity Manager 릴리스 노트

지원되는 플러그인:

교차 클러스터 신뢰에는 두 개의 계층에서 페더레이션이 필요합니다.

이번 업데이트 이전에는 SpireOIDCDiscoveryProvider 또는 SpireServer CR(사용자 정의 리소스)에서 externalSecretRef TLS 인증서를 사용하여 관리 경로를 구성한 경우 Zero Trust Workload Identity Manager에서 참조된 시크릿을 읽을 수 있는 OpenShift Ingress 라우터 서비스 계정 권한을 부여하는 RoleBinding 을 생성하지 않았습니다. 그 결과 ManagedRouteUpdateFailed 조건으로 경로 조정에 실패하고 secret-reader,Role, RoleBinding CR을 수동으로 생성해야 했습니다. 이번 릴리스에서는 Zero Trust Workload Identity Manager가 필요한 Role 및 RoleBinding CR을 자동으로 조정하므로 라우터 서비스 계정이 externalSecretRef TLS 인증서에서 참조하는 보안에 액세스할 수 있습니다. 외부로 제공된 TLS 인증서를 사용하는 관리형 경로는 추가 수동 RBAC 단계 없이 조정됩니다.

(SPIRE-164)

이번 업데이트 이전에는 피연산자 오브젝트와 동일한 이름의 Kubernetes 리소스가 이미 포함된 클러스터에 Zero Trust Workload Identity Manager를 설치할 때 충돌을 보고하지 않고 초기 설치 중에 이러한 리소스를 조정 및 덮어썼습니다. 결과적으로 이름 충돌을 해결하기 전에 수동으로 생성되거나 타사 리소스를 예기치 않게 수정할 수 있었습니다. 이번 릴리스에서는 설치 중에 기존 리소스를 업데이트하기 전에 Zero Trust Workload Identity Manager가 app.kubernetes.io/managed-by 레이블을 확인합니다. Zero Trust Workload Identity Manager에서 일치하는 리소스를 관리하지 않으면 Zero Trust Workload Identity Manager가 ResourceConflict 상태 조건을 설정하고 리소스를 덮어쓰는 대신 조정을 중지합니다.

(SPIRE-340)

이번 업데이트 이전에는 Zero Trust Workload Identity Manager가 이미 실행 중인 후에도 해당 리소스가 Zero Trust Workload Identity Manager에 속하지 않은 경우에도 피연산자 컨트롤러에서 해당 리소스가 일치하는 이름으로 Kubernetes 리소스를 업데이트할 수 있었습니다. 이는 이름 충돌이 나중에 또는 app.kubernetes.io/managed-by: zero-trust-workload-identity-manager 레이블이 이전에 관리했던 리소스에서 제거된 경우 발생할 수 있습니다. 이번 릴리스에서는 각 피연산자 컨트롤러에서 업데이트를 적용하기 전에 모든 조정 주기에서 managed-by 레이블을 확인합니다. 라벨이 없으면 Zero Trust Workload Identity Manager가 사용자 정의 리소스에 ResourceConflict 상태 조건을 설정하고 충돌하는 오브젝트로 업데이트를 건너뜁니다. 피연산자 업데이트는 Zero Trust Workload Identity Manager가 현재 관리하는 리소스에 대해서만 진행됩니다.

(SPIRE-344)

이번 업데이트 이전에는 SPIRE Server StatefulSet 필드의 spire-server 및 spire-controller-manager 컨테이너는 둘 다 다른 컨테이너 포트에서 healthz 라는 포트를 선언했습니다. Kubernetes는 이를 Pod 내에서 중복 포트 이름으로 처리했으며, 경고를 발행했으며, 이름으로 포트를 선택한 서비스 또는 프로브가 잘못된 컨테이너를 대상으로 할 수 있었습니다. 이번 릴리스에서는 Zero Trust Workload Identity Manager에서 server-healthz 및 ctrlmgr-healthz 와 같은 고유한 포트 이름을 할당하고 활성 상태 프로브 및 준비 상태 프로브를 업데이트하여 해당 이름을 참조합니다. 이제 상태 점검 및 모니터링 구성이 의도한 컨테이너로 확인되었습니다.

(SPIRE-353)

이번 업데이트 이전에는 Operator 서브스크립션에서 CREATE_ONLY_MODE 를 false 로 설정하여 생성 전용 모드를 비활성화한 후 기본 ZeroTrustWorkloadIdentityManager CR의 CreateOnlyMode 조건이 CreateOnlyModeEnabled 이유와 함께 True 로 유지될 수 있었습니다. Zero Trust Workload Identity Manager는 서브스크립션의 CREATE_ONLY_MODE 환경 변수 대신 피연산자 상태의 조건을 설정했기 때문에 기본 CR 상태는 피연산자 조정이 다시 시작된 경우에도 create-only 모드가 비활성화되었음을 반영하지 않았습니다. 이번 릴리스에서는 Zero Trust Workload Identity Manager가 CREATE_ONLY_MODE 환경 변수에서 직접 기본 CR에 CreateOnlyMode 조건을 설정하고 create-only 모드가 꺼지면 CreateOnlyModeDisabled 이유 CreateOnlyModeDisabled로 업데이트합니다.

(SHARE-365)

이번 업데이트 이전에는 Zero Trust Workload Identity Manager 컨트롤러가 각 조정 주기 동안 CR(사용자 정의 리소스) 상태를 두 번 작성했습니다. CR 상태는 시작 부분에 SetInitialReconciliationStatus 사이클을 통해 작성되었으며, 결국 상태 관리자를 통해 다시 작성되었습니다. 정보자 캐시는 첫 번째 쓰기 후 오래된 ResourceVersion 을 반환할 수 있었기 때문에 HTTP 409 충돌 과 함께 지연된 상태 업데이트가 거부되었습니다. CreateOnlyMode 를 포함한 상태 조건은 Operator 서브스크립션의 구성을 변경한 후에도 예상 상태로 전환되지 않을 수 있습니다. 이번 릴리스에서는 컨트롤러가 조정이 끝날 때 단일 업데이트에서 상태를 적용하고 상태 업데이트 재시도 논리가 RetryOnConflict 계약을 준수합니다. 이제 create-only mode transitions를 포함한 CR 상태 업데이트가 완료되었습니다.

(SPIRE-506)