26M12a

Young-Kyoo Kim·2026년 3월 11일

Kyverno를 활용하면 쿠버네티스 노드 레이블링 작업에 대해 매우 세밀한 거버넌스(Governance)와 자동화를 구축할 수 있습니다. 특히 말씀하신 "사용자/그룹별 권한 제어"와 "워크벤치(UI) 연동" 시나리오에 Kyverno의 Validate(검증) 및 Mutate(변조) 정책이 어떻게 쓰이는지 핵심 전략을 정리해 드립니다.

1. Kyverno를 이용한 노드 레이블 관리 전략

기본적으로 쿠버네티스에서 노드 수정 권한은 매우 강력한 권한입니다. Kyverno를 사용하면 단순히 "수정 가능 여부"를 넘어 "누가, 어떤 키-값(Key-Value)만 수정할 수 있는지"를 통제할 수 있습니다.

① 특정 사용자/그룹만 특정 레이블 키 수정 허용 (Validate)

예를 들어, admin 그룹은 모든 레이블을 고칠 수 있지만, data-scientist 그룹은 project나 workbench-id 레이블만 수정할 수 있도록 제한할 수 있습니다.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-node-label-updates
spec:
  validationFailureAction: Enforce
  background: false
  rules:
  - name: check-user-label-permission
    match:
      any:
      - resources:
          kinds:
          - Node
    # 특정 그룹이 아닌 경우 검증 로직 실행
    exclude:
      clusterRoles:
      - cluster-admin
    validate:
      message: "귀하의 그룹은 'workbench/'로 시작하는 레이블만 수정할 수 있습니다."
      foreach:
      - list: "request.object.metadata.labels"
        # 변경된 레이블 키가 특정 패턴인지 확인
        deny:
          conditions:
          - all:
            - key: "{{ key }}"
              operator: NotEquals
              value: "workbench/*"

② 레이블 추가 시 자동 메타데이터 주입 (Mutate)

누가 레이블을 추가했는지 추적하기 위해, 레이블이 변경될 때 수정자의 정보를 별도 주석(Annotation)으로 자동 기입할 수 있습니다.

mutate:
  patchStrategicMerge:
    metadata:
      annotations:
        last-modified-by: "{{ serviceAccountName |  request.userInfo.username }}"

2. 워크벤치 화면 및 권한 설계 (UX/UI 관점)

사용자용 워크벤치 화면에서 이를 구현하려면 다음과 같은 아키텍처가 권장됩니다.

기능구현 방법Kyverno의 역할
현재 레이블 조회kubectl get node --show-labels 결과를 API로 노출(직접 관여 안 함)
레이블 추가/수정워크벤치 백엔드에서 kubectl patch node 호출요청을 가로채서(Intercept) 허용된 키인지 검사
그룹별 권한 분리RBAC(ClusterRole) + Kyverno PolicyRBAC이 통과되어도 Kyverno가 세부 레이블 정책 검증

3. 실무 구현 팁

  1. 레이블 네임스페이스 활용: 사용자가 직접 노드를 건드리는 것은 위험하므로, workbench.io/owner: "user-a", workbench.io/allow-gpu: "true" 처럼 전용 접두사(Prefix)를 정해두고 해당 접두사가 붙은 레이블만 Kyverno에서 허용하는 것이 가장 안전합니다.
  2. Admission Review 로그: 사용자가 권한이 없는 레이블을 추가하려고 할 때, Kyverno가 차단한 사유를 워크벤치 UI에 그대로 전달해 줄 수 있습니다. (API 응답의 message 필드 활용)
  3. Self-Service 레이블링: 보통 노드 레이블은 노드의 특성을 정의하므로, 사용자가 직접 하기보다는 "워크벤치 신청" 시 백엔드 로직이 Kyverno의 승인을 받아 특정 노드에 레이블을 찍어주고, 그 노드에 해당 사용자의 Pod가 스케줄링되도록 nodeSelector를 자동 설정하는 흐름이 더 세련된 방식입니다.

💡 다음 단계로 제안드리는 것

  • Kyverno 정책 작성: 특정 그룹(workbench-users)이 노드에 레이블을 추가하려고 할 때의 상세 YAML 정책 코드를 짜드릴까요?
  • 보안: 일반 사용자가 노드 레이블을 통해 다른 사람의 노드를 탈취하는 것을 방지하는 보안 정책이 궁금하신가요?
  • UI 연동: 워크벤치에서 노드 정보를 가져오는 Kubernetes API 호출 예시가 필요하신가요?

