The parent comment is wondering about the structure of the signature and if different curve parameters can be specified for it. How can explicit curve parameters be specified in an ECDSA signature? ecdsaWithSHA256, at least, is simply two bigints. There's no spot for specifying explicit parameters.
Gotcha. On the ingest front, do you have any numbers around that? I see some benchmarks that focus on other (important) aspects like QPS but didn't catch anything on ingest.
Say I'm using ELK for log aggregation. Would Vespa be a good replacement? One pain point is ingest rate. How many "average" log lines per second can Vespa do per node?
I recently read about how Plex got trusted SSL certificates for all their users in partnership with DigiCert, and was really curious if a similar scheme could be accomplished with Let's Encrypt. The scheme required wildcard certificates so I figured it wouldn't be possible. But with this announcement, maybe it would be! I work on a product that generates a self-signed cert and so our customers always get a cert warning. They can replace the cert with their own if they like, but some customers aren't set up to do that. Offering an alternative where we securely mediate creation of a trusted SSL cert would be fantastic.
You raise some good points, like the kubelet killing off pods in hopes of getting a new pod with juicier secrets associated with it, but nevertheless the ticket mentioned by the sibling comment (https://github.com/kubernetes/kubernetes/issues/40476) sounds like a property that Docker's secret handling already has. It would be great to see Kubernetes work this way, too.
Coincidentally, I'm working on a project that uses Kubernetes and it has a very locked down pod placement policy, so the attack you described would be significantly scoped down. But I don't think the same is true of most Kubernetes deployments.
I agree. I also care more about access control than encryption. But if you obtain a kubelet's credentials, you can read all secrets. It would be nice if a kubelet's access was restricted to only what the kubelet needs to know. That would limit the impact of a node in a cluster being rooted.
"Currently, anyone with root on any node can read any secret from the apiserver, by impersonating the kubelet. It is a planned feature to only send secrets to nodes that actually require them, to restrict the impact of a root exploit on a single node."