Add revocation details #15
Conversation
Signed-off-by: Monis Khan <[email protected]>
| since it can easily cache certificate revocation lists. | ||
|
|
||
| When the API server parses the bundles within `pemTrustAnchors`, it will extract | ||
| out all `CRLDistributionPoints` that have a `http://` scheme. These CRLs |
There was a problem hiding this comment.
Is there any plan to support a HTTPS scheme? While generally CRLs are distributed by http (and that's safe as they're independently signed, though still prone to replay attacks), I've been discouraging my clients from allowing any outbound HTTP Connections from their cluster as a matter of security (not shooting themselves in the foot, really). On the other hand, introducing the HTTPS Scheme creates a whole minor issue of which trust bundle to use for that connection; Either the pemTrustAnchors or the system CA store could be appropriate in different circumstances.
There was a problem hiding this comment.
We could support https but it does complicate the code for the reasons you mentioned. Technically we could just skip all TLS verification and rely on the same verification as we do for http. It would be equivalently secure.
There was a problem hiding this comment.
Intentionally setting insecureSkipVerify on CRL download clients is a good call ; want to add that to the spec?
There was a problem hiding this comment.
This was contentious so we have dropped the API server bits altogether for the 1.26 release.
ahmedtd
force-pushed
the
trust-anchor-sets
branch
from
434efb5 to
df35249
Compare
ahmedtd
force-pushed
the
trust-anchor-sets
branch
2 times, most recently
from
46cfe79 to
9b8216c
Compare
ahmedtd
force-pushed
the
trust-anchor-sets
branch
from
c66985d to
f2c6f88
Compare
No description provided.