Kubernetes & Amazon EKS Training

한국어

English
中文
日本語
Español

한국어

English
中文
日本語
Español

Appearance

SPIFFE/SPIRE 퀴즈 ​

다음 질문들을 통해 SPIFFE/SPIRE 워크로드 아이덴티티에 대한 이해도를 점검해보세요.

문제 ​

1. SPIFFE ID의 올바른 형식은? ​

  • A) urn:spiffe:trust-domain:path
  • B) spiffe://trust-domain/path
  • C) https://trust-domain.spiffe.io/path
  • D) spiffe:trust-domain/path
정답 보기

정답: B) spiffe://trust-domain/path

설명: SPIFFE ID는 URI 형식의 워크로드 식별자입니다:

spiffe://trust-domain/path

예시:
spiffe://example.org/ns/production/sa/web-server
spiffe://cluster.local/k8s/ns/default/sa/frontend

구성요소:

  • 스킴: spiffe:// (고정)
  • Trust Domain: 조직/클러스터 식별 (예: example.org)
  • Path: 워크로드 식별 경로 (예: /ns/production/sa/web-server)

SPIFFE ID는 X.509 인증서의 SAN(Subject Alternative Name) URI 필드에 포함됩니다.

2. X.509-SVID와 JWT-SVID의 주요 차이점은? ​

  • A) X.509-SVID는 단기 토큰, JWT-SVID는 장기 인증서
  • B) X.509-SVID는 mTLS용, JWT-SVID는 API 인증용
  • C) JWT-SVID만 SPIFFE 표준
  • D) 기능적 차이 없음
정답 보기

정답: B) X.509-SVID는 mTLS용, JWT-SVID는 API 인증용

설명: SVID(SPIFFE Verifiable Identity Document) 유형별 특성:

특성X.509-SVIDJWT-SVID
형식X.509 인증서JWT 토큰
주요 용도mTLS 연결API 인증, 프록시 통과
전달 방식TLS 핸드셰이크HTTP 헤더
유효 기간보통 1시간보통 5분
검증 방식인증서 체인서명 검증
bash
# X.509-SVID 조회
/opt/spire/bin/spire-agent api fetch x509

# JWT-SVID 조회
/opt/spire/bin/spire-agent api fetch jwt -audience myservice

3. SPIRE Server의 주요 역할은? ​

  • A) 워크로드에 직접 인증서 배포
  • B) 등록 항목 관리 및 SVID 서명
  • C) 네트워크 트래픽 암호화
  • D) 서비스 디스커버리
정답 보기

정답: B) 등록 항목 관리 및 SVID 서명

설명: SPIRE Server의 핵심 기능:

┌─────────────────────────────────────────┐
│             SPIRE Server                 │
├─────────────────────────────────────────┤
│ • Registration Entry 저장/관리           │
│ • 노드 어테스테이션 검증                  │
│ • SVID 서명 (CA 역할)                    │
│ • Trust Bundle 배포                      │
│ • Agent 인증 및 권한 부여                 │
└─────────────────────────────────────────┘

Registration Entry 예시:

bash
# 워크로드 등록
spire-server entry create \
  -spiffeID spiffe://example.org/web-server \
  -parentID spiffe://example.org/host \
  -selector k8s:ns:production \
  -selector k8s:sa:web-server

Server는 중앙 집중식 ID 관리를 담당하며, 실제 워크로드와 직접 통신하지 않습니다.

4. SPIRE Agent의 주요 역할은? ​

  • A) 클러스터 전체 정책 관리
  • B) 노드에서 워크로드 어테스테이션 수행 및 SVID 전달
  • C) 인증서 서명
  • D) DNS 레코드 관리
정답 보기

정답: B) 노드에서 워크로드 어테스테이션 수행 및 SVID 전달

설명: SPIRE Agent의 역할:

┌─────────────────────────────────────────┐
│              SPIRE Agent                 │
│           (각 노드에 배포)                │
├─────────────────────────────────────────┤
│ • 워크로드 어테스테이션 (프로세스 검증)    │
│ • Workload API 노출 (Unix Socket)        │
│ • SVID 캐싱 및 자동 갱신                  │
│ • Server와 통신하여 SVID 요청             │
└─────────────────────────────────────────┘
           │
           ▼
    /run/spire/agent.sock
           │
           ▼
