Teleport의 Sigstore 통합을 사용하면 워크로드 신원과 그것이 보호하는 리소스에 대한 접근을 서명된 컨테이너 이미지로만 제한하여 공급망 공격의 범위를 줄일 수 있습니다.

작동 방식#

서명#

아티팩트 서명 및 증명은 cosign 또는 GitHub의 attest-build-provenance 액션과 같은 Sigstore 호환 도구를 사용하여 생성됩니다.

키리스 모드에서는 이러한 서명이 Fulcio에서 발행된 일회용 X.509 인증서로 서명되며, 이 인증서는 서명자의 OIDC 신원(예: 사용자의 Google 계정 또는 GitHub Actions 토큰)을 인코딩합니다.

사용자는 대안으로 전통적인 장기 개인/공개 키 쌍으로 서명하고 소비자에게 직접 공개 키를 배포할 수 있습니다.

서명과 관련 메타데이터는 감사 가능성, 부인 방지 및 서명 타임스탬프를 위해 Rekor 투명성 로그에 기록됩니다. 키리스 서명 인증서의 단기 특성으로 인해 인증서의 유효 기간(not before, not after)을 사용할 수 없기 때문입니다.

사용자는 투명성 로그의 다른 기능이 필요하지 않은 경우 Rekor 대신 또는 Rekor에 추가로 RFC 3161 타임스탬프 기관을 사용할 수 있습니다.

서명, 인증서, 투명성 로그 포함 증명 및 RFC 3161 타임스탬프는 컨테이너 이미지 레지스트리에 업로드됩니다.

검증#

컨테이너 기반 워크로드가 tbot의 SPIFFE Workload API에 연결하면, tbot은 플랫폼별 증명자(예: Kubernetes, Docker 또는 Podman)를 사용하여 워크로드가 실행 중인 컨테이너 이미지를 검색합니다. 그런 다음 해당 특정 이미지 다이제스트와 관련된 서명을 위해 관련 컨테이너 레지스트리에 쿼리합니다. 이러한 서명은 SVID를 요청할 때 Teleport Auth Service로 전송됩니다.

WorkloadIdentity 규칙에 sigstore.policy_satisfied 호출이 포함된 경우, Auth Service는 지정된 SigstorePolicy 객체를 로드하고 평가합니다.

이러한 정책은 서명의 진위를 검증하는 데 사용할 "신뢰할 수 있는 루트"를 결정하는 데 사용됩니다. 키리스 서명의 경우 Fulcio 및 Rekor 인증서 체인이 포함됩니다. 전통적인 키 기반 서명의 경우 서명자의 공개 키가 사용됩니다.

정책에는 서명에 대한 요구 사항도 포함되어 있습니다. 예를 들어 어떤 in-toto 증명 술어 유형이 필요한지 또는 cosign 단순 서명 기반 아티팩트 서명이 필요한지 여부 등입니다.

SigstorePolicy 리소스#

kind: sigstore_policy
version: v1
metadata:
  # SigstorePolicy 리소스의 이름. `sigstore.policy_satisfied` 규칙
  # 표현식 함수의 매개변수로 사용됩니다.
  name: github-provenance
