KEP-4317: Pod Certificates #4318

ahmedtd · 2023-10-30T03:26:28Z

This PR adds the initial content for KEP-4317, which outlines machinery for:

Representing pod identities in X.509 certificates and certificate requests,
Generically provisioning certificates to pods,
Specifically provisioning kube-apiserver client certificates to pods, and
Using pod identity certificates to authenticate to kube-apiserver,.

This KEP is still in the draft/discussion phase. Significant changes are anticipated based on review and discussion in SIG Auth.

Issue link: Pod Certificates #4317
Draft implementation: [WIP] Pod Certificates kubernetes#121596

keps/sig-auth/4317-pod-certificates/README.md

mtaufen · 2023-11-03T22:15:39Z

keps/sig-auth/4317-pod-certificates/README.md

+actually been scheduled onto that node.
+
+<<[UNRESOLVED]>>
+Is it necessary or desirable to forbid non-Kubelet identities from creating CertificateSigningRequest objects that embed a PodIdentity extension?


Does anything prevent non-Kubelets from adding a Pod binding in TokenRequest, today? noderestriction doesn't appear to limit it, at least.

I believe it is forbidden at some level. But I guess we should just try it out.

mtaufen · 2023-11-03T22:37:53Z

keps/sig-auth/4317-pod-certificates/README.md

+	ServiceAccountName string `asn1:"utf8"`
+	PodName            string `asn1:"utf8"`
+	PodUID             string `asn1:"utf8"`
+	NodeName           string `asn1:"utf8"`


We included Node UID in https://github.com/kubernetes/kubernetes/pull/120780/files#diff-0c530c4dd8479db341cd002079be7ab62e34d49b42540785df9ad17431c8f108R243 and should probably do the same here.

Are all these fields required? If they are, I think we might one day regret not making the node name / uid optional.

