워크로드 아이덴티티 API 서비스(workload-identity-api)는 워크로드가 즉석에서 JWT 및 X509 워크로드 신원 자격 증명을 요청할 수 있게 하는 구성 가능한 tbot 서비스입니다.

자격 증명을 디스크에 쓰는 것보다 더 안전한 대안이며, 자격 증명을 발행하기 전에 워크로드의 속성을 결정하기 위한 워크로드 증명이라는 프로세스 수행을 지원합니다.

워크로드 아이덴티티 API는 두 가지 표준과 호환됩니다:

• SPIFFE Workload API
• Envoy SDS

워크로드에 자격 증명을 발행하는 것 외에도, 워크로드 아이덴티티 API는 워크로드가 다른 워크로드의 자격 증명을 검증하는 데 필요한 신뢰 번들도 제공할 수 있습니다.

구성#

# type은 서비스의 유형을 지정합니다. 워크로드 아이덴티티 API 서비스의 경우
# 항상 `workload-identity-api`입니다.
type: workload-identity-api
# listen은 서비스가 수신 대기해야 하는 주소를 지정합니다.
#
# 두 가지 유형의 리스너가 지원됩니다:
# - TCP: `tcp://<address>:<port>`
# - Unix 소켓: `unix:///<path>`
listen: unix:///opt/machine-id/workload.sock
# attestors는 이 Workload API에 대한 워크로드 증명을 구성할 수 있게 합니다.
attestors:
  # docker는 Docker 워크로드 증명자에 대한 구성입니다. 자세한 내용은
  # 아래 Docker 섹션을 참조하세요.
  docker:
    # enabled는 워크로드의 신원이 Docker 컨테이너에 대한 정보로
    # 증명되어야 하는지 지정합니다. 지정하지 않으면 기본값은 false입니다.
    enabled: true
    # addr는 Docker Engine 데몬에 연결할 수 있는 주소입니다.
    # TCP를 통한 연결은 현재 지원되지 않으므로 `unix://path/to/socket`
    # 형식이어야 합니다. 지정하지 않으면 "rootful" Docker 설치의 표준
    # 소켓 위치인 `unix:///var/run/docker.sock`이 기본값입니다.
    addr: unix:///var/run/docker.sock
  # kubernetes는 Kubernetes 워크로드 증명자에 대한 구성입니다. 자세한 내용은
  # Kubernetes 워크로드 증명자 섹션을 참조하세요.
  kubernetes:
    # enabled는 Kubernetes 워크로드 증명자를 활성화해야 하는지 지정합니다.
    # 지정하지 않으면 기본값은 false입니다.
    enabled: true
    # kubelet은 Kubernetes 워크로드 증명자의 Kubelet API와의 상호 작용에
    # 관련된 구성을 보유합니다.
    kubelet:
      # read_only_port는 읽기 전용 작업을 위해 Kubelet API가 노출되는
      # 포트입니다. Kubernetes 1.16 이후로 읽기 전용 포트는 기본적으로
      # 비활성화되어 있으므로 대신 secure_port를 사용해야 합니다.
      read_only_port: 10255
      # secure_port는 증명자가 Kubelet 보안 API에 연결해야 하는 포트입니다.
      # 지정하지 않으면 기본값은 `10250`입니다. ReadOnlyPort와 상호 배타적입니다.
      secure_port: 10250
      # token_path는 Kubelet API 클라이언트가 Kubelet API로 인증하는 데
      # 사용해야 하는 토큰 파일 경로입니다. 지정하지 않으면 기본값은
      # `/var/run/secrets/kubernetes.io/serviceaccount/token`입니다.
      token_path: "/var/run/secrets/kubernetes.io/serviceaccount/token"
      # ca_path는 Kubelet API 클라이언트가 Kubelet API 서버의 인증서를
      # 검증하는 데 사용해야 하는 CA 파일 경로입니다. 지정하지 않으면
      # 기본값은 `/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`입니다.
      ca_path: "/var/run/secrets/kubernetes.io/serviceaccount/ca.crt"
      # skip_verify는 Kubelet API 서버의 인증서 검증을 비활성화하는 데
      # 사용됩니다. 지정하지 않으면 기본값은 false입니다.
      #
      # 지정하면 ca_path에 지정된 값이 무시됩니다.
      #
      # 이는 Kubelet API 서버에 Kubernetes 클러스터 CA가 서명한 인증서가
      # 발급되지 않은 경우에 유용합니다. 이는 여러 Kubernetes 배포판에서
      # 꽤 일반적입니다.
      skip_verify: true
      # anonymous는 Kubelet API 인증을 비활성화하는 데 사용됩니다.
      # 지정하지 않으면 기본값은 false입니다. 설정하면 token_path 필드가
      # 무시됩니다.
      anonymous: false
  # podman은 Podman 워크로드 증명자에 대한 구성입니다. 자세한 내용은
  # 아래 Podman 섹션을 참조하세요.
  podman:
    # enabled는 워크로드의 신원이 Podman 컨테이너 및 파드에 대한 정보로
    # 증명되어야 하는지 지정합니다. 지정하지 않으면 기본값은 false입니다.
    enabled: true
    # addr는 Podman API 서비스에 연결할 수 있는 주소입니다.
    # TCP는 지원되지 않으므로 `unix://path/to/socket` 형식이어야 합니다.
    # 이 필드는 필수이며 기본값이 없습니다. 자세한 내용은 아래 Podman
    # 섹션을 참조하세요.
    addr: unix:///run/podman/podman.sock
  # sigstore는 Sigstore 워크로드 증명자에 대한 구성입니다. 자세한 내용은
  # Sigstore 워크로드 증명 페이지를 참조하세요.
  sigstore:
    # enabled는 tbot이 워크로드의 컨테이너 이미지에 대한 Sigstore 서명을
    # 검색할지 지정합니다. 지정하지 않으면 기본값은 false입니다.
    enabled: true
    # additional_registries는 워크로드 컨테이너 이미지의 소스 레지스트리
    # 외에 서명을 검색할 OCI 레지스트리를 선택적으로 구성합니다.
    additional_registries:
      -
        # OCI 레지스트리의 호스트.
        host: ghcr.io
    # credentials_path는 레지스트리별 자격 증명이 포함된 Docker 또는
    # Podman 구성 파일 경로입니다.
    credentials_path: /path/to/docker/config.json
    # allowed_private_network_prefixes는 Sigstore 증명자가 연결할 수 있는
    # 프라이빗 IP 주소 접두사(CIDR 블록)입니다. 기본적으로 tbot은 SSRF
    # 공격의 표면을 줄이기 위해 공개적으로 라우팅 가능한 IP 주소의
    # 레지스트리에만 연결합니다.
    allowed_private_network_prefixes:
      - "192.168.1.42/32"
      - "fd12:3456:789a:1::1/128"
  # systemd는 Systemd 워크로드 증명자에 대한 구성입니다. 자세한 내용은
  # 아래 Systemd 섹션을 참조하세요.
  systemd:
    # enabled는 워크로드의 신원이 Systemd 서비스에 대한 정보로 증명되어야
    # 하는지 지정합니다. 지정하지 않으면 기본값은 false입니다.
    enabled: true
  # unix는 Unix 워크로드 증명자에 대한 구성입니다.
  unix:
    # binary_hash_max_size_bytes는 SHA-256 체크섬을 계산하기 위해 프로세스의
    # 바이너리에서 읽을 최대 바이트 수입니다. 바이너리가 이보다 크면
    # `workload.unix.binary_hash` 속성이 비어 있습니다. 지정하지 않으면
    # 기본값은 1GiB입니다. 무제한으로 설정하려면 -1로 설정하세요.
    binary_hash_max_size_bytes: 1024