spec:
  # Sigstore의 키리스 모드 구성.
  #
  # `key`와 상호 배타적입니다.
  keyless:
    # 신뢰할 수 있는 서명 신원. 여러 신원이 주어진 경우, 정책이
    # 충족되려면 최소 하나가 일치해야 합니다.
    identities:
    -
      # OIDC 발행자와 정확히 일치합니다.
      issuer: https://accounts.google.com
      # OIDC 신원과 정확히 일치합니다.
      subject: security@example.com
    -
      # 정규식을 사용하여 OIDC 발행자와 일치합니다.
      issuer_regex: ^https://token.actions.githubusercontent.com(/asteroid-earth)?$
      # 정규식을 사용하여 OIDC 신원과 일치합니다.
      subject_regex: ^https://github.com/asteroid-earth/(.*)/\.github/workflows/(.*)@refs/heads/main$

  # "Public Good" 인스턴스가 아닌 프라이빗 Sigstore 인프라를 사용할 때
  # 공급할 수 있는 사용자 지정 신뢰할 수 있는 루트 목록. 루트는 인증
  # 기관 중 하나에서 발행한 인증서가 신뢰되도록 결합됩니다.
  #
  # `application/vnd.dev.sigstore.trustedroot+json;version=0.1`
  # JSON 문자열 형식.
  trusted_roots:
    - |
      {
        "mediaType": "application/vnd.dev.sigstore.trustedroot+json;version=0.1",
        "certificateAuthorities": [
        ...

  # 전통적인 키 기반 서명 검증 구성.
  #
  # `keyless`와 상호 배타적입니다.
  key:
    # PEM 인코딩 DER 형식의 공개 키. RSA, ECDSA 또는 Ed25519 키여야 합니다.
    public: |
      -----BEGIN PUBLIC KEY-----
      MCowBQYDK2VwAyEAA6h8OgaAX0htOLNP5hwaENfcivylMa8yBuOqD7k6kYE=
      -----END PUBLIC KEY-----

  # 정책이 충족되기 위해 존재해야 하는 서명 및 증명.
  requirements:
    # cosign 단순 서명 기반 아티팩트 서명이 있어야 하는지 여부.
    #
    # `attestations`와 상호 배타적입니다.
    artifact_signature: false

    # 존재해야 하는(모두) 증명.
    #
    # `artifact_signature`와 상호 배타적입니다.
    attestations:
    -
      # 필요한 증명의 in-toto 술어 유형.
      predicate_type: https://slsa.dev/provenance/v1

RSA-PSS는 현재 지원되지 않습니다.

예시: GitHub 아티팩트 증명#

공개 저장소에서 attest-build-provenance 액션을 사용하는 경우, GitHub는 Sigstore의 Public Good 인스턴스의 Fulcio와 Rekor를 사용하므로 신뢰할 수 있는 신원과 필요한 증명만 구성하면 됩니다.

kind: sigstore_policy
version: v1
metadata:
  name: github-provenance
spec:
  keyless:
    identities:
      - issuer: https://token.actions.githubusercontent.com
        subject_regex: ^https://github.com/asteroid-earth/(.*)/\.github/workflows/(.*)@refs/heads/main$
  requirements:
    attestations:
      - predicate_type: https://slsa.dev/provenance/v1

GitHub Enterprise 고객은 Rekor 대신 GitHub의 내부 Fulcio 인스턴스와 GitHub 자체 타임스탬프 기관을 사용하는 프라이빗 저장소에서 아티팩트 증명을 사용할 수 있습니다.

프라이빗 저장소의 서명을 지원하려면 GitHub CLI를 사용하여 신뢰할 수 있는 루트를 내보내세요:

$ gh attestation trusted-root

이는 줄 바꿈으로 구분된 JSON 신뢰 루트 객체 목록을 반환하며, 이를 정책의 keyless 섹션에 사용할 수 있습니다.

GitHub의 내부 Fulcio 인스턴스를 사용할 때, 서명 인증서의 OIDC 발행자에는 조직 이름이 접미사로 붙습니다.

kind: sigstore_policy
version: v1
metadata:
  name: github-provenance
spec:
  keyless:
    identities:
      - issuer_regex: ^https://token.actions.githubusercontent.com(/asteroid-earth)?$
        subject_regex: ^https://github.com/asteroid-earth/(.*)/\.github/workflows/(.*)@refs/heads/main$
    trusted_roots:
      -  |
        {"mediaType":"application/vnd.dev.sigstore.trustedroot+json;version=0.1" ...
      -  |
        {"mediaType":"application/vnd.dev.sigstore.trustedroot+json;version=0.1" ...
  requirements:
    attestations:
      - predicate_type: https://slsa.dev/provenance/v1

타임스탬프 및 투명성 로그 요구 사항#

키리스 모드를 사용할 때, 키리스 인증서를 신뢰하기 위해서는 투명성 로그 포함 증명 또는 RFC 3161 타임스탬프 중 하나가 필요합니다.

따라서 사용자 지정 trusted_roots를 지정할 때는 tlogs 또는 timestamp_authorities 목록에 최소 하나의 항목이 있어야 합니다. 항목이 여러 개 있는 경우, 서명은 그 중 하나에만 일치하면 됩니다. 예를 들어 여러 투명성 로그가 구성된 경우, 서명은 그 중 하나에만 포함되어 있으면 검증됩니다.

WorkloadIdentity 규칙#

Teleport가 SVID 발행 여부를 결정할 때 정책을 적용하려면, WorkloadIdentity 규칙 표현식에서 sigstore.policy_satisfied 함수를 호출하세요.

이 함수는 여러 정책 이름을 허용하고 tbot이 제시한 서명으로 지정된 모든 정책이 충족되었는지 여부를 나타내는 불리언 값을 반환합니다.

kind: workload_identity
version: v1
metadata:
  labels:
    application: k8s-service
  name: k8s-workload-identity
spec:
  spiffe:
    id: /k8s/{{ workload.kubernetes.labels["app"] }}
  rules:
    allow:
      - expression: |
          sigstore.policy_satisfied("github-provenance", "security-scan") || sigstore.policy_satisfied("security-team-signoff")

tbot 구성#

services:
  - type: workload-identity-api
    listen: unix:///run/tbot/sockets/workload.sock
    selector:
      name: k8s-workload-identity
    attestors:
      sigstore:
        enabled: true
        additional_registries:
          - host: ghcr.io
        credentials_path: /path/to/docker/config.json
        allowed_private_network_prefixes:
          - "192.168.1.42/32"
          - "fd12:3456:789a:1::1/128"

tbot이 워크로드의 컨테이너 이미지에 대한 서명을 검색하려면, Sigstore 증명자와 함께 컨테이너 플랫폼용 증명자(예: Kubernetes, Docker 또는 Podman)도 활성화해야 합니다.

기본적으로 Sigstore 증명자는 이미지의 소스 레지스트리에서 서명을 찾지만, 다른 레지스트리를 통해 서명을 배포하는 경우 additional_registries를 설정할 수 있습니다.

프라이빗 레지스트리#

레지스트리에 인증이 필요한 경우, credentials_path를 사용하여 auths 섹션에 레지스트리별 자격 증명이 포함된 Docker 또는 Podman 구성 파일을 제공할 수 있습니다.

credentials_path를 지정하지 않으면, tbot은 기본적으로 다음 위치를 찾습니다:

• $HOME/.docker/config.json
• $DOCKER_CONFIG
• $REGISTRY_AUTH_FILE
• $XDG_RUNTIME_DIR/containers/auth.json

tbot은 Docker의 cli 패키지를 사용하므로 docker-credential-gcr과 같은 자격 증명 헬퍼도 지원합니다.

tbot용 자격 증명 파일을 만드는 가장 간단한 방법은 docker login을 사용하고 $HOME/.docker/config.json에서 auths 및 credHelpers 섹션을 복사하는 것입니다.

기본적으로 tbot은 SSRF 공격의 표면을 줄이기 위해 RFC 1918에서 프라이빗 사용을 위해 지정된 IP 범위와 같은 프라이빗 네트워크 주소에 호스팅된 레지스트리에 연결하는 것을 거부합니다. 레지스트리가 프라이빗 네트워크에 있는 경우, CIDR 표기법을 사용하여 allowed_private_network_prefixes 목록에 해당 IP를 추가할 수 있습니다.

Kubernetes 레지스트리 자격 증명 사용#

Kubernetes에서 tbot을 실행하는 경우, kubelet이 이미지를 가져올 수 있도록 레지스트리에 대한 자격 증명이 이미 구성되어 있을 것입니다.

$ kubectl create secret docker-registry docker-credentials \
  --docker-server=<your-registry-server> \
  --docker-username=<your-name> \
  --docker-password=<your-password> \
  --docker-email=<your-email>

Sigstore 증명자가 이러한 자격 증명을 사용하도록 구성하려면, tbot DaemonSet에 시크릿을 볼륨으로 마운트하고 credentials_path 또는 $DOCKER_CONFIG가 이를 가리키도록 할 수 있습니다:

spec:
  template:
    spec:
      containers:
        - name: tbot
          volumeMounts:
            - mountPath: /var/run/secrets/docker
              name: docker-credentials
          env:
            - name: DOCKER_CONFIG
              value: /var/run/secrets/docker/.dockerconfigjson
      volumes:
        - name: docker-credentials
          secret:
            secretName: docker-credentials