In the extension data itself, all fields are optional, in that you can always leave them as the empty string. (I don't think the ASN.1 parser in Go tries to handle field presence or absence).

If the extension appears in a CertificateSigningRequest from a kubelet, the node restriction plugin will enforce that all the fields are populated, and consistent with reality.

If the extension appears in an issued certificate, I think it's up to the component that's validating the certificate to decide which fields it cares about. For the specific example of certificates issued by the kubernetes.io/kube-apiserver-client-pod signer/approver, we probably want kube-apiserver to check all of the fields before letting the request past the authentication stage.

I think clearly documenting a minimum, non-negotiable subset of required fields that are provably sufficient to guarantee unambiguous pod<->cert binding in Kubernetes is required, or including this ASN.1 OID field as an overall KEP requirement isn't much use.

Otherwise they can be left all empty, enforcement is implementation-dependent, and I can be fully compliant with this KEP and use a single cert for every pod in the cluster depending on whatever internal attestation logic the CSR admission controller I'm using happens to employ.

Sure, I can add a detailed proposal for exactly which fields need to be set in order for kube-apiserver to allow authentication via a certificate containing a PodIdentity extension.

Based on discussion in API review, we are going to go with a dedicated PodCertificateRequest type, rather than encoding these details in the existing CertificateSigningRequest spec.request field. This drastically lowers the importance of the PodIdentity extension, since it will only be used by the kube-apiserver-client-pod signer, not every third-party signer that wants to integrate with pod certificates.

mtaufen · 2023-11-03T22:38:05Z

keps/sig-auth/4317-pod-certificates/README.md

+following DER-encoded structure:
+
+```go
+type podIdentityASN1 struct {


Somewhat off-topic, but... What would it take to network bind these certificates? E.g. assuming we can trust the underlying network to prevent IP spoofing, could we include a node or pod source IP here as well?

That's basically it --- we need to write the IP here, have kube-apiserver cross-check it during admission, and then ensure it ends up in the PodIdentity extension for the final cert. Then kube-apiserver can check it during TLS termination.

Doesn't even have to be kube-apiserver that validates during admission, IIUC?

E.g. you could use SPIRE's attesting agent to validate the admission request for the cert and reject if out-of-band validations fail, or any other thing.

keps/sig-auth/4317-pod-certificates/README.md

sftim · 2023-11-04T15:53:55Z

Is this related to ClusterTrustBundles?

sftim

Thanks. Here's a bunch of feedback - a mix of style nits and opinions.

keps/sig-auth/4317-pod-certificates/README.md

keps/sig-auth/4317-pod-certificates/kep.yaml

keps/sig-auth/4317-pod-certificates/README.md

aojea · 2023-11-06T23:46:42Z

/cc @aojea

ahmedtd · 2023-11-17T21:00:14Z

Is this related to ClusterTrustBundles?

They're intended to work together. It's not needed for the kube-apiserver client certificate use case, but if someone were to build a pod-to-pod mTLS solution on top of this, they would need to use both ClusterTrustBundle and PodCertificate projected volumes.

keps/sig-auth/4317-pod-certificates/README.md

aramase · 2024-01-19T16:15:21Z

/cc

bleggett · 2024-02-14T05:28:21Z

keps/sig-auth/4317-pod-certificates/README.md

+
+### PodIdentity Extension Node Restriction
+
+The noderestriction admission plugin will check the consistency of PodIdentity extensions in CertificateSigningRequest objects created by `system:node:` identities.  The creation request will only be admitted if the PodIdentity extension refers to a pod that is currently running on the node that requested the certificate.


I'm assuming that this admission plugin is purely a reference impl, and people are free to write their own admission plugins which do more (or less).

...which also means the admission criteria is entirely implementation-dependent?

The node restriction plugin is built in to kube-apiserver. It can probably be disabled, but I don't think it is on most distributions?

Okay, so the noderestriction admission plugin is the default "floor" and people can always add more strict/granular admission plugins on top. IIUC, that makes sense.

bleggett · 2024-02-14T05:33:18Z

keps/sig-auth/4317-pod-certificates/README.md

+actually been scheduled onto that node.
+
+<<[UNRESOLVED]>>
+Is it necessary or desirable to forbid non-kubelet identities from creating CertificateSigningRequest objects that embed a PodIdentity extension?


If I can write my own admission plugin and use that instead of the reference impl, I can implement whatever restrictions I like here, which makes it less important how strict or not the reference impl is.

My $0.02 is that the reference impl should restrict to the kubelet identity, at least initially.

bleggett · 2024-02-14T05:45:51Z

keps/sig-auth/4317-pod-certificates/README.md

+The kubelet supports only a few key generation strategies, each named by a string
+that encapsulates both the key type and any parameters necessary (for example,
+RSA modulus size).  The intention is to offer a a tasting menu of reasonable key
+choices, rather than offering a flexibility to a wide variety of parameters.
+Key types supported by kubelet are "RSA2048", "RSA3072", "RSA4096", "ECDSAP256",
+and "ECDSAP384".  If no key type is specified, kubelet defaults to "ECDSAP256".
+


I can tell you from experience that no matter what algos and param defaults you pick, people are going to want to customize beyond those defaults pretty quickly for various compliance and internal reasons, and "shipping your own custom kubelet" is a bit of a lift to allow that.

In general I think it would be best to minimize the kubelet opinions and lack of flexibility around PKI algos and params.

The problem here is that Kubelet has to generate the key, so fundamentally if we want to allow the user to exercise option X, then Kubelet needs to implement option X.

However, I'm not sure there really are any other choices to make for private keys. RSA lets you pick the modulus, which is specified here, and ECDSA lets you pick a curve, which is specified here.

The problem here is that Kubelet has to generate the key, so fundamentally if we want to allow the user to exercise option X, then Kubelet needs to implement option X.

Yes, that's a bit unfortunate. I do understand it's an unavoidable limitation of the goals/non-goals here tho.

keps/sig-auth/4317-pod-certificates/README.md

bleggett · 2024-02-14T06:04:33Z

keps/sig-auth/4317-pod-certificates/README.md

+following DER-encoded structure:
+
+```go
+type podIdentityASN1 struct {


Doesn't even have to be kube-apiserver that validates during admission, IIUC?

E.g. you could use SPIRE's attesting agent to validate the admission request for the cert and reject if out-of-band validations fail, or any other thing.

keps/sig-auth/4317-pod-certificates/README.md

k8s-triage-robot · 2024-05-14T06:48:33Z

The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

After 90d of inactivity, lifecycle/stale is applied
After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

Mark this PR as fresh with /remove-lifecycle stale
Close this PR with /close
Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

k8s-triage-robot · 2024-06-13T07:15:51Z

The Kubernetes project currently lacks enough active contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

After 90d of inactivity, lifecycle/stale is applied
After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

Mark this PR as fresh with /remove-lifecycle rotten
Close this PR with /close
Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

soltysh · 2024-10-01T11:31:35Z

@ahmedtd please don't forget to creating a PRR file (see template in https://github.com/kubernetes/enhancements/blob/master/keps/prod-readiness/template/nnnn.yaml) and answering the questions, feel free to assign me for the PRR approval.

ahmedtd · 2024-10-02T02:05:58Z

@ahmedtd please don't forget to creating a PRR file (see template in https://github.com/kubernetes/enhancements/blob/master/keps/prod-readiness/template/nnnn.yaml) and answering the questions, feel free to assign me for the PRR approval.

I added the yaml file to the PR. However, I don't see any questions in it. Are you referring to the PRR questions in the main KEP body?

ahmedtd · 2024-10-02T03:52:55Z

Capturing some notes from discussion with Jordan:

For Alpha, we are unsure about how much we want existing things that understand client certs to understand these new certs. To keep our options open, we will put a random UID as the CN, and not encode groups. In the future, we might decide to encode a meaningful CN and groups.

New flag for pod client certificate CA, no sort of fallback logic.

On kube-apiserver, continue to use one flag for all client certificate CAs.

Use PEM in the PCR.

All of these points are now reflected in the text.

soltysh

a few comments from PRR review

keps/sig-auth/4317-pod-certificates/README.md

soltysh · 2024-10-02T11:14:59Z

keps/sig-auth/4317-pod-certificates/README.md

+* Indicate failure in issuing the certificate by updating the status subresource
+  of the PodCertificateRequest, adding a "Failed" condition.
+
+PodCertificateRequest validation logic will:


I believe the validation described here is strictly about the apiserver-side validation, not the kubelet. The important distinction is that this kind of validation will happen only during create/update actions.
Below, there's a description of noderestriction admission plugin, which does a consistency check combining the PCR with an actual pod.

soltysh · 2024-10-02T11:15:39Z

keps/sig-auth/4317-pod-certificates/README.md

+compromising a single node only results in compromises of workloads that have
+actually been scheduled onto that node.
+
+During alpha, the ability to store PodCertificate objects (and the node


An important note: feature gates are only for the development phase, once this feature reaches GA they will be removed.

keps/sig-auth/4317-pod-certificates/README.md

soltysh · 2024-10-02T11:46:37Z

keps/sig-auth/4317-pod-certificates/README.md

+### Rollout, Upgrade and Rollback Planning
+
+<!--
+This section must be completed when targeting beta to a release.


Below sections although not required and won't block alpha are worthy of your time to try to tackle some of the answers. I believe you've already pointed out some issues with scalability after node restart.

This holds, especially the rollout when you have api enablement + 3 various feature gates. Although I believe the overall recommendation will be to turn all at once.

stlaz · 2024-10-03T11:34:20Z

keps/sig-auth/4317-pod-certificates/README.md

+    projected:
+      sources:
+      - podCertificate:
+          signerName: "kubernetes.io/kube-apiserver-client-pod"


It's less about the usability, more about the maintenance.

You have to register multiple attributes for the RDNs to start with but:

You don't have to write your own ASN.1 parser because this is just DN parsing.

You don't have to port your parser into multiple languages

You can reuse the RDNs for other purposes and you can combine them at will

I think this might be worth mentioning in alternatives at least.

keps/sig-auth/4317-pod-certificates/README.md

stlaz · 2024-10-03T12:53:36Z

keps/sig-auth/4317-pod-certificates/README.md

+
+This extension, and the utility functions for manipulating it, are developed for
+use by core Kubernetes components, although third parties could make use of
+them.  The extension should only be changed in backwards-compatible ways.


What would a backward-compatible change look like in this case? As per RFC5280 - Section 4.2:

A certificate-using system MUST reject the certificate if it encounters a critical extension it does not recognize or a critical extension that contains information that it cannot process.

From Kubernetes perspective, adding an optional field would be considered a backward-compatible change, but the way I understand the above definition blocks this change as that would add information that the older versions of the parsers cannot process.

It's very much possible my interpretation of the RFC is too pedantic. I wonder if there's anyone in the community that would be able to confirm/deny.

Strictly speaking, we don't need to mark the extension as critical. The only other content of the certificate will be some random bytes in the Subject.Name field, so it is unlikely that anything bad can happen if you present the cert to an application that doesn't understand the extension (or our custom RDNs, if we go that route).

To close on this, I think we will mark the extension as critical. If we need to evolve the contents of the extension in the future, we will need to do so taking into consideration the behavior of TLS libraries when parsing the extension.

neolit123 · 2024-10-04T11:20:26Z

keps/sig-auth/4317-pod-certificates/README.md

+responsibility for enforcing node restriction on PodCertificateRequests into
+kube-apiserver, so that signer implementations do not need to consider it.
+
+### Non-Goals


i think it's worth mentioning explicitly as a non-goal that this proposal does not cover signing serving certificates for pods. that seems obvious and covered in the pod-to-pod mTLS point, but implicitly.

It's a non-goal for the built-in signer to issue serving certs (although we will probably mark the certs to allow server cert usage; it doesn't hurt anything).

However, it's an explicit goal for third-party signers to be able to use the PodCertificate projected volume machinery to be able to issue serving certificates to pods.

It's a non-goal for the built-in signer to issue serving certs (although we will probably mark the certs to allow server cert usage; it doesn't hurt anything).

I would not expect us to mark these certs as anything but client certs.

Clarified in the text.

I would not expect us to mark these certs as anything but client certs.

Agreed. As discussed on slack, we will only set the client cert usages. This doesn't preclude users from using them as server certs; since they will need to write custom TLS validation code, they can just ignore the lack of the "server" usage bits.

soltysh

the PRR for alpha is ok, although I'd still encourage filling in the metrics and the scalability secions

/approve

soltysh · 2024-10-08T11:17:57Z

keps/sig-auth/4317-pod-certificates/README.md

+For Alpha:
+* The feature will be gated behind feature flags and alpha API
+enablement.
+* An e2e test will exercise the feature in order to prevent


We don't enable alpha feature gates in our regular e2es, so make sure to add them to appropriate test suite which does it.

Will do. We had to do the same thing for ClusterTrustBundles.

soltysh · 2024-10-08T11:18:40Z

keps/sig-auth/4317-pod-certificates/README.md

+<!--
+Additionally, for Alpha try to enumerate the core package you will be touching
+to implement this enhancement and provide the current unit coverage for those
+in the form of:


Nit: but the above comment explicitly requires both the directory and coverage 😅

The coverage tab crashes in Chrome :/ I need to dig up a Firefox install

You can always just run go test -race -cover <package> 😉

soltysh · 2024-10-08T11:23:34Z

keps/sig-auth/4317-pod-certificates/README.md

+Based on the above analysis, we may want to consider making kube-scheduler aware
+of which kubelet versions support PodCertificate projected volumes (and which
+key types are supported by version), and try to steer pods towards nodes that
+can successfully mount them.


We don't do that kind of checks anywhere I'm aware of, so I'd advise against it.

Rather make sure to provide sufficient information in the logs or through events which would allow a user to identify such a situation.

Removed that paragraph.

soltysh · 2024-10-08T11:26:12Z

keps/sig-auth/4317-pod-certificates/README.md

+### Rollout, Upgrade and Rollback Planning
+
+<!--
+This section must be completed when targeting beta to a release.


This holds, especially the rollout when you have api enablement + 3 various feature gates. Although I believe the overall recommendation will be to turn all at once.

ahmedtd · 2024-10-08T21:08:56Z

@soltysh

This holds, especially the rollout when you have api enablement + 3 various feature gates. Although I believe the overall recommendation will be to turn all at once.

I'm sorry, can you elaborate? Are you saying that I should go ahead and fill this section out?

enj

First pass.

enj · 2024-10-07T22:44:59Z

keps/sig-auth/4317-pod-certificates/README.md

+responsibility for enforcing node restriction on PodCertificateRequests into
+kube-apiserver, so that signer implementations do not need to consider it.
+
+### Non-Goals


It's a non-goal for the built-in signer to issue serving certs (although we will probably mark the certs to allow server cert usage; it doesn't hurt anything).

