검색

2.4. 보안을 사용하여 Pod에 민감한 데이터 제공

download PDF

추가 리소스

일부 애플리케이션에는 개발자에게 제공하길 원하지 않는 민감한 정보(암호 및 사용자 이름 등)가 필요합니다.

관리자는 Secret 오브젝트를 사용하여 이러한 정보를 명확한 텍스트로 공개하지 않고도 제공할 수 있습니다.

2.4.1. 보안 이해

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

주요 속성은 다음과 같습니다.

  • 보안 데이터는 정의와는 별도로 참조할 수 있습니다.
  • 보안 데이터 볼륨은 임시 파일 저장 기능(tmpfs)에 의해 지원되며 노드에 저장되지 않습니다.
  • 보안 데이터는 네임스페이스 내에서 공유할 수 있습니다.

YAML Secret 오브젝트 정의

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

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

먼저 보안을 생성한 후 해당 보안을 사용하는 Pod를 생성해야 합니다.

보안 생성 시 다음을 수행합니다.

  • 보안 데이터를 사용하여 보안 오브젝트를 생성합니다.
  • Pod 서비스 계정을 업데이트하여 보안에 대한 참조를 허용합니다.
  • 보안을 환경 변수로 사용하거나 secret 볼륨을 사용하여 파일로 사용하는 Pod를 생성합니다.

2.4.1.1. 보안 유형

type 필드의 값은 보안의 키 이름과 값의 구조를 나타냅니다. 유형을 사용하면 보안 오브젝트에 사용자 이름과 키를 적용할 수 있습니다. 검증을 수행하지 않으려면 기본값인 opaque 유형을 사용합니다.

보안 데이터에 특정 키 이름이 있는지 확인하기 위해 서버 측 최소 검증을 트리거하려면 다음 유형 중 하나를 지정합니다.

  • kubernetes.io/basic-auth: 기본 인증으로 사용
  • kubernetes.io/dockercfg: 이미지 풀 시크릿으로 사용
  • kubernetes.io/dockerconfigjson: 이미지 풀 시크릿으로 사용
  • kubernetes.io/service-account-token: 기존 서비스 계정 API 토큰을 얻으려면 사용
  • kubernetes.io/ssh-auth: SSH 키 인증과 함께 사용
  • kubernetes.io/tls: TLS 인증 기관과 함께 사용

검증을 수행하지 않으려면 typ: Opaque를 지정합니다. 즉 보안에서 키 이름 또는 값에 대한 규칙을 준수하도록 요청하지 않습니다. opaque 보안에는 임의의 값을 포함할 수 있는 비정형 key:value 쌍을 사용할 수 있습니다.

참고

example.com/my-secret-type과 같은 다른 임의의 유형을 지정할 수 있습니다. 이러한 유형은 서버 측에 적용되지 않지만 보안 생성자가 해당 유형의 키/값 요구 사항을 준수하도록 의도했음을 나타냅니다.

다양한 유형의 시크릿 생성 예를 보려면 시크릿을 생성하는 방법 이해 를 참조하십시오.

2.4.1.2. 보안 데이터 키

보안키는 DNS 하위 도메인에 있어야 합니다.

2.4.1.3. 자동으로 생성된 이미지 풀 시크릿

기본적으로 AWS의 Red Hat OpenShift Service는 각 서비스 계정에 대한 이미지 풀 시크릿을 생성합니다.

참고

AWS 4.16에서 Red Hat OpenShift Service를 사용하기 전에 생성된 각 서비스 계정에 대해 장기 서비스 계정 API 토큰 시크릿도 생성되었습니다. AWS 4.16에서 Red Hat OpenShift Service부터 이 서비스 계정 API 토큰 시크릿이 더 이상 생성되지 않습니다.