<!-- INCLUDE:ENGLISH:docs/pages/includes/machine-id/workload-identity-selector-config.yaml -->
# Selector is used to control which WorkloadIdentity resource will be used to
# issue the workload identity credential. The selector can either be the name of
# a specific WorkloadIdentity resource or a label selector that can match
# multiple WorkloadIdentity resources.
#
# The selector must be set to either a name or labels, but not both.
selector:
  # Name is used to select a specific WorkloadIdentity resource by its name.
  name: foo
  # Labels is used to select multiple WorkloadIdentity resources by their labels.
  labels:
    app: [foo, bar]
<!-- /INCLUDE:ENGLISH -->

SPIFFE Workload API#

워크로드 아이덴티티 API는 SPIFFE Workload API를 구현합니다. 이는 워크로드가 워크로드 신원 자격 증명과 신뢰 번들을 요청하는 표준화된 API입니다.

이 API를 통해 JWT 및 X509 워크로드 신원 자격 증명을 모두 발행할 수 있습니다.

워크로드 증명#

워크로드 증명은 tbot이 Workload API에 연결하여 자격 증명을 요청한 워크로드의 신원을 확인하기 위해 완료하는 프로세스입니다.

워크로드 증명자는 이 증명을 수행하는 개별 구성 요소입니다. 워크로드의 프로세스 ID를 사용하여 플랫폼별 API에서 워크로드에 대한 정보를 수집합니다. 예를 들어, Kubernetes 워크로드 증명자는 로컬 Kubelet API에 쿼리하여 프로세스가 속한 Kubernetes 파드를 확인합니다.