I would not expect us to mark these certs as anything but client certs.

enj · 2024-10-07T22:46:33Z

keps/sig-auth/4317-pod-certificates/README.md

+* A new TLS user-mapping capability in kube-apiserver to understand client
+  certificates that embed PodIdentity extensions.
+* A new PodCertificateRequest signer
+  (`kubernetes.io/kube-apiserver-client-pod`), shipped in


Need full docs for this signer like https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers

Sure, but I don't think "we will adequately document the feature" is something we need to state in the KEP.

No I mean, actually document the signer here, in the KEP itself.

It is? In the section "API Server Pod Client Certificate Approver / Signer".

enj · 2024-10-07T22:51:32Z

keps/sig-auth/4317-pod-certificates/README.md

+    [ED25519 Specification](https://ed25519.cr.yp.to/) (as implemented by
+    the golang library crypto/ed25519.Sign).
+* Details of the requesting Pod's identity:
+  * Namespace (indicated by the namespace the PodCertificateRequest is created in).


Namespace UID?

Sure, added.

Hmmm, actually, I'm not quite sure here. The namespace is indicated by which namespace the PodCertificateRequest (and pod, and service account) are actually in

I'm not sure it makes sense to embed the UID of the namespace in the PodCertificateRequest, although we could have kubernetes.io/kube-apiserver-client-pod embed the UID in the issued certificate.