┌─────────────────────────────────────────┐
│            워크로드 (Pod)                 │
│    SVID 요청 → Agent가 신원 확인 후 발급   │
└─────────────────────────────────────────┘

Agent는 각 노드에서 DaemonSet으로 실행되며, 워크로드의 신원을 로컬에서 검증합니다.

5. EKS 환경에서 SPIRE 노드 어테스테이션에 권장되는 방식은? ​

  • A) k8s_sat (Service Account Token)
  • B) k8s_psat (Projected Service Account Token)
  • C) aws_iid (AWS Instance Identity Document)
  • D) join_token
정답 보기

정답: B) k8s_psat (Projected Service Account Token)

설명: EKS에서 k8s_psat 사용 이유:

yaml
# SPIRE Agent DaemonSet 설정
spec:
  containers:
  - name: spire-agent
    volumeMounts:
    - name: spire-token
      mountPath: /var/run/secrets/tokens
  volumes:
  - name: spire-token
    projected:
      sources:
      - serviceAccountToken:
          path: spire-agent
          expirationSeconds: 600
          audience: spire-server

k8s_psat vs k8s_sat:

특성k8s_satk8s_psat
토큰 만료없음있음 (설정 가능)
Audience없음지정 가능
보안 수준낮음높음
EKS 권장아니오예

PSAT은 바운드 서비스 계정 토큰으로, 만료 시간과 audience를 지정할 수 있어 더 안전합니다.

6. Kubernetes 워크로드 어테스테이션에서 사용되는 셀렉터 형식은? ​

  • A) pod:name:nginx
  • B) k8s:ns:default
  • C) kubernetes/namespace=default
  • D) selector.k8s.io/ns:default
정답 보기

정답: B) k8s:ns:default

설명: Kubernetes 워크로드 어테스테이션 셀렉터:

bash
# 워크로드 등록 예시
spire-server entry create \
  -spiffeID spiffe://example.org/frontend \
  -parentID spiffe://example.org/ns/spire/sa/spire-agent \
  -selector k8s:ns:production \           # 네임스페이스
  -selector k8s:sa:frontend \             # ServiceAccount
  -selector k8s:pod-label:app:frontend \  # Pod 레이블
  -selector k8s:container-name:app        # 컨테이너 이름

주요 셀렉터 유형:

  • k8s:ns:<namespace>: 네임스페이스 매칭
  • k8s:sa:<service-account>: ServiceAccount 매칭
  • k8s:pod-label:<key>:<value>: Pod 레이블 매칭
  • k8s:container-name:<name>: 컨테이너 이름 매칭
  • k8s:container-image:<image>: 컨테이너 이미지 매칭

7. SPIFFE CSI Driver의 주요 목적은? ​

  • A) 영구 볼륨 프로비저닝
  • B) 워크로드에 SVID를 파일 시스템으로 마운트
  • C) 네트워크 스토리지 연결
  • D) 시크릿 암호화
정답 보기

정답: B) 워크로드에 SVID를 파일 시스템으로 마운트

설명: SPIFFE CSI Driver는 Workload API 없이 SVID를 제공합니다:

yaml
apiVersion: v1
kind: Pod
spec:
  containers:
  - name: app
    volumeMounts:
    - name: spiffe
      mountPath: /run/spiffe
      readOnly: true
  volumes:
  - name: spiffe
    csi:
      driver: csi.spiffe.io
      readOnly: true

마운트되는 파일:

/run/spiffe/
├── svid.pem          # X.509 인증서
├── svid.key          # 개인키
└── bundle.pem        # Trust Bundle (CA 인증서)

장점:

  • Workload API 통합 불필요
  • 기존 애플리케이션에 쉽게 적용
  • 자동 갱신 (CSI Driver가 관리)

8. SPIFFE 페더레이션의 주요 기능은? ​

  • A) 단일 클러스터 내 서비스 통신
  • B) 서로 다른 Trust Domain 간 상호 신뢰 설정
  • C) DNS 기반 서비스 디스커버리
  • D) 로드 밸런싱
