3.6. 입력 보안 및 구성 맵
입력 보안 및 구성 맵의 콘텐츠가 빌드 출력 컨테이너 이미지에 표시되지 않도록 Docker 빌드 및 source-to-image 빌드 전략의 빌드 볼륨을 사용합니다.
일부 시나리오에서는 빌드 작업을 수행하려면 종속 리소스에 액세스하기 위해 자격 증명 또는 기타 구성 데이터가 필요합니다. 그러나 이러한 정보가 소스 제어에 배치되는 것은 바람직하지 않습니다. 이러한 용도를 위해 입력 보안 및 입력 구성 맵을 정의할 수 있습니다.
예를 들어 Maven으로 Java 애플리케이션을 빌드할 때 개인 키로 액세스할 수 있는 Maven Central 또는 JCenter의 개인 미러를 설정할 수 있습니다. 해당 개인 미러에서 라이브러리를 다운로드하려면 다음을 제공해야 합니다.
-
미러의 URL 및 연결 설정으로 구성된
settings.xml
파일 -
설정 파일에서 참조하는 개인 키(예:
~/.ssh/id_rsa
)
보안상의 이유로 애플리케이션 이미지에 자격 증명을 노출해서는 안 됩니다.
이 예제에서는 Java 애플리케이션을 설명하지만 /etc/ssl/certs
디렉터리, API 키 또는 토큰, 라이선스 파일 등에 SSL 인증서를 추가하는 데 동일한 접근 방식을 사용할 수 있습니다.
3.6.1. 비밀이란? 링크 복사링크가 클립보드에 복사되었습니다!
Secret
오브젝트 유형에서는 암호, OpenShift Container Platform 클라이언트 구성 파일, dockercfg
파일, 개인 소스 리포지토리 자격 증명 등과 같은 중요한 정보를 보유하는 메커니즘을 제공합니다. 보안은 Pod에서 중요한 콘텐츠를 분리합니다. 볼륨 플러그인을 사용하여 컨테이너에 보안을 마운트하거나 시스템에서 시크릿을 사용하여 Pod 대신 작업을 수행할 수 있습니다.
YAML 보안 오브젝트 정의
3.6.1.1. 보안 속성 링크 복사링크가 클립보드에 복사되었습니다!
주요 속성은 다음과 같습니다.
- 보안 데이터는 정의와는 별도로 참조할 수 있습니다.
- 보안 데이터 볼륨은 임시 파일 저장 기능(tmpfs)에 의해 지원되며 노드에 저장되지 않습니다.
- 보안 데이터는 네임스페이스 내에서 공유할 수 있습니다.
3.6.1.2. 보안 유형 링크 복사링크가 클립보드에 복사되었습니다!
type
필드의 값은 보안의 키 이름과 값의 구조를 나타냅니다. 유형을 사용하면 보안 오브젝트에 사용자 이름과 키를 적용할 수 있습니다. 검증을 수행하지 않으려면 기본값인 opaque
유형을 사용합니다.
보안 데이터에 특정 키 이름이 있는지 확인하기 위해 서버 측 최소 검증을 트리거하려면 다음 유형 중 하나를 지정합니다.
-
kubernetes.io/service-account-token
. 서비스 계정 토큰을 사용합니다. -
kubernetes.io/dockercfg
. 필수 Docker 자격 증명으로.dockercfg
파일을 사용합니다. -
kubernetes.io/dockerconfigjson
. 필수 Docker 자격 증명으로.docker/config.json
파일을 사용합니다. -
kubernetes.io/basic-auth
. 기본 인증에 사용합니다. -
kubernetes.io/ssh-auth
. SSH 키 인증에 사용합니다. -
kubernetes.io/tls
. TLS 인증 기관에 사용합니다.
검증을 수행하지 않으려면 type= Opaque
를 지정합니다. 즉 보안에서 키 이름 또는 값에 대한 규칙을 준수하도록 요청하지 않습니다. opaque
보안에는 임의의 값을 포함할 수 있는 비정형 key:value
쌍을 사용할 수 있습니다.
example.com/my-secret-type
과 같은 다른 임의의 유형을 지정할 수 있습니다. 이러한 유형은 서버 측에 적용되지 않지만 보안 생성자가 해당 유형의 키/값 요구 사항을 준수하도록 의도했음을 나타냅니다.
3.6.1.3. 보안 업데이트 링크 복사링크가 클립보드에 복사되었습니다!
보안 값을 수정해도 이미 실행 중인 Pod에서 사용하는 값은 동적으로 변경되지 않습니다. 보안을 변경하려면 동일한 PodSpec
을 사용하는 일부 경우에서 원래 Pod를 삭제하고 새 Pod를 생성해야 합니다.
보안 업데이트 작업에서는 새 컨테이너 이미지를 배포하는 것과 동일한 워크플로를 따릅니다. kubectl rolling-update
명령을 사용할 수 있습니다.
보안의 resourceVersion
값은 참조 시 지정되지 않습니다. 따라서 Pod가 시작되는 동시에 보안이 업데이트되는 경우 Pod에 사용되는 보안의 버전이 정의되지 않습니다.
현재는 Pod가 생성될 때 사용된 보안 오브젝트의 리소스 버전을 확인할 수 없습니다. 컨트롤러에서 이전 resourceVersion
을 사용하여 재시작할 수 있도록 Pod에서 이 정보를 보고하도록 계획되어 있습니다. 그동안 기존 보안 데이터를 업데이트하지 말고 고유한 이름으로 새 보안을 생성하십시오.
3.6.2. 보안 생성 링크 복사링크가 클립보드에 복사되었습니다!
먼저 보안을 생성한 후 해당 보안을 사용하는 Pod를 생성해야 합니다.
보안 생성 시 다음을 수행합니다.
- 보안 데이터를 사용하여 보안 오브젝트를 생성합니다.
- Pod 서비스 계정을 업데이트하여 보안에 대한 참조를 허용합니다.
-
보안을 환경 변수로 사용하거나
secret
볼륨을 사용하여 파일로 사용하는 Pod를 생성합니다.
프로세스
JSON 또는 YAML 파일에서 보안 오브젝트를 생성하려면 다음 명령을 입력합니다.
oc create -f <filename>
$ oc create -f <filename>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 예를 들어 로컬
.docker/config.json
파일에서 보안을 생성할 수 있습니다.oc create secret generic dockerhub \ --from-file=.dockerconfigjson=<path/to/.docker/config.json> \ --type=kubernetes.io/dockerconfigjson
$ oc create secret generic dockerhub \ --from-file=.dockerconfigjson=<path/to/.docker/config.json> \ --type=kubernetes.io/dockerconfigjson
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이 명령은
dockerhub
라는 보안의 JSON 사양을 생성한 후 오브젝트를 생성합니다.YAML Opaque Secret 오브젝트 정의
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 불투명 보안을 지정합니다.
Docker 구성 JSON 파일 시크릿 오브젝트 정의
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.6.3. 보안 사용 링크 복사링크가 클립보드에 복사되었습니다!
보안을 생성한 후에는 해당 보안을 참조하는 Pod를 생성하고 로그를 가져오고 해당 Pod를 삭제할 수 있습니다.
프로세스
다음 명령을 입력하여 보안을 참조할 Pod를 생성합니다.
oc create -f <your_yaml_file>.yaml
$ oc create -f <your_yaml_file>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 로그를 가져옵니다.
oc logs secret-example-pod
$ oc logs secret-example-pod
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 Pod를 삭제합니다.
oc delete pod secret-example-pod
$ oc delete pod secret-example-pod
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.6.4. 입력 보안 및 구성 맵 추가 링크 복사링크가 클립보드에 복사되었습니다!
소스 제어에 의존하지 않고 인증 정보 및 기타 구성 데이터를 빌드에 제공하기 위해 입력 보안 및 입력 구성 맵을 정의할 수 있습니다.
일부 시나리오에서는 빌드 작업을 수행하려면 종속 리소스에 액세스하기 위해 인증 정보 또는 기타 구성 데이터가 필요합니다. 해당 정보를 소스 제어에 배치하지 않고 사용할 수 있도록 입력 보안 및 입력 구성 맵을 정의할 수 있습니다.
프로세스
입력 보안이나 구성 맵 또는 둘 다를 기존 BuildConfig
오브젝트에 추가하려면 다음을 수행합니다.
ConfigMap
오브젝트가 없는 경우 다음 명령을 입력하여 생성합니다.oc create configmap settings-mvn \ --from-file=settings.xml=<path/to/settings.xml>
$ oc create configmap settings-mvn \ --from-file=settings.xml=<path/to/settings.xml>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 그러면
settings-mvn
이라는 새 구성 맵이 생성됩니다. 이 맵에는settings.xml
파일의 일반 텍스트 내용이 포함됩니다.작은 정보다음 YAML을 적용하여 구성 맵을 만들 수 있습니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Secret
오브젝트가 없는 경우 다음 명령을 입력하여 생성합니다.oc create secret generic secret-mvn \ --from-file=ssh-privatekey=<path/to/.ssh/id_rsa> \ --type=kubernetes.io/ssh-auth
$ oc create secret generic secret-mvn \ --from-file=ssh-privatekey=<path/to/.ssh/id_rsa> \ --type=kubernetes.io/ssh-auth
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 그러면
secret-mvn
이라는 새 보안이 생성됩니다. 이 보안에는id_rsa
개인 키의 base64 인코딩 콘텐츠가 포함됩니다.작은 정보다음 YAML을 적용하여 입력 보안을 생성할 수 있습니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같이 기존
BuildConfig
오브젝트의source
섹션에 구성 맵과 보안을 추가합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 새
BuildConfig
오브젝트에 시크릿 및 구성 맵을 포함하려면 다음 명령을 입력합니다.oc new-build \ openshift/wildfly-101-centos7~https://github.com/wildfly/quickstart.git \ --context-dir helloworld --build-secret “secret-mvn” \ --build-config-map "settings-mvn"
$ oc new-build \ openshift/wildfly-101-centos7~https://github.com/wildfly/quickstart.git \ --context-dir helloworld --build-secret “secret-mvn” \ --build-config-map "settings-mvn"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 빌드 중에 빌드 프로세스는
settings.xml
및id_rsa
파일을 소스 코드가 있는 디렉터리에 복사합니다. OpenShift Container Platform S2I 빌더 이미지의 경우 이 디렉터리는Dockerfile
에WORKDIR
명령을 사용하여 설정하는 이미지 작업 디렉터리입니다. 다른 디렉터리를 지정하려면 정의에destinationDir
을 추가합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 새
BuildConfig
오브젝트를 생성할 때 대상 디렉터리를 지정할 수도 있습니다.oc new-build \ openshift/wildfly-101-centos7~https://github.com/wildfly/quickstart.git \ --context-dir helloworld --build-secret “secret-mvn:.ssh” \ --build-config-map "settings-mvn:.m2"
$ oc new-build \ openshift/wildfly-101-centos7~https://github.com/wildfly/quickstart.git \ --context-dir helloworld --build-secret “secret-mvn:.ssh” \ --build-config-map "settings-mvn:.m2"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 두 경우 모두
settings.xml
파일은 빌드 환경의./.m2
디렉터리에 추가되고id_rsa
키는./.ssh
디렉터리에 추가됩니다.
3.6.5. S2I(Source-to-Image) 전략 링크 복사링크가 클립보드에 복사되었습니다!
Source
전략을 사용하면 정의된 모든 입력 보안이 해당 destinationDir
에 복사됩니다. destinationDir
을 비워 두면 보안이 빌더 이미지의 작업 디렉터리에 배치됩니다.
destinationDir
이 상대 경로인 경우 동일한 규칙이 사용됩니다. 보안은 이미지 작업 디렉터리의 상대 경로에 배치됩니다. destinationDir
경로의 최종 디렉터리가 빌더 이미지에 없는 경우 해당 디렉터리가 생성됩니다. destinationDir
의 선행 디렉터리가 모두 존재해야 합니다. 없는 경우 오류가 발생합니다.
입력 보안은 전역 쓰기 가능으로 추가되고 0666
권한이 있으며 assemble
스크립트 실행 후 크기가 0으로 잘립니다. 즉 보안 파일은 결과 이미지에 존재하지만 보안상의 이유로 비어 있습니다.
assemble
스크립트가 완료되면 입력 구성 맵이 잘리지 않습니다.
3.6.6. Docker 전략 링크 복사링크가 클립보드에 복사되었습니다!
docker 전략을 사용하는 경우 Dockerfile의 ADD
및 COPY
명령을 사용하여 정의된 모든 입력 보안을 컨테이너 이미지에 추가할 수 있습니다.
보안의 destinationDir
을 지정하지 않으면 Dockerfile이 있는 동일한 디렉터리로 파일이 복사됩니다. 상대 경로를 destinationDir
로 지정하면 보안이 Dockerfile 위치와 상대되는 해당 디렉터리에 복사됩니다. 그러면 Docker 빌드 작업에서 빌드 중 사용하는 컨텍스트 디렉터리의 일부로 보안 파일을 사용할 수 있습니다.
보안 및 구성 맵 데이터를 참조하는 Dockerfile의 예
일반적으로 사용자는 해당 이미지에서 실행되는 컨테이너에 보안이 표시되지 않도록 최종 애플리케이션 이미지에서 입력 보안을 제거합니다. 그러나 보안은 추가된 계층에 있는 이미지 자체에 계속 있습니다. 이 제거는 Dockerfile 자체에 포함됩니다.
입력 보안 및 구성 맵의 콘텐츠가 빌드 출력 컨테이너 이미지에 표시되지 않도록 하려면 Docker 빌드 전략의 빌드 볼륨을 대신 사용합니다.
3.6.7. 사용자 정의 전략 링크 복사링크가 클립보드에 복사되었습니다!
사용자 정의 전략을 사용하는 경우 정의된 입력 보안 및 구성 맵을 /var/run/secrets/openshift.io/build
디렉터리의 빌더 컨테이너에서 모두 사용할 수 있습니다. 사용자 정의 빌드 이미지에서는 이러한 보안 및 구성 맵을 적절하게 사용해야 합니다. 사용자 정의 전략을 사용하면 사용자 정의 전략 옵션에 설명된 대로 보안을 정의할 수 있습니다.
기존 전략 보안과 입력 보안은 기술적으로 차이가 없습니다. 하지만 빌더 이미지는 빌드 사용 사례에 따라 해당 항목을 구분하고 다르게 사용할 수 있습니다.
입력 보안은 항상 /var/run/secrets/openshift.io/build
디렉터리에 마운트되거나 빌더에서 전체 빌드 오브젝트를 포함하는 $BUILD
환경 변수를 구문 분석할 수 있습니다.
레지스트리에 대한 가져오기 보안이 네임스페이스와 노드 모두에 있는 경우 빌드는 기본적으로 네임스페이스의 가져오기 보안을 사용합니다.