4로 업그레이드한 후 장기 서비스 계정 API 토큰 시크릿은 삭제되지 않으며 계속 작동합니다. 클러스터에서 사용 중인 장기 API 토큰을 감지하거나 필요하지 않은 경우 삭제하는 방법에 대한 자세한 내용은 OpenShift Container Platform의 장기 서비스 계정 API 토큰을 참조하십시오.

이 이미지 풀 시크릿은 OpenShift 이미지 레지스트리를 클러스터의 사용자 인증 및 권한 부여 시스템에 통합하기 위해 필요합니다.

그러나 ImageRegistry 기능을 활성화하지 않거나 Cluster Image Registry Operator 구성에서 통합 OpenShift 이미지 레지스트리를 비활성화하면 각 서비스 계정에 대해 이미지 풀 시크릿이 생성되지 않습니다.

이전에 활성화된 클러스터에서 통합 OpenShift 이미지 레지스트리가 비활성화되면 이전에 생성된 이미지 가져오기 보안이 자동으로 삭제됩니다.

2.4.2. 보안 생성 방법 이해

관리자는 개발자가 해당 보안을 사용하는 Pod를 생성하기 전에 보안을 생성해야 합니다.

보안 생성 시 다음을 수행합니다.

  1. 보안을 유지하려는 데이터가 포함된 보안 오브젝트를 생성합니다. 각 보안 유형에 필요한 특정 데이터는 다음 섹션에서 축소됩니다.

    불투명 보안을 생성하는 YAML 오브젝트의 예

    apiVersion: v1
    kind: Secret
    metadata:
      name: test-secret
    type: Opaque 1
    data: 2
      username: <username>
      password: <password>
    stringData: 3
      hostname: myapp.mydomain.com
      secret.properties: |
        property1=valueA
        property2=valueB

    1
    보안 유형을 지정합니다.
    2
    인코딩된 문자열 및 데이터를 지정합니다.
    3
    디코딩된 문자열 및 데이터를 지정합니다.

    둘 다 아닌 data 또는 stringdata 필드를 사용합니다.

  2. Pod의 서비스 계정을 업데이트하여 보안을 참조합니다.

    보안을 사용하는 서비스 계정의 YAML

    apiVersion: v1
    kind: ServiceAccount
     ...
    secrets:
    - name: test-secret

  3. 보안을 환경 변수로 사용하거나 secret 볼륨을 사용하여 파일로 사용하는 Pod를 생성합니다.

    보안 데이터로 볼륨의 파일을 채우는 Pod의 YAML

    apiVersion: v1
    kind: Pod
    metadata:
      name: secret-example-pod
    spec:
      securityContext:
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
      containers:
        - name: secret-test-container
          image: busybox
          command: [ "/bin/sh", "-c", "cat /etc/secret-volume/*" ]
          volumeMounts: 1
              - name: secret-volume
                mountPath: /etc/secret-volume 2
                readOnly: true 3
          securityContext:
            allowPrivilegeEscalation: false
            capabilities:
              drop: [ALL]
      volumes:
        - name: secret-volume
          secret:
            secretName: test-secret 4
      restartPolicy: Never

    1
    보안이 필요한 각 컨테이너에 volumeMounts 필드를 추가합니다.
    2
    시크릿을 표시할 사용하지 않는 디렉터리 이름을 지정합니다. 시크릿 데이터 맵의 각 키는 mountPath 아래의 파일 이름이 됩니다.
    3
    true 로 설정합니다. true인 경우 드라이버에 읽기 전용 볼륨을 제공하도록 지시합니다.
    4
    보안 이름을 지정합니다.

    보안 데이터로 환경 변수를 채우는 Pod의 YAML

    apiVersion: v1
    kind: Pod
    metadata:
      name: secret-example-pod
    spec:
      securityContext:
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
      containers:
        - name: secret-test-container
          image: busybox
          command: [ "/bin/sh", "-c", "export" ]
          env:
            - name: TEST_SECRET_USERNAME_ENV_VAR
              valueFrom:
                secretKeyRef: 1
                  name: test-secret
                  key: username
          securityContext:
            allowPrivilegeEscalation: false
            capabilities:
              drop: [ALL]
      restartPolicy: Never

    1
    시크릿 키를 사용하는 환경 변수를 지정합니다.

    보안 데이터로 환경 변수를 채우는 빌드 구성의 YAML

    apiVersion: build.openshift.io/v1
    kind: BuildConfig
    metadata:
      name: secret-example-bc
    spec:
      strategy:
        sourceStrategy:
          env:
          - name: TEST_SECRET_USERNAME_ENV_VAR
            valueFrom:
              secretKeyRef: 1
                name: test-secret
                key: username
          from:
            kind: ImageStreamTag
            namespace: openshift
            name: 'cli:latest'

    1
    시크릿 키를 사용하는 환경 변수를 지정합니다.

