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."
I'd have assumed this was Sipser's book as well, except that I was recently at a university bookstore and saw the third edition of his book priced at over $200. Sipser's a great writer, but that's an outrageous price. When I was in school, it was still expensive at a bit over $100.
I am grateful this free alternative exists, because the subject matter is really fun.
ST2's first public alpha release was in January 2011 and there was an update about every two weeks.
Six months later, July 2011, the first Beta was released and Jon Skinner said there would be monthly updates now that ST2 was in beta.
True to his word, there's been about an update a month and then in June 2012 the Beta label was dropped. After that, there were a few ST2 updates, mostly fixes, until September 2012. So by no means is ST2 an "unfinished" piece of software. And while I'm sure it has many bugs, that's practically a truism for any piece of complicated software. I personally have not actually noticed any. I wonder if the author has.
My takeaway from all this is that Jon Skinner delivers.
If you want a yearly subscription, well, that's really no different than what Jon Skinner is providing, except that instead of paying once a year, you're paying once every TWO years, if the past is any indication of the future.
Finally, complaining about plugins breaking is like complaining about the Lightning connector on new iPhones. There's a strong list of good reasons to make backward-incompatible changes to the plugin system.