enj · 2024-10-07T22:52:22Z

keps/sig-auth/4317-pod-certificates/README.md

+  * If the key is an RSA key, then the signature is over the ASCII bytes of the
+	  pod UID, using RSASSA-PKCS1-V1_5-SIGN from RSA PKCS #1 v1.5 (as implemented


Don't we need a timestamp or similar to prevent replay?

I don't know how important this is --- the primary security guarantees here come from ensuring that only the correct kubelet can request a certificate for a given pod. The proof of possession is just to prevent (implausible) accidents, as far as I can tell from https://www.rfc-editor.org/rfc/rfc4211#appendix-C

And https://www.rfc-editor.org/rfc/rfc4211#section-4 only says that the proof of possession should sign over some representation of the identity being requested. It doesn't include a timestamp.

Okay per my reading of that RFC, I think the pod UID is sufficient when combined with all the other node admission checks (i.e. we know that this exact pod is scheduled on this exact node with this exact SA in the same namespace).

If a different node tried to replay the PoP, it would fail because that pod isn't scheduled to it.

keps/sig-auth/4317-pod-certificates/README.md

enj · 2024-10-09T02:00:27Z

keps/sig-auth/4317-pod-certificates/README.md

+authenticates to kube-apiserver using mTLS.
+
+I add a new projected volume to my pod, containing the information that
+client-go expects at a well-known path.  I set