2.4.2.1. 보안 생성 제한 사항

보안을 사용하려면 Pod에서 보안을 참조해야 합니다. 보안은 다음 세 가지 방법으로 Pod에서 사용할 수 있습니다.

  • 컨테이너에 환경 변수를 채우기 위해 사용.
  • 하나 이상의 컨테이너에 마운트된 볼륨에서 파일로 사용.
  • Pod에 대한 이미지를 가져올 때 kubelet으로 사용.

볼륨 유형 보안은 볼륨 메커니즘을 사용하여 데이터를 컨테이너에 파일로 작성합니다. 이미지 가져오기 보안은 서비스 계정을 사용하여 네임스페이스의 모든 Pod에 보안을 자동으로 삽입합니다.

템플릿에 보안 정의가 포함된 경우 템플릿에 제공된 보안을 사용할 수 있는 유일한 방법은 보안 볼륨 소스를 검증하고 지정된 오브젝트 참조가 Secret 오브젝트를 실제로 가리키는 것입니다. 따라서 보안을 생성한 후 해당 보안을 사용하는 Pod를 생성해야 합니다. 가장 효과적인 방법은 서비스 계정을 사용하여 자동으로 삽입되도록 하는 것입니다.

Secret API 오브젝트는 네임스페이스에 있습니다. 동일한 네임스페이스에 있는 Pod만 참조할 수 있습니다.

개별 보안은 1MB로 제한됩니다. 이는 대규모 보안이 생성되어 apiserver 및 kubelet 메모리가 소모되는 것을 막기 위한 것입니다. 그러나 작은 보안을 많이 생성해도 메모리가 소모될 수 있습니다.

2.4.2.2. 불투명 보안 생성

관리자는 임의의 값을 포함할 수 있는 구조화되지 않은 키:값 쌍을 저장할 수 있는 opaque 보안을 생성할 수 있습니다.

프로세스

  1. 컨트롤 플레인 노드의 YAML 파일에 Secret 오브젝트를 생성합니다.

    예를 들면 다음과 같습니다.

    apiVersion: v1
    kind: Secret
    metadata:
      name: mysecret
    type: Opaque 1
    data:
      username: <username>
      password: <password>
    1
    불투명 보안을 지정합니다.
  2. 다음 명령을 사용하여 Secret 오브젝트를 생성합니다.

    $ oc create -f <filename>.yaml
  3. Pod에서 보안을 사용하려면 다음을 수행합니다.

    1. "보안을 생성하는 방법 이해" 섹션에 표시된 대로 Pod의 서비스 계정을 업데이트하여 보안을 참조합니다.
    2. "보안 생성 방법 이해" 섹션에 표시된 대로 보안 을 환경 변수 또는 파일로 사용하는 Pod를 생성합니다.

추가 리소스

2.4.2.3. 레거시 서비스 계정 토큰 시크릿 생성

관리자는 레거시 서비스 계정 토큰 시크릿을 생성할 수 있으므로 API에 인증해야 하는 애플리케이션에 서비스 계정 토큰을 배포할 수 있습니다.

주의