정답 보기

정답: B) 서로 다른 Trust Domain 간 상호 신뢰 설정

설명: SPIFFE 페더레이션 아키텍처:

┌────────────────────┐        ┌────────────────────┐
│  Trust Domain A    │        │  Trust Domain B    │
│  (cluster-a.com)   │◄──────►│  (cluster-b.com)   │
│                    │ 페더레이션│                    │
│  ┌──────────────┐  │        │  ┌──────────────┐  │
│  │ SPIRE Server │  │        │  │ SPIRE Server │  │
│  └──────────────┘  │        │  └──────────────┘  │
│         │          │        │         │          │
│  ┌──────────────┐  │        │  ┌──────────────┐  │
│  │  Workload A  │──────────────│  Workload B  │  │
│  └──────────────┘  │  mTLS   │  └──────────────┘  │
└────────────────────┘        └────────────────────┘

페더레이션 설정:

bash
# Trust Domain A에서 B의 번들 가져오기
spire-server bundle set \
  -id spiffe://cluster-b.com \
  -path /path/to/cluster-b-bundle.pem

사용 사례:

  • 멀티클러스터 서비스 메시
  • 하이브리드 클라우드 환경
  • 조직 간 제로 트러스트 통신

9. SPIFFE/SPIRE와 AWS IRSA(IAM Roles for Service Accounts) 비교 시 SPIFFE의 장점은? ​

  • A) AWS 네이티브 통합
  • B) IAM 정책 기반 세분화된 권한
  • C) 클라우드 중립적이며 워크로드 간 mTLS 지원
  • D) 설정 간편함
정답 보기

정답: C) 클라우드 중립적이며 워크로드 간 mTLS 지원

설명: SPIFFE/SPIRE vs IRSA 비교:

특성SPIFFE/SPIREIRSA
클라우드 의존성없음AWS 전용
워크로드 간 인증mTLS 지원미지원
AWS 서비스 접근별도 설정 필요네이티브
멀티클라우드지원불가
온프레미스지원불가
복잡도높음낮음

SPIFFE/SPIRE 선택 상황:

  • 워크로드 간 mTLS가 필요한 경우
  • 멀티클라우드/하이브리드 환경
  • 클라우드 독립적인 아이덴티티 필요 시

IRSA 선택 상황:

  • AWS 서비스 접근만 필요한 경우
  • 단순한 설정 선호 시

10. SPIFFE Trust Domain 네이밍 모범 사례는? ​

  • A) 임의의 문자열 사용
  • B) IP 주소 기반
  • C) 조직 도메인 또는 클러스터 식별자 사용
  • D) 숫자로만 구성
정답 보기

정답: C) 조직 도메인 또는 클러스터 식별자 사용

설명: Trust Domain 네이밍 권장사항:

좋은 예시:
✓ spiffe://example.org              # 조직 도메인
✓ spiffe://prod.example.org         # 환경별 구분
✓ spiffe://cluster-1.example.org    # 클러스터별 구분
✓ spiffe://us-east-1.aws.example.org # 리전별 구분

나쁜 예시:
✗ spiffe://my-cluster              # 조직 식별 불가
✗ spiffe://192.168.1.100           # IP 변경 시 문제
✗ spiffe://12345                   # 의미 없음
✗ spiffe://test                    # 모호함

네이밍 원칙:

  • 고유성: 전역적으로 유일해야 함
  • 계층 구조: 조직/환경/클러스터 반영
  • 안정성: 장기간 변경 없이 유지
  • 의미 전달: 도메인 목적을 명확히 표현
  • DNS 호환: 페더레이션 시 DNS로 번들 조회 가능

점수 계산 ​

  • 9-10개 정답: 우수 - 해당 주제를 깊이 이해하고 있습니다.
  • 7-8개 정답: 양호 - 핵심 개념을 잘 파악하고 있습니다.
  • 5-6개 정답: 보통 - 추가 학습이 필요한 부분이 있습니다.
  • 4개 이하: 문서를 다시 복습하시기 바랍니다.

관련 문서 ​