It seems really awkward to require this very manual process, especially with magic well known paths on disk in play.

In the future, we can think about automatically injecting these as a replacement for the existing kube-apiserver-access volumes. I didn't want to cover that in Alpha because there's already enough work just landing the machinery without thinking about driving adoption.

However, I think there's a larger conversation to be had on this topic in SIG Auth. My personal thoughts are:

Automatically granting API access credentials by default is probably a mistake. Most workloads in a Kubernetes cluster do not actually need to talk to the Kubernetes API.

Mutating admission controllers (especially webhooks) cause a lot of problems. In general, workload authors expect the spec they write to be the spec that gets loaded into the cluster.

In a perfect world, I would make workload authors who want Kubernetes API access opt in by inserting a token (or pod certificate volume).

Yeah I am fine with this as-is, but lets discuss further in a future meeting.

enj · 2024-10-09T02:02:48Z

keps/sig-auth/4317-pod-certificates/README.md

+
+- `<package>`: `<date>` - `<test coverage>`
+
+##### Integration tests


I suspect we could manually run enough of the kcm/kubelet pieces during integration tests to exercise the various node restriction and new signer bits.

keps/sig-auth/4317-pod-certificates/README.md

soltysh · 2024-10-09T13:58:22Z

@soltysh

This holds, especially the rollout when you have api enablement + 3 various feature gates. Although I believe the overall recommendation will be to turn all at once.