기존 서비스 계정 토큰 시크릿을 사용하는 대신 TokenRequest API를 사용하여 바인딩된 서비스 계정 토큰을 가져오는 것이 좋습니다. TokenRequest API를 사용할 수 없고 읽을 수 있는 API 오브젝트에서 만료되지 않은 토큰의 보안 노출이 허용되는 경우에만 서비스 계정 토큰 시크릿을 생성해야 합니다.

바인딩된 서비스 계정 토큰은 다음과 같은 이유로 서비스 계정 토큰 시크릿보다 안전합니다.

  • 바인딩된 서비스 계정 토큰은 수명이 바인딩되어 있습니다.
  • 바인딩된 서비스 계정 토큰에는 대상자가 포함됩니다.
  • 바인딩된 서비스 계정 토큰은 Pod 또는 보안에 바인딩될 수 있으며 바인딩된 오브젝트가 제거되면 바인딩된 토큰이 무효화됩니다.

바인딩된 서비스 계정 토큰을 얻기 위해 예상 볼륨과 함께 워크로드가 자동으로 삽입됩니다. 워크로드에 추가 서비스 계정 토큰이 필요한 경우 워크로드 매니페스트에 예상 볼륨을 추가합니다.

자세한 내용은 "볼륨 프로젝션을 사용하여 바인딩된 서비스 계정 토큰 구성"을 참조하십시오.

프로세스

  1. 컨트롤 플레인 노드의 YAML 파일에 Secret 오브젝트를 생성합니다.

    Secret 오브젝트의 예

    apiVersion: v1
    kind: Secret
    metadata:
      name: secret-sa-sample
      annotations:
        kubernetes.io/service-account.name: "sa-name" 1
    type: kubernetes.io/service-account-token 2

    1
    기존 서비스 계정 이름을 지정합니다. ServiceAccountSecret 오브젝트를 모두 생성하는 경우 ServiceAccount 오브젝트를 먼저 생성합니다.
    2
    서비스 계정 토큰 시크릿을 지정합니다.
  2. 다음 명령을 사용하여 Secret 오브젝트를 생성합니다.

    $ oc create -f <filename>.yaml
  3. Pod에서 보안을 사용하려면 다음을 수행합니다.

    1. "보안을 생성하는 방법 이해" 섹션에 표시된 대로 Pod의 서비스 계정을 업데이트하여 보안을 참조합니다.
    2. "보안 생성 방법 이해" 섹션에 표시된 대로 보안 을 환경 변수 또는 파일로 사용하는 Pod를 생성합니다.

추가 리소스

2.4.2.4. 기본 인증 보안 생성

관리자는 기본 인증에 필요한 인증 정보를 저장할 수 있는 기본 인증 보안을 생성할 수 있습니다. 이 보안 유형을 사용하는 경우 Secret 오브젝트의 data 매개변수에는 base64 형식으로 인코딩된 다음 키가 포함되어야 합니다.

  • username: 인증을 위한 사용자 이름
  • 암호: 인증을 위한 암호 또는 토큰
참고

stringData 매개변수를 사용하여 일반 텍스트 콘텐츠를 사용할 수 있습니다.

프로세스

  1. 컨트롤 플레인 노드의 YAML 파일에 Secret 오브젝트를 생성합니다.

    보안 오브젝트의

    apiVersion: v1
    kind: Secret
    metadata:
      name: secret-basic-auth
    type: kubernetes.io/basic-auth 1
    data:
    stringData: 2
      username: admin
      password: <password>

    1
    기본 인증 보안을 지정합니다.
    2
    사용할 기본 인증 값을 지정합니다.
  2. 다음 명령을 사용하여 Secret 오브젝트를 생성합니다.

    $ oc create -f <filename>.yaml
  3. Pod에서 보안을 사용하려면 다음을 수행합니다.

    1. "보안을 생성하는 방법 이해" 섹션에 표시된 대로 Pod의 서비스 계정을 업데이트하여 보안을 참조합니다.
    2. "보안 생성 방법 이해" 섹션에 표시된 대로 보안 을 환경 변수 또는 파일로 사용하는 Pod를 생성합니다.

