4.8.3. 프라이빗 레지스트리에서 Operator용 이미지에 액세스
OLM(Operator Lifecycle Manager)에서 관리하는 Operator와 관련된 특정 이미지가 개인 레지스트리라고도 하는 인증된 컨테이너 이미지 레지스트리에서 호스팅되는 경우 OLM 및 OperatorHub는 기본적으로 이미지를 가져올 수 없습니다. 액세스를 활성화하려면 레지스트리의 인증 정보가 포함된 풀 시크릿을 생성할 수 있습니다. OLM은 카탈로그 소스에서 하나 이상의 가져오기 보안을 참조함으로써 Operator 및 카탈로그 네임스페이스에 보안을 배치하여 설치를 허용할 수 있습니다.
Operator 또는 해당 Operand에 필요한 기타 이미지에서도 프라이빗 레지스트리에 액세스해야 할 수 있습니다. 이 시나리오에서 OLM은 대상 테넌트 네임스페이스에 보안을 배치하지 않지만 필요한 액세스 권한을 활성화하기 위해 글로벌 클러스터 가져오기 보안 또는 개별 네임스페이스 서비스 계정에 인증 자격 증명을 추가할 수 있습니다.
OLM에서 관리하는 Operator에 적절한 가져오기 액세스 권한이 있는지 확인할 때는 다음 유형의 이미지를 고려해야 합니다.
- 인덱스 또는 카탈로그 이미지
-
CatalogSource
오브젝트는 이미지 레지스트리에서 호스팅되는 컨테이너 이미지로 패키지된 카탈로그 소스에 해당하는 인덱스 이미지 또는 카탈로그 이미지를 참조할 수 있습니다. 인덱스 이미지에서는 번들 형식 및 참조 번들 이미지를 사용하는 반면 카탈로그 이미지는 패키지 매니페스트 형식을 사용합니다. 인덱스 또는 카탈로그 이미지가 프라이빗 레지스트리에서 호스팅되는 경우 시크릿을 사용하여 가져오기 액세스 권한을 활성화할 수 있습니다. - 번들 이미지
- Operator 번들 이미지는 컨테이너 이미지로 패키지되어 Operator의 고유 버전을 나타내는 메타데이터와 매니페스트입니다. 카탈로그 소스에서 참조한 번들 이미지가 하나 이상의 프라이빗 레지스트리에서 호스팅되는 경우 보안을 사용하여 가져오기 액세스 권한을 활성화할 수 있습니다.
- Operator 및 Operand 이미지
카탈로그 소스에서 설치한 Operator에서 Operator 이미지 자체 또는 조사하는 Operand 이미지 중 하나로 프라이빗 이미지를 사용하는 경우 Operator가 설치되지 않습니다. 배포에 필수 레지스트리 인증에 대한 액세스 권한이 없기 때문입니다. 카탈로그 소스의 보안을 참조해도 OLM에서 Operand가 설치된 대상 테넌트 네임스페이스에 보안을 배치할 수 없습니다.
대신 클러스터의 모든 네임스페이스에 대한 액세스 권한을 제공하는
openshift-config
네임스페이스의 글로벌 클러스터 가져오기 보안에 인증 세부 정보를 추가하면 됩니다. 또는 전체 클러스터에 대한 액세스 권한을 제공할 수 없는 경우 대상 테넌트 네임스페이스의default
서비스 계정에 가져오기 보안을 추가할 수 있습니다.
사전 요구 사항
다음 중 한 개 이상이 프라이빗 레지스트리에서 호스팅됩니다.
- 인덱스 이미지 또는 카탈로그 이미지.
- Operator 번들 이미지.
- Operator 또는 Operand 이미지.
프로세스
필요한 각 프라이빗 레지스트리에 대해 보안을 생성합니다.
프라이빗 레지스트리에 로그인하여 레지스트리 자격 증명 파일을 생성하거나 업데이트합니다.
$ podman login <registry>:<port>
참고레지스트리 자격 증명의 파일 경로는 레지스트리에 로그인하는 데 사용하는 컨테이너 툴에 따라 다를 수 있습니다.
podman
CLI의 경우 기본 위치는${XDG_RUNTIME_DIR}/containers/auth.json
입니다.docker
CLI의 경우 기본 위치는/root/.docker/config.json
입니다.보안당 하나의 레지스트리에 대한 자격 증명만 포함하고 여러 레지스트리의 자격 증명은 별도의 보안에서 관리하는 것이 좋습니다. 이후 단계에서
CatalogSource
오브젝트에 여러 보안을 포함할 수 있으며 OpenShift Container Platform은 이미지를 가져오는 동안 사용할 수 있도록 보안을 단일 가상 자격 증명 파일에 병합합니다.기본적으로 레지스트리 자격 증명 파일은 둘 이상의 레지스트리에 대한 세부 정보를 저장할 수 있습니다. 파일의 현재 콘텐츠를 확인합니다. 예를 들면 다음과 같습니다.
두 레지스트리에 대한 자격 증명을 저장하는 파일
{ "auths": { "registry.redhat.io": { "auth": "FrNHNydQXdzclNqdg==" }, "quay.io": { "auth": "Xd2lhdsbnRib21iMQ==" } } }
이 파일은 이후 단계에서 보안을 생성하는 데 사용되므로 파일마다 하나의 레지스트리에만 세부 정보를 저장해야 합니다. 이 작업은 다음 방법 중 하나를 사용하여 수행할 수 있습니다.
-
podman logout <registry>
명령을 사용하여 원하는 레지스트리 하나만 남을 때까지 추가 레지스트리의 자격 증명을 제거합니다. 레지스트리 자격 증명 파일을 편집하고 레지스트리 세부 정보를 분리하여 여러 파일에 저장합니다. 예를 들면 다음과 같습니다.
하나의 레지스트리에 대한 자격 증명을 저장하는 파일
{ "auths": { "registry.redhat.io": { "auth": "FrNHNydQXdzclNqdg==" } } }
또 다른 레지스트리에 대한 자격 증명을 저장하는 파일
{ "auths": { "quay.io": { "auth": "Xd2lhdsbnRib21iMQ==" } } }
-
프라이빗 레지스트리의 인증 자격 증명 정보가 포함된
openshift-marketplace
네임스페이스에 보안을 생성합니다.$ oc create secret generic <secret_name> \ -n openshift-marketplace \ --from-file=.dockerconfigjson=<path/to/registry/credentials> \ --type=kubernetes.io/dockerconfigjson
이 단계를 반복하여 다른 필수 프라이빗 레지스트리에 대한 추가 보안을 생성하고
--from-file
플래그를 업데이트하여 다른 레지스트리 자격 증명 파일 경로를 지정합니다.
기존
CatalogSource
오브젝트를 생성하거나 업데이트하여 하나 이상의 보안을 참조합니다.apiVersion: operators.coreos.com/v1alpha1 kind: CatalogSource metadata: name: my-operator-catalog namespace: openshift-marketplace spec: sourceType: grpc secrets: 1 - "<secret_name_1>" - "<secret_name_2>" image: <registry>:<port>/<namespace>/<image>:<tag> displayName: My Operator Catalog publisher: <publisher_name> updateStrategy: registryPoll: interval: 30m
- 1
spec.secrets
섹션을 추가하고 필요한 보안을 지정합니다.
구독한 Operator에서 참조하는 Operator 또는 Operand 이미지에 프라이빗 레지스트리에 대한 액세스 권한이 필요한 경우 클러스터의 모든 네임스페이스 또는 개별 대상 테넌트 네임스페이스에 액세스 권한을 제공하면 됩니다.
클러스터의 모든 네임스페이스에 액세스 권한을 제공하려면
openshift-config
네임스페이스의 글로벌 클러스터 가져오기 보안에 인증 세부 정보를 추가합니다.주의클러스터 리소스는 클러스터의 사용성을 일시적으로 제한할 수 있는 새 글로벌 가져오기 보안에 맞게 조정해야 합니다.
글로벌 가져오기 보안에서
.dockerconfigjson
파일을 추출합니다.$ oc extract secret/pull-secret -n openshift-config --confirm
필요한 프라이빗 레지스트리 또는 레지스트리에 대한 인증 자격 증명을 사용하여
.dockerconfigjson
파일을 업데이트한 후 새 파일로 저장합니다.$ cat .dockerconfigjson | \ jq --compact-output '.auths["<registry>:<port>/<namespace>/"] |= . + {"auth":"<token>"}' \1 > new_dockerconfigjson
- 1
<registry>:<port>/<namespace>
를 프라이빗 레지스트리 세부 정보로 교체하고<token>
을 인증 자격 증명으로 교체합니다.
새 파일을 사용하여 글로벌 가져오기 보안을 업데이트합니다.
$ oc set data secret/pull-secret -n openshift-config \ --from-file=.dockerconfigjson=new_dockerconfigjson
개별 네임스페이스를 업데이트하려면 대상 테넌트 네임스페이스에 액세스해야 하는 Operator의 서비스 계정에 가져오기 보안을 추가합니다.
테넌트 네임스페이스에서
openshift-marketplace
용으로 생성한 보안을 다시 생성합니다.$ oc create secret generic <secret_name> \ -n <tenant_namespace> \ --from-file=.dockerconfigjson=<path/to/registry/credentials> \ --type=kubernetes.io/dockerconfigjson
테넌트 네임스페이스를 검색하여 Operator의 서비스 계정 이름을 확인합니다.
$ oc get sa -n <tenant_namespace> 1
- 1
- Operator가 개별 네임스페이스에 설치된 경우 해당 네임스페이스를 검색합니다. Operator가 모든 네임스페이스에 설치된 경우
openshift-operators
네임스페이스를 검색합니다.
출력 예
NAME SECRETS AGE builder 2 6m1s default 2 6m1s deployer 2 6m1s etcd-operator 2 5m18s 1
- 1
- 설치된 etcd Operator의 서비스 계정입니다.
Operator의 서비스 계정에 보안을 연결합니다.
$ oc secrets link <operator_sa> \ -n <tenant_namespace> \ <secret_name> \ --for=pull
추가 리소스
- 레지스트리 자격 증명에 사용되는 보안을 포함하여 보안 유형에 대한 자세한 내용은 보안이란?을 참조하십시오.
- 이러한 보안 변경이 미치는 영향에 대한 자세한 내용은 글로벌 클러스터 가져오기 보안 업데이트를 참조하십시오.
- 가져오기 보안을 네임스페이스별 서비스 계정에 연결하는 방법에 대한 자세한 내용은 Pod에서 다른 보안 레지스트리의 이미지를 참조하도록 허용을 참조하십시오.