I'm sorry, can you elaborate? Are you saying that I should go ahead and fill this section out?

I mean that it would be nice to see this section filled in, but it's not a hard requirement for alpha. Although usually going through that kind of exercise allows unlocking potential problems, which then leads to better designs of the feature.

enj

Minor stuff, lgtm.

enj · 2024-10-09T23:40:04Z

keps/sig-auth/4317-pod-certificates/README.md

+* It uses a CA specified by a new pair of private key / root certificate flags
+  (although implementations are free to set this flag to point at the CA as
+  another signer).
+* It issues certificates that are valid for 24 hours, and tells Kubelet to begin


What if a client asks for a shorter TTL? What is the min TTL this signer supports?

Good point. I will update so that it issues certs for min(maxExpirationSeconds, 24hours).

Edit: And we can rely on the new 1 hour minimum for maxExpirationSeconds.

enj · 2024-10-09T23:45:10Z

keps/sig-auth/4317-pod-certificates/README.md

+* If the creator of the PodCertificateRequest left `maxExpirationSeconds` at 0,
+  then kube-apiserver will default it to 24 hours.


follow-up -> decide if we need to support both a max exp seconds per signer and a default per signer.

enj · 2024-10-09T23:46:04Z

keps/sig-auth/4317-pod-certificates/README.md

+* Ensure that all fields in PodCertificateRequest.Status are immutable once the
+  request has been issued, denied, or failed.
+
+The `maxExpirationSeconds` field will have the following logic:


Probably need a min for this field -> does not make sense to let clients ask for 1 second certs.

Good point. Updated with a min of 1 hour. It should be safe to drop that down in the future.

enj · 2024-10-09T23:55:21Z

/lgtm
/approve

enj · 2024-10-09T23:56:33Z

@soltysh approved PRR here #4318 (review) but looks like the bot must have missed the GH event, tagging it manually.

k8s-ci-robot · 2024-10-09T23:56:58Z

[APPROVALNOTIFIER] This PR is APPROVED

Approval requirements bypassed by manually added approval.

This pull-request has been approved by: ahmedtd, enj

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

keps/prod-readiness/OWNERS
~~keps/sig-auth/OWNERS~~ [enj]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. labels Oct 30, 2023

k8s-ci-robot requested review from enj and ritazh October 30, 2023 03:26

k8s-ci-robot added kind/kep Categorizes KEP tracking issues and PRs modifying the KEP directory sig/auth Categorizes an issue or PR as relevant to SIG Auth. labels Oct 30, 2023

ahmedtd force-pushed the pod-certificates branch 2 times, most recently from 9c8542f to e1fc884 Compare October 30, 2023 04:04

ahmedtd mentioned this pull request Nov 1, 2023

Pod Certificates #4317

Open

5 tasks

mtaufen reviewed Nov 3, 2023

View reviewed changes

sftim reviewed Nov 4, 2023

View reviewed changes

k8s-ci-robot requested a review from aojea November 6, 2023 23:46

ahmedtd force-pushed the pod-certificates branch from e1fc884 to 890db17 Compare November 17, 2023 07:28

ahmedtd commented Dec 12, 2023

View reviewed changes

keps/sig-auth/4317-pod-certificates/README.md Outdated Show resolved Hide resolved

ahmedtd commented Dec 13, 2023

View reviewed changes

keps/sig-auth/4317-pod-certificates/README.md Show resolved Hide resolved

k8s-ci-robot requested a review from aramase January 19, 2024 16:15

bleggett reviewed Feb 14, 2024

View reviewed changes

keps/sig-auth/4317-pod-certificates/README.md Outdated Show resolved Hide resolved

bleggett reviewed Feb 14, 2024

View reviewed changes

keps/sig-auth/4317-pod-certificates/README.md Show resolved Hide resolved