추가 리소스

2.4.2.5. SSH 인증 보안 생성

관리자는 SSH 인증에 사용되는 데이터를 저장할 수 있는 SSH 인증 보안을 생성할 수 있습니다. 이 보안 유형을 사용하는 경우 Secret 오브젝트의 data 매개변수에 사용할 SSH 인증 정보가 포함되어야 합니다.

프로세스

  1. 컨트롤 플레인 노드의 YAML 파일에 Secret 오브젝트를 생성합니다.

    보안 오브젝트의

    apiVersion: v1
    kind: Secret
    metadata:
      name: secret-ssh-auth
    type: kubernetes.io/ssh-auth 1
    data:
      ssh-privatekey: | 2
              MIIEpQIBAAKCAQEAulqb/Y ...

    1
    SSH 인증 보안을 지정합니다.
    2
    사용할 SSH 자격 증명으로 SSH 키/값 쌍을 지정합니다.
  2. 다음 명령을 사용하여 Secret 오브젝트를 생성합니다.

    $ oc create -f <filename>.yaml
  3. Pod에서 보안을 사용하려면 다음을 수행합니다.

    1. "보안을 생성하는 방법 이해" 섹션에 표시된 대로 Pod의 서비스 계정을 업데이트하여 보안을 참조합니다.
    2. "보안 생성 방법 이해" 섹션에 표시된 대로 보안 을 환경 변수 또는 파일로 사용하는 Pod를 생성합니다.

추가 리소스

2.4.2.6. Docker 구성 보안 생성

관리자는 컨테이너 이미지 레지스트리에 액세스하기 위한 인증 정보를 저장할 수 있는 Docker 구성 시크릿을 생성할 수 있습니다.

  • kubernetes.io/dockercfg. 로컬 Docker 구성 파일을 저장하려면 이 시크릿 유형을 사용합니다. 보안 오브젝트의 data 매개변수에는 base64 형식으로 인코딩된 .dockercfg 파일의 내용이 포함되어야 합니다.
  • kubernetes.io/dockerconfigjson. 이 시크릿 유형을 사용하여 로컬 Docker 구성 JSON 파일을 저장합니다. 보안 오브젝트의 data 매개변수에는 base64 형식으로 인코딩된 .docker/config.json 파일의 내용이 포함되어야 합니다.

프로세스

  1. 컨트롤 플레인 노드의 YAML 파일에 Secret 오브젝트를 생성합니다.

    Docker 구성 시크릿 오브젝트의 예

    apiVersion: v1
    kind: Secret
    metadata:
      name: secret-docker-cfg
      namespace: my-project
    type: kubernetes.io/dockerconfig 1
    data:
      .dockerconfig:bm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg== 2

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

    Docker 구성 JSON 시크릿 오브젝트의 예

    apiVersion: v1
    kind: Secret
    metadata:
      name: secret-docker-json
      namespace: my-project
    type: kubernetes.io/dockerconfig 1
    data:
      .dockerconfigjson:bm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg== 2

    1
    보안이 Docker 구성 JSON 파일을 사용하도록 지정합니다.
    2
    base64로 인코딩된 Docker 구성 JSON 파일의 출력
  2. 다음 명령을 사용하여 Secret 오브젝트를 생성합니다.

    $ oc create -f <filename>.yaml
  3. Pod에서 보안을 사용하려면 다음을 수행합니다.

    1. "보안을 생성하는 방법 이해" 섹션에 표시된 대로 Pod의 서비스 계정을 업데이트하여 보안을 참조합니다.
    2. "보안 생성 방법 이해" 섹션에 표시된 대로 보안 을 환경 변수 또는 파일로 사용하는 Pod를 생성합니다.

