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:
        containers:
        - image: nginx
          name: nginx
          volumeMounts:
          - mountPath: /var/run/secrets/tokens
            name: vault-token
        serviceAccountName: build-robot 1
        volumes:
        - name: vault-token
          projected:
            sources:
            - serviceAccountToken:
                path: vault-token 2
                expirationSeconds: 7200 3
                audience: vault 4

      1

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

      2

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

      3

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

      4

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

   2. Pod를 생성합니다.

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

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

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

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