This was referenced Apr 2, 2024

proxy: switch to Delta SDS istio/istio#50153

Closed

proxy: slim Istio agent dependencies istio/istio#50212

Merged

k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label May 14, 2024

k8s-ci-robot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Jun 13, 2024

ahmedtd force-pushed the pod-certificates branch from 3f64bdb to a78d7b3 Compare October 2, 2024 02:05

ahmedtd force-pushed the pod-certificates branch from a78d7b3 to 61ae32c Compare October 2, 2024 03:52

soltysh reviewed Oct 2, 2024

View reviewed changes

stlaz reviewed Oct 3, 2024

View reviewed changes

ahmedtd force-pushed the pod-certificates branch 2 times, most recently from a07b445 to ab42b03 Compare October 3, 2024 22:22

ahmedtd changed the title ~~KEP-4317: PodIdentity certificates, PodCertificate volumes, and in-cluster kube-apiserver client certificates~~ KEP-4317: Pod Certificates Oct 3, 2024

ahmedtd force-pushed the pod-certificates branch from ab42b03 to 42a8731 Compare October 3, 2024 23:43

neolit123 reviewed Oct 4, 2024

View reviewed changes

soltysh approved these changes Oct 8, 2024

View reviewed changes

ahmedtd force-pushed the pod-certificates branch 2 times, most recently from 0d9057d to 4a5849c Compare October 8, 2024 22:12

enj requested changes Oct 9, 2024

View reviewed changes

enj reviewed Oct 9, 2024

View reviewed changes

keps/sig-auth/4317-pod-certificates/README.md Outdated Show resolved Hide resolved

ahmedtd force-pushed the pod-certificates branch from 4a5849c to 2aa4332 Compare October 9, 2024 22:27

enj requested changes Oct 9, 2024

View reviewed changes

KEP-4317: Pod Certificates

9604bb2

ahmedtd force-pushed the pod-certificates branch from 2aa4332 to 9604bb2 Compare October 9, 2024 23:54

k8s-ci-robot assigned enj Oct 9, 2024

k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Oct 9, 2024

enj added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Oct 9, 2024

k8s-ci-robot merged commit 448d36a into kubernetes:master Oct 10, 2024
4 checks passed


		### PodIdentity Extension Node Restriction

		The noderestriction admission plugin will check the consistency of PodIdentity extensions in CertificateSigningRequest objects created by `system:node:` identities. The creation request will only be admitted if the PodIdentity extension refers to a pod that is currently running on the node that requested the certificate.

		* If the key is an RSA key, then the signature is over the ASCII bytes of the
		pod UID, using RSASSA-PKCS1-V1_5-SIGN from RSA PKCS #1 v1.5 (as implemented


		- `<package>`: `<date>` - `<test coverage>`

		##### Integration tests

		* If the creator of the PodCertificateRequest left `maxExpirationSeconds` at 0,
		then kube-apiserver will default it to 24 hours.

KEP-4317: Pod Certificates #4318

KEP-4317: Pod Certificates #4318

Conversation

ahmedtd commented Oct 30, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bleggett Feb 14, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sftim commented Nov 4, 2023

sftim left a comment

Choose a reason for hiding this comment

aojea commented Nov 6, 2023

ahmedtd commented Nov 17, 2023

aramase commented Jan 19, 2024

bleggett Feb 14, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bleggett Feb 14, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

k8s-triage-robot commented May 14, 2024

k8s-triage-robot commented Jun 13, 2024

soltysh commented Oct 1, 2024

ahmedtd commented Oct 2, 2024

ahmedtd commented Oct 2, 2024

soltysh left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stlaz Oct 3, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ahmedtd Oct 4, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

soltysh left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ahmedtd commented Oct 8, 2024

enj left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ahmedtd commented Oct 30, 2023 •

edited

Loading

bleggett Feb 14, 2024 •

edited

Loading

bleggett Feb 14, 2024 •

edited

Loading

bleggett Feb 14, 2024 •

edited

Loading

stlaz Oct 3, 2024 •

edited

Loading

ahmedtd Oct 4, 2024 •

edited

Loading

ahmedtd Oct 9, 2024 •

edited

Loading