추가 리소스

2.4.2.7. 웹 콘솔을 사용하여 보안 생성

웹 콘솔을 사용하여 보안을 생성할 수 있습니다.

프로세스

  1. 워크로드 시크릿으로 이동합니다.
  2. 생성 YAML 을 클릭합니다.

    1. 사양에 맞게 YAML을 수동으로 편집하거나 파일을 YAML 편집기로 끌어서 놓습니다. 예를 들면 다음과 같습니다.

      apiVersion: v1
      kind: Secret
      metadata:
        name: example
        namespace: <namespace>
      type: Opaque 1
      data:
        username: <base64 encoded username>
        password: <base64 encoded password>
      stringData: 2
        hostname: myapp.mydomain.com
      1
      이 예제에서는 불투명 보안을 지정합니다. 그러나 서비스 계정 토큰 시크릿, 기본 인증 시크릿, SSH 인증 시크릿 또는 Docker 구성을 사용하는 시크릿과 같은 다른 시크릿 유형이 표시될 수 있습니다.
      2
      stringData 맵의 항목이 base64로 변환된 후 해당 항목이 자동으로 data 맵으로 이동합니다. 이 필드는 쓰기 전용이며 값은 data 필드를 통해서만 반환됩니다.
  3. 생성을 클릭합니다.
  4. 워크로드에 시크릿 추가를 클릭합니다.

    1. 드롭다운 메뉴에서 추가할 워크로드를 선택합니다.
    2. 저장을 클릭합니다.

2.4.3. 보안 업데이트 방법 이해

보안 값을 수정해도 이미 실행 중인 Pod에서 사용하는 값은 동적으로 변경되지 않습니다. 보안을 변경하려면 원래 Pod를 삭제하고 새 Pod를 생성해야 합니다(대개 동일한 PodSpec 사용).

보안 업데이트 작업에서는 새 컨테이너 이미지를 배포하는 것과 동일한 워크플로를 따릅니다. kubectl rolling-update 명령을 사용할 수 있습니다.

보안의 resourceVersion 값은 참조 시 지정되지 않습니다. 따라서 Pod가 시작되는 동시에 보안이 업데이트되는 경우 Pod에 사용되는 보안의 버전이 정의되지 않습니다.

참고

현재는 Pod가 생성될 때 사용된 보안 오브젝트의 리소스 버전을 확인할 수 없습니다. 컨트롤러에서 이전 resourceVersion 을 사용하여 재시작할 수 있도록 Pod에서 이 정보를 보고하도록 계획되어 있습니다. 그동안 기존 보안 데이터를 업데이트하지 말고 고유한 이름으로 새 보안을 생성하십시오.

2.4.4. 보안 생성 및 사용

관리자는 서비스 계정 토큰 시크릿을 생성할 수 있습니다. 이를 통해 API에 인증해야 하는 애플리케이션에 서비스 계정 토큰을 배포할 수 있습니다.