이 증명 프로세스의 결과는 증명 메타데이터로 알려져 있습니다. 이 증명 메타데이터는 WorkloadIdentity 리소스의 일부로 구성하는 규칙이나 템플릿에 포함될 수 있습니다.

Unix#

Unix 워크로드 증명자는 가장 기본적인 증명자로, 다양한 기준에 따라 특정 Unix 프로세스에 대한 워크로드 신원 발행을 제한할 수 있습니다.

비표준 procfs 마운트 지원#

PID에서 프로세스에 대한 정보를 확인하기 위해 Unix 워크로드 증명자는 procfs 파일시스템에서 정보를 읽습니다. 기본적으로 procfs가 /proc에 마운트되어 있다고 가정합니다.

procfs가 다른 위치에 마운트된 경우, HOST_PROC 환경 변수를 설정하여 Unix 워크로드 증명자가 해당 대체 위치에서 읽도록 구성해야 합니다.

이는 민감한 구성 옵션이므로 올바르게 설정되었는지 또는 전혀 설정되지 않았는지 확인해야 합니다. 잘못 구성된 경우, 공격자가 프로세스에 대한 위조된 정보를 제공할 수 있으며, 이로 인해 권한이 없는 워크로드에 SVID가 발행될 수 있습니다.

binary_path 및 binary_hash 속성#

Unix 워크로드 증명자는 /proc/$pid/exe 심볼릭 링크를 사용하여 워크로드 실행 파일의 경로와 SHA-256 체크섬을 캡처합니다. 규칙에서 이러한 속성을 사용할 때 고려해야 할 중요한 사항이 있습니다:

• tbot은 동일한 마운트 네임스페이스에서 실행 중인 경우에만 프로세스의 실행 파일 경로를 안정적으로 확인할 수 있습니다. 워크로드가 컨테이너화된 경우 binary_path 속성이 올바르지 않을 수 있습니다.
• /proc/$pid/exe는 일반 경로가 아닌 inode에 대한 심볼릭 링크이므로, 바이너리가 디스크에서 교체된 경우에도(예: 롤링 배포 중) 프로세스가 실행 중인 것을 정확하게 나타내는 경우가 많습니다. 그러나 네트워크 파일시스템은 inode 안정성을 보장하지 않으므로, 프로세스의 실행 파일이 네트워크 마운트에 있는 경우 binary_hash가 오래된 것일 수 있습니다.
• 기본적으로 tbot은 1GiB보다 작은 바이너리만 체크섬합니다. 이를 변경하려면 attestors.unix.binary_hash_max_size_bytes를 늘리세요.

