Secret

• 암호/토큰/인증서/접속정보처럼 민감한 값을 저장하는 리소스
• 왜 필요?
  • 오퍼레이터나 파드가 외부 시스템(예:Elasticsearch, S3, DB) 또는 내부 컴포넌트와 통신할 때 자격증명이 필요하다. 이걸 YAML에 평문으로 넣지 않고 Secret으로 분리
• 특징
  • base64 인코딩으로 저장(암호화는 별도 설정: at-rest encryption/KMS)
  • 파드에 환경변수나 볼륨으로 주입
  • 네임스페이스 스코프
• 자주 쓰는 예
  • TLS 인증서/키(tls.crt, tls.key), basic auth, API 토큰, 이미지 풀 시크릿, DB 비밀번호 등
• 예: 엘라스틱서치 접속용 시크릿

apiVersion: v1
kind: Secret
metadata:
  name: es-secret
  namespace: openshift-logging
type: Opaque
stringData:
  username: admin
  password: "S3cr3tP@ss!"

CRD & CR

• CRD (CustomResourceDafinition)

  • “새로운 타입의 리소스 스키마”를 클러스터에 정의한다.
  • 예 : ClusterLogForwarder.logging.openshift.io, kafka.kafka,strimzi.io 등

• CR( Custom Resource)

  • CRD로 정의한 타입으 ㅣ실제 인스턴스(=원하는 상태)
  • 사용자는 CR의 spec에 “원하는 구성(Desired State)을 적는다.
  • 오퍼레이터는 이 CR을 읽고 실제 리소스
    • (Deployment/Service/Secret/ConfigMap/Route/PV 등)를 조합해 만든다.

• 왜 CR을 쓰나?

  • 복잡한 앱 스택(오퍼랜드)을 단순한 선언형 yaml 한 장으로 편하게 관리
  • 검증/기본값/없그레이드 호환성 등을 오퍼레이터가 책임

• 예시: Logging Operator의 ClusterLogForwarder CR

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
    - name: elasticsearch-secure
      type: elasticsearch
      url: <https://es.example.com:9200>
      secret:
        name: es-secret     # ↑ 위에서 만든 Secret을 참조
  pipelines:
    - name: app
      inputRefs: [application]
      outputRefs: [elasticsearch-secure]

오퍼레이터 구성 흐름 (큰 그림)

• OLM(Operator Lifecycle Manager)