프로세스

  1. 다음 명령을 실행하여 네임스페이스에 서비스 계정을 생성합니다.

    $ oc create sa <service_account_name> -n <your_namespace>
  2. 다음 YAML 예제를 service-account-token-secret.yaml 이라는 파일에 저장합니다. 예제에는 서비스 계정 토큰을 생성하는 데 사용할 수 있는 Secret 오브젝트 구성이 포함되어 있습니다.

    apiVersion: v1
    kind: Secret
    metadata:
      name: <secret_name> 1
      annotations:
        kubernetes.io/service-account.name: "sa-name" 2
    type: kubernetes.io/service-account-token 3
    1
    & lt;secret_name& gt;을 서비스 토큰 시크릿의 이름으로 바꿉니다.
    2
    기존 서비스 계정 이름을 지정합니다. ServiceAccountSecret 오브젝트를 모두 생성하는 경우 ServiceAccount 오브젝트를 먼저 생성합니다.
    3
    서비스 계정 토큰 시크릿 유형을 지정합니다.
  3. 파일을 적용하여 서비스 계정 토큰을 생성합니다.

    $ oc apply -f service-account-token-secret.yaml
  4. 다음 명령을 실행하여 시크릿에서 서비스 계정 토큰을 가져옵니다.

    $ oc get secret <sa_token_secret> -o jsonpath='{.data.token}' | base64 --decode 1

    출력 예

    ayJhbGciOiJSUzI1NiIsImtpZCI6IklOb2dtck1qZ3hCSWpoNnh5YnZhSE9QMkk3YnRZMVZoclFfQTZfRFp1YlUifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImJ1aWxkZXItdG9rZW4tdHZrbnIiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiYnVpbGRlciIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjNmZGU2MGZmLTA1NGYtNDkyZi04YzhjLTNlZjE0NDk3MmFmNyIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0OmJ1aWxkZXIifQ.OmqFTDuMHC_lYvvEUrjr1x453hlEEHYcxS9VKSzmRkP1SiVZWPNPkTWlfNRp6bIUZD3U6aN3N7dMSN0eI5hu36xPgpKTdvuckKLTCnelMx6cxOdAbrcw1mCmOClNscwjS1KO1kzMtYnnq8rXHiMJELsNlhnRyyIXRTtNBsy4t64T3283s3SLsancyx0gy0ujx-Ch3uKAKdZi5iT-I8jnnQ-ds5THDs2h65RJhgglQEmSxpHrLGZFmyHAQI-_SjvmHZPXEc482x3SkaQHNLqpmrpJorNqh1M8ZHKzlujhZgVooMvJmWPXTb2vnvi3DGn2XI-hZxl1yD2yGH1RBpYUHA

    1
    <sa_token_secret>을 서비스 토큰 시크릿의 이름으로 바꿉니다.
  5. 서비스 계정 토큰을 사용하여 클러스터의 API로 인증합니다.

    $ curl -X GET <openshift_cluster_api> --header "Authorization: Bearer <token>" 1 2
    1
    &lt ;openshift_cluster_api&gt;를 OpenShift 클러스터 API로 바꿉니다.
    2
    & lt;token >을 이전 명령에서 출력하는 서비스 계정 토큰으로 바꿉니다.

2.4.5. 보안이 포함된 서명된 인증서 사용 정보

서비스와의 통신을 보호하려면 AWS에서 Red Hat OpenShift Service를 구성하여 프로젝트의 보안에 추가할 수 있는 서명된 제공 인증서/키 쌍을 생성할 수 있습니다.

서비스 제공 인증서 보안은 즉시 사용 가능한 인증서가 필요한 복잡한 미들웨어 애플리케이션을 지원하기 위한 것입니다. 해당 설정은 관리자 툴에서 노드 및 마스터에 대해 생성하는 서버 인증서와 동일합니다.

서비스 Pod 사양은 서비스 제공 인증서 보안에 대해 구성됩니다.

apiVersion: v1
kind: Service
metadata:
  name: registry
  annotations:
    service.beta.openshift.io/serving-cert-secret-name: registry-cert1
# ...

1
인증서 이름을 지정합니다.

기타 Pod는 해당 Pod에 자동으로 마운트되는 /var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt 파일의 CA 번들을 사용하여 내부 DNS 이름에만 서명되는 클러스터 생성 인증서를 신뢰할 수 있습니다.

이 기능의 서명 알고리즘은 x509.SHA256WithRSA입니다. 직접 교대하려면 생성된 보안을 삭제합니다. 새 인증서가 생성됩니다.

2.4.5.1. 보안과 함께 사용할 서명된 인증서 생성

Pod에서 서명된 제공 인증서/키 쌍을 사용하려면 서비스를 생성하거나 편집하여 service.beta.openshift.io/serving-cert-secret-name 주석을 추가한 다음 Pod에 보안을 추가합니다.

프로세스