Kubernetes#

Kubernetes 워크로드 증명자를 사용하면 다양한 기준에 따라 특정 Kubernetes 워크로드에 대한 워크로드 신원 발행을 제한할 수 있습니다.

특정 프로세스 ID에 대한 파드 ID를 먼저 확인한 다음, 로컬 kubelet API에 해당 파드에 대한 세부 정보를 쿼리하여 작동합니다.

배포 지침#

Kubernetes 워크로드 증명을 사용하려면 tbot을 데몬셋으로 배포해야 합니다. 이는 Unix 도메인 소켓이 에이전트와 동일한 노드의 파드에서만 접근할 수 있기 때문입니다. 또한 데몬셋은 에이전트가 다른 컨테이너 내의 프로세스에 대한 정보에 접근할 수 있도록 hostPID 속성을 true로 설정해야 합니다.

데몬셋에는 Kubelet API에 쿼리할 수 있는 서비스 계정도 할당되어야 합니다. 다음은 필요한 RBAC가 있는 예시 역할입니다:

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: tbot
rules:
  - resources: ["pods","nodes","nodes/proxy"]
    apiGroups: [""]
    verbs: ["get"]

Workload API Unix 도메인 소켓을 워크로드의 컨테이너에 매핑하는 두 가지 방법이 있습니다:

• tbot 데몬셋 및 연결이 필요한 워크로드에 대해 hostPath 볼륨을 직접 구성.
• spiffe-csi-driver 사용.