==

Keycloak과 AD가 연동된 환경이라면, 사용자 인증 정보는 OIDC(OpenID Connect)를 통해 쿠버네티스 API 서버로 전달됩니다. 이 과정에서 Keycloak은 AD의 그룹 정보를 ID Token의 groups 클레임(Claim)에 담아 보냅니다.

Kyverno는 이 토큰에 담긴 사용자 이름(User)과 그룹명(Groups)을 실시간으로 읽어 정책에 적용할 수 있습니다.

1. 인증 흐름과 Kyverno의 역할

  1. 사용자: 워크벤치 UI에서 AD 계정으로 로그인.
  2. Keycloak: AD에서 사용자의 그룹(예: CN=Admin-Group,OU=Groups...)을 읽어와 JWT 토큰을 발행.
  3. K8s API 서버: 토큰을 검증하고 사용자의 Identity를 파악.
  4. Kyverno: API 서버로 들어온 '노드 레이블 수정' 요청의 request.userInfo를 검사하여 정책 승인 여부 결정.

2. Kyverno 정책 내에서 권한 사용자 구분법

Kyverno의 match 또는 preconditions 섹션에서 AD 그룹명을 직접 대조할 수 있습니다.

① 특정 AD 그룹에만 레이블 수정 권한 부여 (ClusterPolicy)

아래 정책은 AD의 workbench-admins 그룹에 속한 사용자만 노드 레이블을 수정할 수 있도록 제한하는 예시입니다.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: node-label-permission-by-ad-group
spec:
  validationFailureAction: Enforce
  rules:
  - name: allow-only-specific-ad-groups
    match:
      any:
      - resources:
          kinds:
          - Node
          operations:
          - UPDATE
    # 권한이 없는 그룹인 경우 차단 로직 실행
    preconditions:
      all:
      - key: "workbench-admins" # 허용할 AD 그룹명 (Keycloak 매핑 기준)
        operator: AnyNotIn
        value: "{{ request.userInfo.groups }}" # 사용자가 속한 전체 그룹 리스트
    validate:
      message: "귀하의 AD 그룹 권한으로는 노드 레이블을 수정할 수 없습니다."
      deny:
        conditions:
        - all:
          - key: "{{ request.object.metadata.labels }}" # 변경하려는 레이블 확인
            operator: NotNull

3. Keycloak 및 K8s 설정 시 주의사항 (Prerequisites)

이 구조가 작동하려면 Keycloak과 쿠버네티스 사이의 매퍼(Mapper) 설정이 선행되어야 합니다.

  • Keycloak Client Scopes: groups라는 이름의 Protocol Mapper를 추가하여 AD의 그룹 정보가 토큰에 포함되도록 설정해야 합니다.
  • K8s API Server 설정: API 서버 실행 옵션에 다음이 포함되어 있어야 합니다.
  • --oidc-username-claim=preferred_username (또는 email)
  • --oidc-groups-claim=groups (토큰 내 groups 필드를 K8s 그룹으로 인식)

4. 워크벤치 UI와의 연동 시나리오

  1. 조회 시: 사용자가 워크벤치에 접속하면, 백엔드에서 Keycloak 토큰을 파싱하여 이 사용자가 workbench-admins 그룹인지 확인합니다. 만약 그룹에 속해 있다면 UI상에서 "레이블 수정" 버튼을 활성화합니다.
  2. 수정 시: 사용자가 버튼을 눌러 API를 호출하면, Kyverno가 최종적으로 요청을 검증합니다.
  • 만약 권한이 없는 사용자가 직접 API를 호출(우회)하더라도 Kyverno가 차단하므로 2중 보안이 됩니다.

💡 전문가의 조언: 레이블 키 기반의 세부 제어

단순히 "수정 가능"을 넘어, "AD 그룹별로 고칠 수 있는 레이블 키를 다르게" 할 수도 있습니다.

  • ML-Team 그룹: gpu-type, project-id 레이블만 수정 가능
  • Ops-Team 그룹: 모든 레이블 수정 가능

이런 식의 세부 제어가 필요하시다면, Kyverno의 foreach 구문을 사용한 Label Key-specific policy 예시를 더 자세히 구성해 드릴 수 있습니다. 어떻게 진행해 드릴까요?

profile
Young-Kyoo Kim
engineer
이전 포스트

26M11a

다음 포스트

26M13a

0개의 댓글