3.6. 입력 보안 및 구성 맵


중요

입력 보안 및 구성 맵의 콘텐츠가 빌드 출력 컨테이너 이미지에 표시되지 않도록 Docker 빌드source-to-image 빌드 전략의 빌드 볼륨을 사용합니다.

일부 시나리오에서는 빌드 작업을 수행하려면 종속 리소스에 액세스하기 위해 자격 증명 또는 기타 구성 데이터가 필요합니다. 그러나 이러한 정보가 소스 제어에 배치되는 것은 바람직하지 않습니다. 이러한 용도를 위해 입력 보안 및 입력 구성 맵을 정의할 수 있습니다.

예를 들어 Maven으로 Java 애플리케이션을 빌드할 때 개인 키로 액세스할 수 있는 Maven Central 또는 JCenter의 개인 미러를 설정할 수 있습니다. 해당 개인 미러에서 라이브러리를 다운로드하려면 다음을 제공해야 합니다.

  1. 미러의 URL 및 연결 설정으로 구성된 settings.xml 파일
  2. 설정 파일에서 참조하는 개인 키(예: ~/.ssh/id_rsa)

보안상의 이유로 애플리케이션 이미지에 자격 증명을 노출해서는 안 됩니다.

이 예제에서는 Java 애플리케이션을 설명하지만 /etc/ssl/certs 디렉터리, API 키 또는 토큰, 라이선스 파일 등에 SSL 인증서를 추가하는 데 동일한 접근 방식을 사용할 수 있습니다.

3.6.1. 비밀이란?

Secret 오브젝트 유형에서는 암호, OpenShift Container Platform 클라이언트 구성 파일, dockercfg 파일, 개인 소스 리포지토리 자격 증명 등과 같은 중요한 정보를 보유하는 메커니즘을 제공합니다. 보안은 Pod에서 중요한 콘텐츠를 분리합니다. 볼륨 플러그인을 사용하여 컨테이너에 보안을 마운트하거나 시스템에서 시크릿을 사용하여 Pod 대신 작업을 수행할 수 있습니다.

YAML 보안 오브젝트 정의

apiVersion: v1
kind: Secret
metadata:
  name: test-secret
  namespace: my-namespace
type: Opaque 
1

data: 
2

  username: <username> 
3

  password: <password>
stringData: 
4

  hostname: myapp.mydomain.com 
5
Copy to Clipboard Toggle word wrap

1
보안의 키 이름과 값의 구조를 나타냅니다.
2
data 필드에서 허용되는 키 형식은 Kubernetes 구분자 용어집의 DNS_SUBDOMAIN 값에 있는 지침을 충족해야 합니다.
3
data 맵의 키와 관련된 값은 base64로 인코딩되어야 합니다.
4
stringData 맵의 항목이 base64로 변환된 후 해당 항목이 자동으로 data 맵으로 이동합니다. 이 필드는 쓰기 전용입니다. 해당 값은 data 필드에서만 반환합니다.
5
stringData 맵의 키와 관련된 값은 일반 텍스트 문자열로 구성됩니다.

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>
    Copy to Clipboard Toggle word wrap

    예를 들어 로컬 .docker/config.json 파일에서 보안을 생성할 수 있습니다.

    $ oc create secret generic dockerhub \
        --from-file=.dockerconfigjson=<path/to/.docker/config.json> \
        --type=kubernetes.io/dockerconfigjson
    Copy to Clipboard Toggle word wrap

    이 명령은 dockerhub라는 보안의 JSON 사양을 생성한 후 오브젝트를 생성합니다.

    YAML Opaque Secret 오브젝트 정의

    apiVersion: v1
    kind: Secret
    metadata:
      name: mysecret
    type: Opaque 
    1
    
    data:
      username: <username>
      password: <password>
    Copy to Clipboard Toggle word wrap

    1
    불투명 보안을 지정합니다.

    Docker 구성 JSON 파일 시크릿 오브젝트 정의

    apiVersion: v1
    kind: Secret
    metadata:
      name: aregistrykey
      namespace: myapps
    type: kubernetes.io/dockerconfigjson 
    1
    
    data:
      .dockerconfigjson:bm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg== 
    2
    Copy to Clipboard Toggle word wrap

    1
    보안에서 Docker 구성 JSON 파일을 사용하도록 지정합니다.
    2
    base64로 인코딩된 Docker 구성 JSON 파일의 출력입니다.

