14.2. 볼륨 프로젝션을 사용한 바인딩된 서비스 계정 토큰 구성

프로세스

1. 선택 사항: 서비스 계정 발행자를 설정합니다.

   바인딩된 토큰이 클러스터 내에서만 사용되는 경우 일반적으로 이 단계가 필요하지 않습니다.

   중요

   서비스 계정 발행자를 사용자 정의로 변경하는 경우에도 이전 서비스 계정 발행자는 24시간 동안 계속 신뢰할 수 있습니다.

   클러스터의 모든 Pod를 수동으로 다시 시작하거나 롤링 노드를 다시 시작하여 모든 소유자가 새 바인딩된 토큰을 요청하도록 할 수 있습니다. 두 작업을 수행하기 전에 Kubernetes API 서버 Pod의 새 버전이 서비스 계정 발행자 변경과 함께 롤아웃될 때까지 기다립니다.

   1. cluster Authentication 오브젝트를 편집합니다.

      $ oc edit authentications cluster

   2. spec.serviceAccountIssuer 필드를 원하는 서비스 계정 발행자 값으로 설정합니다.

      spec:
        serviceAccountIssuer: https://test.default.svc 1

      1

      이 값은 바인딩된 토큰의 수신자가 토큰 서명을 확인하는 데 필요한 공개 키를 공급할 수 있는 URL이어야 합니다. 기본값은 https://kubernetes.default.svc입니다.

   3. 파일을 저장하여 변경 사항을 적용합니다.

   4. Kubernetes API 서버 pod의 새 버전이 롤아웃될 때까지 기다립니다. 모든 노드가 새 버전으로 업데이트되는 데 몇 분이 걸릴 수 있습니다. 다음 명령을 실행합니다.

      $ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

      Kubernetes API 서버의 NodeInstallerProgressing 상태 조건을 검토하여 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에 AllNodesAtLatestRevision이 표시됩니다.

      AllNodesAtLatestRevision
      3 nodes are at revision 12 1

      1

      이 예에서 최신 버전 번호는 12 입니다.

      출력에 다음 메시지 중 하나와 유사한 메시지가 표시되면 업데이트가 계속 진행 중입니다. 몇 분 기다린 후 다시 시도합니다.

      • 3 nodes are at revision 11; 0 nodes have achieved new revision 12
      • 2 nodes are at revision 11; 1 nodes are at revision 12

   5. 선택 사항: 홀더가 롤링 노드를 다시 시작하거나 클러스터의 모든 Pod를 수동으로 다시 시작하여 새 바인딩된 토큰을 요청하도록 강제 적용합니다.

      • 롤링 노드 재시작을 수행합니다.

        주의

        클러스터에서 사용자 정의 워크로드를 실행 중인 경우 서비스가 중단될 수 있으므로 롤링 노드 재시작을 수행하지 않는 것이 좋습니다. 대신 클러스터의 모든 Pod를 수동으로 다시 시작합니다.

        노드를 순차적으로 재시작합니다. 다음 노드를 다시 시작하기 전에 노드를 완전히 사용할 수 있을 때까지 기다립니다. 노드를 다시 예약 가능으로 드레이닝, 재시작, 표시하는 방법에 대한 지침은 정상적으로 노드 재부팅 을 참조하십시오.

      • 클러스터의 모든 Pod를 수동으로 다시 시작합니다.

        주의

        이 명령을 실행하면 모든 네임스페이스에서 실행 중인 모든 Pod가 삭제되므로 서비스가 중단됩니다. 이 Pod는 삭제 후 자동으로 다시 시작됩니다.

        다음 명령을 실행합니다.

        $ for I in $(oc get ns -o jsonpath='{range .items[*]} {.metadata.name}{"\n"} {end}'); \
              do oc delete pods --all -n $I; \
              sleep 1; \
              done

2. 볼륨 프로젝션을 통해 바인딩된 서비스 계정 토큰을 사용하도록 pod를 구성합니다.

   1. 다음 콘텐츠를 사용하여 pod-projected-svc-token.yaml이라는 파일을 생성합니다.

      apiVersion: v1
      kind: Pod
      metadata:
        name: nginx
      spec:
        securityContext:
          runAsNonRoot: true 1
          seccompProfile:
            type: RuntimeDefault 2
        containers:
        - image: nginx
          name: nginx
          volumeMounts:
          - mountPath: /var/run/secrets/tokens
            name: vault-token
          securityContext:
            allowPrivilegeEscalation: false
            capabilities:
              drop: [ALL]
        serviceAccountName: build-robot 3
        volumes:
        - name: vault-token
          projected:
            sources:
            - serviceAccountToken:
                path: vault-token 4
                expirationSeconds: 7200 5
                audience: vault 6

      1

      컨테이너가 root로 실행되도록 하여 위험 저하를 최소화합니다.

      2

      위험을 줄이기 위해 필수 시스템 호출으로 제한되는 기본 seccomp 프로필을 설정합니다.

      3

      기존 서비스 계정에 대한 참조입니다.

      4

      토큰을 프로젝션할 파일의 마운트 지점을 기준으로 하는 경로입니다.

      5

      필요한 경우 서비스 계정 토큰 만료 시간을 초 단위로 설정합니다. 기본값은 3600초(1시간)이며 이 값은 600초(10분) 이상이어야 합니다. 토큰이 수명의 80% 이상을 경과했거나 24시간 이상된 경우 kubelet에서 토큰을 순환하기 시작합니다.

      6

      필요한 경우 의도된 토큰 오디언스를 설정합니다. 토큰 수신자는 수신자 ID가 토큰의 오디언스 클레임과 일치하는지 확인하고 일치하지 않는 경우 토큰을 거부해야 합니다. 오디언스는 기본적으로 API 서버의 식별자입니다.

      참고

      예기치 않은 실패를 방지하기 위해 OpenShift Container Platform은 --service-account-extend-token-expiration 기본값인 true 를 사용하여 expirationSeconds 값을 초기 토큰 생성에서 1년으로 덮어씁니다. 이 설정은 변경할 수 없습니다.

   2. Pod를 생성합니다.

      $ oc create -f pod-projected-svc-token.yaml

      kubelet은 pod를 대신하여 토큰을 요청 및 저장하고, 구성 가능한 파일 경로에 있는 pod에서 토큰을 사용할 수 있도록 설정하고, 토큰이 만료되면 토큰을 갱신합니다.

3. 바인딩된 토큰을 사용하는 애플리케이션에서는 토큰이 회전할 때 다시 로드하는 작업을 처리해야 합니다.

   kubelet은 토큰이 수명의 80% 이상을 경과했거나 24시간 이상된 경우, 토큰을 회전합니다.