[CKS] 1-12. Bootstrap token for authentication & Service Account token and use it to access API server Lab

kubeadm 부트스트랩 토큰으로 워커 노드를 안전하게 추가하고 초기 역할을 부여하며, RBAC를 통해 클러스터 전반의 권한을 정교하게 관리합니다.

개요

kubernetes 워커 노드가 어떻게 조인할 수 있는지 랩을 통해 확인했습니다.

Hands-on

kubeadm 부트스트랩 토큰(Bootstrap Token)을 생성하는 Secret 리소스입니다.

토큰은 새로운 워커 노드(Worker Node)를 쿠버네티스 클러스터에 안전하게 추가(kubeadm join)할 때 사용합니다.

apiVersion: v1
kind: Secret
metadata:
  # Name MUST be of form "bootstrap-token-<token id>"
  name: bootstrap-token-07401b
  namespace: kube-system

# Type MUST be 'bootstrap.kubernetes.io/token'
type: bootstrap.kubernetes.io/token
stringData:
  # Human readable description. Optional.
  description: "The default bootstrap token generated by 'kubeadm init'."

  # Token ID and secret. Required.
  token-id: 07401b
  token-secret: f395accd246ae52d

  # Expiration. Optional.
  expiration: 2017-03-10T03:22:11Z

  # Allowed usages.
  usage-bootstrap-authentication: "true"
  usage-bootstrap-signing: "true"

  # Extra groups to authenticate the token as. Must start with "system:bootstrappers:"
  auth-extra-groups: system:bootstrappers:worker,system:bootstrappers:ingress

auth-extra-groups: system:bootstrappers:worker,system:bootstrappers:ingress (핵심 특징)

kubeadm token create 07401a.f395accd246ae52e --dry-run --print-join-command --ttl 2h

이는 노드가 마스터에 조인하기 위한 과정을 확인하기 위한 것입니다.

부트스트랩 토큰은 새로운 노드를 ‘안전하게’ 추가하는 표준 방식으로 사용됩니다.

Service Account

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-service-account
  namespace: default
secrets:
  - name: my-service-account-token
---
apiVersion: v1
kind: Secret
metadata:
  name: my-service-account-token
  namespace: default
  annotations:
    kubernetes.io/service-account.name: "my-service-account"
type: kubernetes.io/service-account-token
kubectl create rolebinding read-pods --serviceaccount=default:my-service-account --role=pod-reader

<1. Role (네임스페이스 범위의 역할)>

Role은 특정 네임스페이스 안에 존재하는 리소스(예: Pod, Deployment, Service 등)에 대한 권한을 정의합니다.

# "dev" 네임스페이스에만 적용되는 Role
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev # 이 Role은 'dev' 네임스페이스에 속함
  name: pod-reader
rules:
- apiGroups: [""] # ""는 core API 그룹을 의미
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

<2. ClusterRole (클러스터 범위의 역할)>

ClusterRoleRole과 기능적으로 동일하지만, 범위가 클러스터 전체입니다. 두 가지 중요한 목적을 가집니다.

  1. 클러스터 범위 리소스에 대한 권한 정의:
    • 노드(Nodes), 퍼시스턴트 볼륨(PersistentVolumes), 네임스페이스(Namespaces) 자체와 같이 네임스페이스에 속하지 않는 리소스에 대한 권한을 부여하려면 반드시 ClusterRole을 사용해야 합니다.
  2. 모든 네임스페이스의 리소스에 대한 권한 정의:
    • 클러스터 관리자가 모든 네임스페이스의 Pod를 관리해야 하는 경우처럼, 여러 네임스페이스에 걸쳐 동일한 권한을 부여하고 싶을 때 사용합니다.
      • (매번 네임스페이스마다 Role을 만들 필요가 없어 편리합니다.)
k config view --raw