[RFC-XXXX] Vendor-Agnostic Short-Lived Credentials#5702
[RFC-XXXX] Vendor-Agnostic Short-Lived Credentials#5702matheuscscp wants to merge 2 commits intomainfrom
Conversation
matheuscscp
added
enhancement
matheuscscp
force-pushed
the
rfc-creds
branch
4 times, most recently
from
87c0172 to
e2a8a56
Compare
matheuscscp
force-pushed
the
rfc-creds
branch
2 times, most recently
from
4adaa54 to
635872b
Compare
| short-lived credential to use for authentication. The field is mutually exclusive | ||
| with `.spec.provider` (when set to a cloud provider) because "provider" conveys |
There was a problem hiding this comment.
Should we provide another CEL rule example for this? Given "mutual exclusivity".
There was a problem hiding this comment.
Not sure I follow the suggestion 🤔
There was a problem hiding this comment.
I think the current CEL expression already covers the entire mutual exclusivity, no? 🤔
matheuscscp
force-pushed
the
rfc-creds
branch
2 times, most recently
from
f9632fd to
792631f
Compare
|
@hiddeco I fixed the inconsistencies you found around the SPIFFE flags in this diff: https://github.com/fluxcd/flux2/compare/f9632fd9d7c118763ba7bfbd2e88cbe8a9dbf8e3..792631f49699aa8813cc24f2875f3a75fe1a826c They were an artifact of my late decision to introduce a separate flag for the trust domain. |
Signed-off-by: Matheus Pimenta <matheuscscp@gmail.com>
matheuscscp
force-pushed
the
rfc-creds
branch
from
792631f to
6fcba05
Compare
Signed-off-by: Matheus Pimenta <matheuscscp@gmail.com>
| The trust domain for the SPIFFE ID is configured via the controller flag | ||
| `--spiffe-trust-domain`. The `iss` claim is set to the controller flag | ||
| `--spiffe-issuer`, which third-party services use for OIDC discovery. The | ||
| JWT is signed using a private key provided via `--spiffe-secret-name`. Unlike |
There was a problem hiding this comment.
do we just read this secret every time and let the client decide how long to cache it?
There was a problem hiding this comment.
We don't cache secrets in Flux, it's always a live lookup
|
@stefanprodan @hiddeco @stealthybox The last week to work on |
| - **`SpiffeCertificate`**: The controller issues a short-lived SPIFFE SVID | ||
| x509 certificate for client authentication via mTLS. The certificate encodes | ||
| the same SPIFFE ID as `SpiffeJWT` in the SAN URI field. The certificate is | ||
| signed using a CA private key and certificate provided via the controller |
There was a problem hiding this comment.
I don't think having to supply CA key as secret will be acceptable to many security teams to be honest..
There was a problem hiding this comment.
All Flux APIs require the CA be specified in a secret.
There was a problem hiding this comment.
To be clear, I mean the private key of the CA which as I understand is required for issuance for this proposal to work, not the CA (public) certificate (aka root of trust).
There was a problem hiding this comment.
@SpectralHiss As we discussed in our call today, this proposal indeed needs to be clearer and to better frame why we are proposing to provide a CA key to Flux: The idea is replacing the PKI from the Kubernetes ServiceAccount token issuer with one dedicated for Flux. There are two major advantages:
- This CA would be dedicated for Flux. Only Flux can/should issue short-lived creds with it. This is better than Kube's SA token issuer because there are much less components issuing creds with it: it's just Flux, and not Kube itself (for its own built-in purposes) plus anything else that has the
createRBAC verb for theserviceaccounts/tokenresource in the cluster. - Flux can issue identities mapping 1:1 with objects, the identity is the object itself. With Kube SA token issuer we're limited to SAs, which can be reused by different objects.
The justification for this is that Flux is normally the most trusted component in the cluster, deploying absolutely everything inside it, including CNI (e.g. https://timoni.sh/flux-aio/).
5 participants
Part of: #5681
Preview: https://github.com/fluxcd/flux2/blob/rfc-creds/rfcs/xxxx-vendor-agnostic-short-lived-credentials/README.md
@SpectralHiss Please review 🙏