Recent submissions

Comment · 6 years ago
Missed that. Thank you!
Comment · 6 years ago
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.
Comment · 9 years ago
From the post:

"For example, one customer told us that they plan to create hundreds of VPCs, each hosting and providing a single microservice"

At first glance, that sounds pretty neat, but looking at VPC pricing shows that PrivateLink pricing is 1 cent per hour and 1 cent per GB.

It'd be nice to discuss pricing before suggesting we partition microservices into separate VPCs. Or after. Somewhere :-)

That pricing can add up if you're making "hundreds of VPCs"!

Comment · 9 years ago
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.
Comment · 9 years ago
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?
Comment · 9 years ago
In our case, the appliance usually can access the internet, possibly through a proxy, but it's not accessible from the internet.
Comment · 9 years ago
Comment · 9 years ago
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.

Comment · 9 years ago
Comment · 9 years ago
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.
Comment · 9 years ago
It's not so much the plain text part that bothers me, it's the access control.

Quoting the docs at https://kubernetes.io/docs/user-guide/secrets/#security-prop...:

"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."

As your cluster grows, your risk grows.

Comment · 12 years ago
ExtraHop Networks - Seattle

Give us packets, get IT and business insight.

Like systems-level programming? C, Go, Python? Let's talk! [email protected]

Comment · 12 years ago
Glad the conditional/ternary operator's atypical associativity is documented now...
Comment · 12 years ago
ExtraHop Networks. Seattle, WA. [email protected]

Deep L7 protocol analysis at scale.

Comment · 12 years ago
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.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton