Kubernetes Blog опубликовал техническое руководство о Pod Certificates и Cluster Trust Bundles в Kubernetes 1.37. Из него читатель узнает об архитектуре удостоверений для рабочих нагрузок, установке и использовании экспериментального контроллера подписи сертификатов.

Основы этой встроенной технологии производственной идентификации получили статус GA. Pod Certificates и Cluster Trust Bundles встраивают выпуск X.509-сертификатов для TLS и mTLS в ядро Kubernetes.

Kubelet генерирует приватный ключ и создаёт PodCertificateRequest для выбранного signer. Контроллер решает, выпускать ли сертификат, записывает цепочку и задаёт момент начала обновления.

Механизм автоматически ротирует сертификаты, но приложение должно обрабатывать изменения. Kubernetes пока не поставляет встроенных signer, а показанный в руководстве Tinycert не предназначен для production.

Проверка утверждений:

  • Kubernetes Blog опубликовал техническую статью-руководство о Pod Certificates и Cluster Trust Bundles в Kubernetes 1.37: автор разбирает архитектуру удостоверений для рабочих нагрузок и показывает установку и использование экспериментального контроллера подписи сертификатов. (подтверждено первоисточником: доказательство; «In the remainder of this article, I’ll take you through the overall architecture of a Kubernetes workload using Pod Certificates, as well as give you an example of installing and using a real (toy) Pod Certificates signer controller.»)
  • В Kubernetes 1.37 базовые механизмы новой встроенной технологии производственной идентификации получили статус GA, а Pod Certificates вместе с Cluster Trust Bundles встраивают выпуск X.509-сертификатов для TLS и mTLS непосредственно в ядро Kubernetes. (подтверждено первоисточником: доказательство; «In Kubernetes 1.37, the foundations of a new built-in production identity technology have gone GA. Pod Certificates (and the closely-associated Cluster Trust Bundles) build X.509 certificate issuance for TLS and mTLS directly into core Kubernetes.»)
  • Pod Certificates решают ключевое ограничение service account JWT: это bearer-токены, копия которых позволяет выдать себя за владельца, тогда как X.509 использует подтверждение владения и позволяет приватному ключу не покидать рабочую нагрузку. (подтверждено первоисточником: доказательство; «A solution to this problem lies in proof-of-possession credentials, where you don’t send your entire credential to your peer, but only a proof that you possess the credential. In practice, these schemes are always built on asymmetric cryptographic signatures (RSA, ECDSA, and friends). There are few different standard approaches, such as request signing (AWS SigV4, JWT DPoP, RFC 9421), but the most widely-deployed and understood solution is X.509 certificates, as used in TLS. In TLS, your credential is split into two pieces A private key, which for maximum security should be generated within your workload (or within a hardware security module), and never leave.»)
  • Механизм Pod Certificates оставляет общую логику в Kubelet, но предоставляет подключаемый интерфейс, поэтому один кластер может одновременно выпускать сертификаты разных типов. (подтверждено первоисточником: доказательство; «For this reason, Pod Certificates has common machinery built into Kubelet, but offers a pluggable interface so that many different types of certificates can be issued within a single cluster, at the same time.»)
  • Архитектура включает приложение, которое запрашивает сертификаты и читает ключи, сертификаты и наборы доверия из файловой системы; Kubelet, создающий PodCertificateRequest и читающий ClusterTrustBundle; и signer controller, отвечающий на запросы и публикующий наборы доверия. (подтверждено первоисточником: доказательство; «Your application, which requests certificates in its pod spec, and reads the keys, certificates and trust bundles from the container filesystem to use for (m)TLS. Kubelet, which issues PodCertificateRequest objects and reads ClusterTrustBundle objects on behalf of your workload. The signer controller, which answers PodCertificateRequests and publishes ClusterTrustBundles.»)
  • Kubelet генерирует приватный ключ, создаёт адресованный выбранному signer объект PodCertificateRequest, а контроллер решает, выпускать ли сертификат, записывает цепочку сертификатов и задаёт момент начала обновления. (подтверждено первоисточником: доказательство; «For each podCertificate source: Kubelet generates a new private key according to the keyType field. Kubelet creates a PodCertificateRequest addressed to the signer named in the source. The signer controller sees the PodCertificateRequest and decides whether or not to issue the certificate. The signer controller issues the certificate by filling out the status.certificateChain field. The signer controller also fills out the status.beginRefreshAt field to instruct Kubelet when it should begin trying to refresh the certificate.»)
  • Автоматическая ротация сертификатов встроена в механизм, но приложение должно обрабатывать изменения; для будущих встроенных signer максимальный срок сертификата составит 24 часа, для сторонних — 91 день. (подтверждено первоисточником: доказательство; «Automatic rotation is built in. Applications must properly handle it. Any signers eventually shipped in core Kubernetes will issue certificates with a max lifetime of 24 hours. The maximum lifetime allowed for other signers is 91 days.»)
  • Kubelet умеет записывать приватный ключ и цепочку сертификатов в один credential bundle, упрощая отслеживание ротации через inotify или polling; при раздельных файлах приложение должно учитывать гонки чтения во время обновления. (подтверждено первоисточником: доказательство; «To make automatic rotation support as simple as possible, Kubelet supports writing the private key and certificate chain to a single file (a credential bundle ) This allows the application to simply subscribe to inotify events for (or poll) the single file, read the contents, and use them. Kubelet does support writing the private key and certificate chain to separate files, but then the application needs to carefully manage the potential race conditions of reading the files mid-rotation.»)
  • Проверки безопасности по возможности выполняются в kube-apiserver: встроенный admission-плагин node restriction изолирует узлы и не позволяет скомпрометированному узлу запрашивать сертификаты для чужих pod. (подтверждено первоисточником: доказательство; «Wherever possible, security checks are built into kube-apiserver, rather than burdening signer or application developers. As an example, the built-in node restriction admission plugin enforces node isolation, ensuring that one compromised node cannot spread access by requesting certificates for pods that aren’t scheduled to it.»)
  • Kubernetes пока не поставляет встроенных signer для Pod Certificates, поэтому для испытаний нужен сторонний signer; приведённый в статье Tinycert не предназначен для production, но служит отправной точкой для экспериментов и создания собственных signer. (подтверждено первоисточником: доказательство; «Because the Kubernetes project does not yet ship any Pod Certificate signers in core, in order to try these features out, you will need to install a third-party signer into your cluster. To make this easier, I have written Tinycert , which you can install into your cluster (or a Kind cluster). Tinycert is not a full production solution, but it’s a good starting point for experimenting with Pod Certificates, as well as a base for creating your own signers.»)
  • Tinycert включает signer, выпускающий сертификаты с DNS SAN для сервисов Kubernetes, в которые входит pod; SPIFFE-совместимый signer, идентифицирующий namespace и service account; а также Go-библиотеку для загрузки SPIFFE-сертификатов и наборов доверия и настройки взаимной TLS-аутентификации. (подтверждено первоисточником: доказательство; «Tinycert provides: The ahmedtd.github.io/tinycert-service signer, which issues certificates with DNS SANs for all of the Kubernetes Services your Pod is part of. The ahmedtd.github.io/tinycert-spiffe signer, which issues SPIFFE-compatible certificates that identify the namespace and service account of your Pod. These can be used as both client and (with effort) server certificates. A Go library, github.com/ahmedtd/tinycert/lib/spiffefsd to help your applications load SPIFFE certificates and trust bundles from a SPIFFE Filesystem Delivery (Draft Standard) folder, as well as configure the Go TLS library for proper client and server authentication.»)

Первоисточники:

оценка 87.5 · тип release · ревизия 1 · истории st-4u87mr