3.6.3. 보안 사용

보안을 생성한 후에는 해당 보안을 참조하는 Pod를 생성하고 로그를 가져오고 해당 Pod를 삭제할 수 있습니다.

프로세스

  1. 다음 명령을 입력하여 보안을 참조할 Pod를 생성합니다.

    $ oc create -f <your_yaml_file>.yaml
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 입력하여 로그를 가져옵니다.

    $ oc logs secret-example-pod
    Copy to Clipboard Toggle word wrap
  3. 다음 명령을 입력하여 Pod를 삭제합니다.

    $ oc delete pod secret-example-pod
    Copy to Clipboard Toggle word wrap

3.6.4. 입력 보안 및 구성 맵 추가

소스 제어에 의존하지 않고 인증 정보 및 기타 구성 데이터를 빌드에 제공하기 위해 입력 보안 및 입력 구성 맵을 정의할 수 있습니다.

일부 시나리오에서는 빌드 작업을 수행하려면 종속 리소스에 액세스하기 위해 인증 정보 또는 기타 구성 데이터가 필요합니다. 해당 정보를 소스 제어에 배치하지 않고 사용할 수 있도록 입력 보안 및 입력 구성 맵을 정의할 수 있습니다.

프로세스

입력 보안이나 구성 맵 또는 둘 다를 기존 BuildConfig 오브젝트에 추가하려면 다음을 수행합니다.

  1. ConfigMap 오브젝트가 없는 경우 다음 명령을 입력하여 생성합니다.

    $ oc create configmap settings-mvn \
        --from-file=settings.xml=<path/to/settings.xml>
    Copy to Clipboard Toggle word wrap

    그러면 settings-mvn이라는 새 구성 맵이 생성됩니다. 이 맵에는 settings.xml 파일의 일반 텍스트 내용이 포함됩니다.

    작은 정보

    다음 YAML을 적용하여 구성 맵을 만들 수 있습니다.

    apiVersion: core/v1
    kind: ConfigMap
    metadata:
      name: settings-mvn
    data:
      settings.xml: |
        <settings>
        … # Insert maven settings here
        </settings>
    Copy to Clipboard Toggle word wrap
  2. Secret 오브젝트가 없는 경우 다음 명령을 입력하여 생성합니다.

    $ oc create secret generic secret-mvn \
        --from-file=ssh-privatekey=<path/to/.ssh/id_rsa> \
        --type=kubernetes.io/ssh-auth
    Copy to Clipboard Toggle word wrap

    그러면 secret-mvn이라는 새 보안이 생성됩니다. 이 보안에는 id_rsa 개인 키의 base64 인코딩 콘텐츠가 포함됩니다.

    작은 정보

    다음 YAML을 적용하여 입력 보안을 생성할 수 있습니다.

    apiVersion: core/v1
    kind: Secret
    metadata:
      name: secret-mvn
    type: kubernetes.io/ssh-auth
    data:
      ssh-privatekey: |
        # Insert ssh private key, base64 encoded
    Copy to Clipboard Toggle word wrap
  3. 다음과 같이 기존 BuildConfig 오브젝트의 source 섹션에 구성 맵과 보안을 추가합니다.

    source:
      git:
        uri: https://github.com/wildfly/quickstart.git
      contextDir: helloworld
      configMaps:
        - configMap:
            name: settings-mvn
      secrets:
        - secret:
            name: secret-mvn
    Copy to Clipboard Toggle word wrap
  4. 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"
    Copy to Clipboard Toggle word wrap

    빌드 중에 빌드 프로세스는 settings.xmlid_rsa 파일을 소스 코드가 있는 디렉터리에 복사합니다. OpenShift Container Platform S2I 빌더 이미지의 경우 이 디렉터리는 DockerfileWORKDIR 명령을 사용하여 설정하는 이미지 작업 디렉터리입니다. 다른 디렉터리를 지정하려면 정의에 destinationDir을 추가합니다.

    source:
      git:
        uri: https://github.com/wildfly/quickstart.git
      contextDir: helloworld
      configMaps:
        - configMap:
            name: settings-mvn
          destinationDir: ".m2"
      secrets:
        - secret:
            name: secret-mvn
          destinationDir: ".ssh"
    Copy to Clipboard Toggle word wrap

    다음 명령을 입력하여 새 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"
    Copy to Clipboard Toggle word wrap

    두 경우 모두 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의 ADDCOPY 명령을 사용하여 정의된 모든 입력 보안을 컨테이너 이미지에 추가할 수 있습니다.