서비스 제공 인증서 보안을 생성하려면 다음을 수행합니다.

  1. 서비스에 대한 Pod 사양을 편집합니다.
  2. 보안에 사용할 이름과 함께 service.beta.openshift.io/serving-cert-secret-name 주석을 추가합니다.

    kind: Service
    apiVersion: v1
    metadata:
      name: my-service
      annotations:
          service.beta.openshift.io/serving-cert-secret-name: my-cert 1
    spec:
      selector:
        app: MyApp
      ports:
      - protocol: TCP
        port: 80
        targetPort: 9376

    인증서 및 키는 PEM 형식이며 각각 tls.crttls.key에 저장됩니다.

  3. 서비스를 생성합니다.

    $ oc create -f <file-name>.yaml
  4. 보안이 생성되었는지 확인합니다.

    1. 모든 보안 목록을 확인합니다.

      $ oc get secrets

      출력 예

      NAME                     TYPE                                  DATA      AGE
      my-cert                  kubernetes.io/tls                     2         9m

    2. 보안에 대한 세부 정보를 확인합니다.

      $ oc describe secret my-cert

      출력 예

      Name:         my-cert
      Namespace:    openshift-console
      Labels:       <none>
      Annotations:  service.beta.openshift.io/expiry: 2023-03-08T23:22:40Z
                    service.beta.openshift.io/originating-service-name: my-service
                    service.beta.openshift.io/originating-service-uid: 640f0ec3-afc2-4380-bf31-a8c784846a11
                    service.beta.openshift.io/expiry: 2023-03-08T23:22:40Z
      
      Type:  kubernetes.io/tls
      
      Data
      ====
      tls.key:  1679 bytes
      tls.crt:  2595 bytes

  5. 해당 보안을 사용하여 Pod 사양을 편집합니다.

    apiVersion: v1
    kind: Pod
    metadata:
      name: my-service-pod
    spec:
      securityContext:
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
      containers:
      - name: mypod
        image: redis
        volumeMounts:
        - name: my-container
          mountPath: "/etc/my-path"
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop: [ALL]
      volumes:
      - name: my-volume
        secret:
          secretName: my-cert
          items:
          - key: username
            path: my-group/my-username
            mode: 511

    사용 가능한 경우 Pod가 실행됩니다. 인증서는 내부 서비스 DNS 이름인 <service.name>.<service.namespace>.svc에 적합합니다.

    인증서/키 쌍은 만료 시기가 다가오면 자동으로 교체됩니다. 시크릿의 service.beta.openshift.io/expiry 주석에서 RFC3339 형식으로 된 만료 날짜를 확인합니다.

    참고

    대부분의 경우 서비스 DNS 이름 <service.name>.<service.namespace>.svc는 외부에서 라우팅할 수 없습니다. <service.name>.<service.namespace>.svc는 주로 클러스터 내 또는 서비스 내 통신과 경로 재암호화에 사용됩니다.

2.4.6. 보안 문제 해결

서비스 인증서 생성에 실패하는 경우(서비스의 service.beta.openshift.io/serving-cert-generation-error 주석에는 다음이 포함됩니다.

secret/ssl-key references serviceUID 62ad25ca-d703-11e6-9d6f-0e9c0057b608, which does not match 77b6dd80-d716-11e6-9d6f-0e9c0057b60

인증서를 생성한 서비스가 더 이상 존재하지 않거나 serviceUID가 다릅니다. 이전 보안을 제거하고 서비스 service.beta.openshift.io/serving-cert-generation-error , service.beta.openshift.io/serving-cert-generation-error -num 주석을 지워 인증서를 강제로 다시 생성해야 합니다.

  1. 보안을 삭제합니다.

    $ oc delete secret <secret_name>
  2. 주석을 지웁니다.

    $ oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-
    $ oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-num-
참고

주석을 제거하는 명령에는 제거할 주석 이름 뒤에 -가 있습니다.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.