필요한 Kubernetes 리소스에 대한 예시 매니페스트:

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: tbot
rules:
  - resources: ["pods","nodes","nodes/proxy"]
    apiGroups: [""]
    verbs: ["get"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: tbot
subjects:
  - kind: ServiceAccount
    name: tbot
    namespace: default
roleRef:
  kind: ClusterRole
  name: tbot
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: tbot
  namespace: default
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: tbot-config
  namespace: default
data:
  tbot.yaml: |
    version: v2
    onboarding:
      join_method: kubernetes
      # replace with the name of a join token you have created.
      token: example-token
    storage:
      type: memory
    # ensure this is configured to the address of your Teleport Proxy Service.
    proxy_server: example.teleport.sh:443
    services:
      - type: workload-identity-api
        listen: unix:///run/tbot/sockets/workload.sock
        attestor:
          kubernetes:
            enabled: true
            kubelet:
              # skip verification of the Kubelet API certificate as this is not
              # usually issued by the cluster CA.
              skip_verify: true
        selector:
          name: example-workload-identity
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: tbot
spec:
  selector:
      matchLabels:
        app: tbot
  template:
    metadata:
      labels:
        app: tbot
    spec:
      securityContext:
        runAsUser: 0
        runAsGroup: 0
      hostPID: true
      containers:
        - name: tbot
          image: public.ecr.aws/gravitational/tbot-distroless:(=teleport.version=)
          imagePullPolicy: IfNotPresent
          securityContext:
            privileged: true
          args:
            - start
            - -c
            - /config/tbot.yaml
            - --log-format
            - json
          volumeMounts:
            - mountPath: /config
              name: config
            - mountPath: /var/run/secrets/tokens
              name: join-sa-token
            - name: tbot-sockets
              mountPath: /run/tbot/sockets
              readOnly: false
          env:
            - name: TELEPORT_NODE_NAME
              valueFrom:
                fieldRef:
                  fieldPath: spec.nodeName
            - name: KUBERNETES_TOKEN_PATH
              value: /var/run/secrets/tokens/join-sa-token
      serviceAccountName: tbot
      volumes:
        - name: tbot-sockets
          hostPath:
            path: /run/tbot/sockets
            type: DirectoryOrCreate
        - name: config
          configMap:
            name: tbot-config
        - name: join-sa-token
          projected:
            sources:
              - serviceAccountToken:
                  path: join-sa-token
                  # 600 seconds is the minimum that Kubernetes supports. We
                  # recommend this value is used.
                  expirationSeconds: 600
                  # `example.teleport.sh` must be replaced with the name of
                  # your Teleport cluster.
                  audience: example.teleport.sh

Docker#

Docker 워크로드 증명자를 사용하면 다양한 기준에 따라 특정 Docker 컨테이너에 대한 워크로드 신원 발행을 제한할 수 있습니다.

특정 프로세스에 대한 컨테이너를 먼저 확인한 다음, Docker Engine API에 해당 컨테이너에 대한 세부 정보를 쿼리하여 작동합니다.

Docker Engine API 접근 권한 부여#

기본적으로 tbot은 "rootful" Docker 배포의 표준 위치인 /var/run/docker.sock에 있는 Unix 도메인 소켓을 통해 Docker 데몬에 연결을 시도합니다.

tbot이 루트로 실행되지 않는 경우, 이 소켓에 접근 권한을 부여하기 위해 해당 사용자를 docker 그룹에 추가해야 합니다:

$ sudo usermod -a -G docker $TBOT_USER

Rootless Docker#

"rootless" 모드로 Docker를 실행하는 경우, 데몬의 소켓은 기본적으로 $XDG_RUNTIME_DIR/docker.sock에 위치하여 다른 루트가 아닌 사용자가 접근할 수 없습니다.

tbot을 Docker와 동일한 사용자 또는 루트로 실행하지 않으려면, 다음 내용이 포함된 ~/.config/docker 아래에 구성 파일을 생성하여 이를 재정의할 수 있습니다:

{
  "hosts": ["unix://path/to/socket"]
}

Podman#

Podman 워크로드 증명자를 사용하면 다양한 기준에 따라 특정 Podman 컨테이너 및 파드에 대한 워크로드 신원 발행을 제한할 수 있습니다.

특정 프로세스에 대한 컨테이너와 파드를 먼저 확인한 다음, Podman API 서비스에 세부 정보를 쿼리하여 작동합니다.

Podman은 장기 실행 데몬 프로세스를 사용하지 않는다는 점에서 Docker와 다릅니다. 대신, API 서비스는 일반적으로 소켓 활성화를 사용하여 필요 시 시작됩니다.

tbot에 Podman API 접근 권한 부여는 "rootful"로 실행하는지 "rootless"로 실행하는지에 따라 다른 단계가 필요합니다. 이러한 이유로 attr 구성 옵션에 기본값을 제공하지 않습니다.

Rootful Podman#

루트로 Podman을 실행하는 경우, 다음을 실행하여 API 서비스를 활성화하세요:

$ sudo systemctl enable --now podman.socket

이 시점에서 서비스는 /run/podman/podman.sock에서 접근할 수 있지만 루트만 접근 가능합니다. tbot을 루트로 실행하지 않으려면, tbot 사용자가 속한 그룹이 소켓을 소유하도록 기본 systemd 유닛을 재정의할 수 있습니다:

$ sudo groupadd podman-root
$ sudo usermod -a -G podman-root $TBOT_USER
$ sudo systemctl edit podman.socket

재정의 파일에 다음을 추가하세요:

[Socket]
 SocketGroup=podman-root

systemd 데몬을 다시 로드하고 소켓 유닛을 재시작하세요:

$ sudo systemctl daemon-reload
$ sudo systemctl restart podman.socket

Rootless Podman#

루트가 아닌 사용자로 Podman을 실행하는 경우, 다음을 실행하여 API 서비스를 활성화하고 시작하세요:

$ sudo loginctl enable-linger $PODMAN_USER
$ systemctl --user enable --now podman.socket

이제 서비스는 $XDG_RUNTIME_DIR/podman/podman.sock에서 접근할 수 있지만, 선택한 podman 사용자 또는 루트만 접근 가능합니다. tbot을 동일한 사용자 또는 루트로 실행하지 않으려면, 기본 systemd 유닛을 재정의하여 소켓을 $XDG_RUNTIME_DIR 밖으로 이동하고 tbot 사용자를 podman 사용자의 그룹에 추가할 수 있습니다:

$ sudo usermod -a -G $PODMAN_USER_GROUP $TBOT_USER
$ systemctl --user edit podman.socket

재정의 파일에 다음을 추가하세요:

[Socket]
ListenStream=/path/to/socket # Example: /srv/podman.$PODMAN_USER/podman.sock

systemd 데몬을 다시 로드하고 소켓 유닛을 재시작하세요:

$ systemctl --user daemon-reload
$ systemctl --user restart podman.socket

컨테이너에서 tbot 실행#

컨테이너 내부에서 실행 중인 tbot이 다른 컨테이너의 워크로드를 증명하려면, 호스트의 PID 네임스페이스에 접근할 수 있어야 합니다. 또한 그룹 권한을 사용하여 tbot에 Podman 소켓 접근 권한을 부여하는 경우(위의 예시 참조), run.oci.keep_original_groups 어노테이션을 설정해야 합니다.

$ podman run \
  --pid=host \
  --annotation run.oci.keep_original_groups=1 \
  --volume /path/to/socket:/path/to/socket \
  --volume /path/to/config:/path/to/config \
  public.ecr.aws/gravitational/tbot-distroless:(=teleport.version=) \
  start -c /path/to/config

Systemd#

Systemd 워크로드 증명자를 사용하면 특정 Systemd 서비스에 대한 워크로드 신원 발행을 제한할 수 있습니다. 주어진 프로세스의 서비스 유닛을 확인하기 위해 Systemd의 D-Bus API와 상호 작용하여 작동합니다.

tbot은 DBUS_SYSTEM_BUS_ADDRESS 환경 변수를 사용하지만, 설정되지 않은 경우 기본적으로 /var/run/dbus/system_bus_socket에 있는 Unix 도메인 소켓을 통해 연결합니다.

이 소켓을 사용한 연결이 실패하면, tbot은 대신 /run/systemd/private에 있는 소켓을 사용하려 시도하지만, 이는 일반적으로 루트만 접근 가능합니다.

Sigstore#

Sigstore 워크로드 증명자를 사용하면 서명된 컨테이너 이미지를 실행하는 워크로드에만 워크로드 신원 발행을 제한하여 공급망 공격의 범위를 줄일 수 있습니다.

자세한 내용은 Sigstore 워크로드 증명을 참조하세요.

Envoy SDS#

workload-identity-api 서비스 엔드포인트는 Envoy SDS API도 구현합니다. 이를 통해 Envoy 프록시의 인증서 및 인증 기관의 소스 역할을 할 수 있습니다.

포워드 프록시로서 Envoy는 SPIFFE를 지원하지 않는 워크로드의 아웃바운드 연결에 X.509 SVID를 첨부하는 데 사용될 수 있습니다.

리버스 프록시로서 Envoy는 SPIFFE 지원 클라이언트의 mTLS 연결을 종료하는 데 사용될 수 있습니다. Envoy는 클라이언트가 유효한 X.509 SVID를 제시했는지 검증하고 SVID에 포함된 SPIFFE ID를 기반으로 권한 부여 정책을 시행할 수 있습니다.

특정 프로토콜에 대한 리버스 프록시로 작동할 때, Envoy는 요청을 서비스로 전달하기 전에 클라이언트의 신원을 나타내는 헤더를 첨부하도록 구성할 수 있습니다. 그런 다음 서비스가 클라이언트의 신원을 기반으로 권한 부여 결정을 내리는 데 사용할 수 있습니다.

workload-identity-api 서비스에서 노출된 SDS API를 사용하도록 Envoy를 구성할 때, 구성을 돕기 위해 세 가지 특별한 이름을 사용할 수 있습니다:

• default: tbot이 워크로드의 기본 SVID를 반환합니다.
• ROOTCA: tbot이 워크로드가 속한 신뢰 도메인의 신뢰 번들을 반환합니다.
• ALL: tbot이 워크로드가 속한 신뢰 도메인의 신뢰 번들과 함께 신뢰 도메인이 페더레이션된 다른 신뢰 도메인의 신뢰 번들을 반환합니다.

다음은 unix:///opt/machine-id/workload.sock에서 수신 대기 중인 workload-identity-api 서비스에서 인증서와 신뢰 번들을 소싱하는 예시 Envoy 구성입니다. 연결 클라이언트가 유효한 SPIFFE SVID를 제시하도록 요구하고 이 정보를 x-forwarded-client-cert 헤더에 백엔드 서비스로 전달합니다.

node:
  id: "my-envoy-proxy"
  cluster: "my-cluster"
static_resources:
  listeners:
    - name: test_listener
      enable_reuse_port: false
      address:
        socket_address:
          address: 0.0.0.0
          port_value: 8080
      filter_chains:
        - filters:
            - name: envoy.filters.network.http_connection_manager
              typed_config:
                "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
                common_http_protocol_options:
                  idle_timeout: 1s
                forward_client_cert_details: sanitize_set
                set_current_client_cert_details:
                  uri: true
                stat_prefix: ingress_http
                route_config:
                  name: local_route
                  virtual_hosts:
                    - name: my_service
                      domains: ["*"]
                      routes:
                        - match:
                            prefix: "/"
                          route:
                            cluster: my_service
                http_filters:
                  - name: envoy.filters.http.router
                    typed_config:
                      "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
          transport_socket:
            name: envoy.transport_sockets.tls
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext
              common_tls_context:
                # configure the certificate that the reverse proxy should present.
                tls_certificate_sds_secret_configs:
                  # `name` can be replaced with the desired SPIFFE ID if  multiple
                  # SVIDs are available.
                  - name: "default"
                    sds_config:
                      resource_api_version: V3
                      api_config_source:
                        api_type: GRPC
                        transport_api_version: V3
                        grpc_services:
                          envoy_grpc:
                            cluster_name: tbot_agent
                # combined validation context "melds" two validation contexts
                # together. This is handy for extending the validation context
                # from the SDS source.
                combined_validation_context:
                  default_validation_context:
                    # You can use match_typed_subject_alt_names to configure
                    # rules that only allow connections from specific SPIFFE IDs.
                    match_typed_subject_alt_names: []
                  validation_context_sds_secret_config:
                    name: "ALL" # This can also be replaced with the trust domain name
                    sds_config:
                      resource_api_version: V3
                      api_config_source:
                        api_type: GRPC
                        transport_api_version: V3
                        grpc_services:
                          envoy_grpc:
                            cluster_name: tbot_agent
  clusters:
    # my_service is the example service that Envoy will forward traffic to.
    - name: my_service
      type: strict_dns
      load_assignment:
        cluster_name: my_service
        endpoints:
          - lb_endpoints:
              - endpoint:
                  address:
                    socket_address:
                      address: 127.0.0.1
                      port_value: 8090
    - name: tbot_agent
      http2_protocol_options: {}
      load_assignment:
        cluster_name: tbot_agent
        endpoints:
          - lb_endpoints:
              - endpoint:
                  address:
                    pipe:
                      # Configure the path to the socket that `tbot` is
                      # listening on.
                      path: /opt/machine-id/workload.sock