보안의 destinationDir을 지정하지 않으면 Dockerfile이 있는 동일한 디렉터리로 파일이 복사됩니다. 상대 경로를 destinationDir로 지정하면 보안이 Dockerfile 위치와 상대되는 해당 디렉터리에 복사됩니다. 그러면 Docker 빌드 작업에서 빌드 중 사용하는 컨텍스트 디렉터리의 일부로 보안 파일을 사용할 수 있습니다.

보안 및 구성 맵 데이터를 참조하는 Dockerfile의 예

FROM centos/ruby-22-centos7

USER root
COPY ./secret-dir /secrets
COPY ./config /

# Create a shell script that will output secrets and ConfigMaps when the image is run
RUN echo '#!/bin/sh' > /input_report.sh
RUN echo '(test -f /secrets/secret1 && echo -n "secret1=" && cat /secrets/secret1)' >> /input_report.sh
RUN echo '(test -f /config && echo -n "relative-configMap=" && cat /config)' >> /input_report.sh
RUN chmod 755 /input_report.sh

CMD ["/bin/sh", "-c", "/input_report.sh"]
Copy to Clipboard Toggle word wrap

중요

일반적으로 사용자는 해당 이미지에서 실행되는 컨테이너에 보안이 표시되지 않도록 최종 애플리케이션 이미지에서 입력 보안을 제거합니다. 그러나 보안은 추가된 계층에 있는 이미지 자체에 계속 있습니다. 이 제거는 Dockerfile 자체에 포함됩니다.

입력 보안 및 구성 맵의 콘텐츠가 빌드 출력 컨테이너 이미지에 표시되지 않도록 하려면 Docker 빌드 전략의 빌드 볼륨을 대신 사용합니다.

3.6.7. 사용자 정의 전략

사용자 정의 전략을 사용하는 경우 정의된 입력 보안 및 구성 맵을 /var/run/secrets/openshift.io/build 디렉터리의 빌더 컨테이너에서 모두 사용할 수 있습니다. 사용자 정의 빌드 이미지에서는 이러한 보안 및 구성 맵을 적절하게 사용해야 합니다. 사용자 정의 전략을 사용하면 사용자 정의 전략 옵션에 설명된 대로 보안을 정의할 수 있습니다.

기존 전략 보안과 입력 보안은 기술적으로 차이가 없습니다. 하지만 빌더 이미지는 빌드 사용 사례에 따라 해당 항목을 구분하고 다르게 사용할 수 있습니다.

입력 보안은 항상 /var/run/secrets/openshift.io/build 디렉터리에 마운트되거나 빌더에서 전체 빌드 오브젝트를 포함하는 $BUILD 환경 변수를 구문 분석할 수 있습니다.

중요

레지스트리에 대한 가져오기 보안이 네임스페이스와 노드 모두에 있는 경우 빌드는 기본적으로 네임스페이스의 가져오기 보안을 사용합니다.

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

Theme

© 2025 Red Hat