dward

For connecting VMs without public IPs to the outside world, Cloud NAT is the easiest answer. You could set one up yourself if you were so inclined (e.g. some forwarding rules and iptables rules on the bastion).

For ssh key distribution, there's a few options. You can store the key in Secret Manager and run your GCE VMs as a service account that has access to the key, then fetch it when pulling.

https://cloud.google.com/secret-manager/docs/

Something like:

$ ssh-add <(gcloud beta secrets versions access latest --secret=github-ssh-key)

On startup. I haven't actually tried out secret manager yet.

If you have too much time on your hands, you could rig something up with GCE vTPMs as well :)

https://cloud.google.com/blog/products/gcp/virtual-trusted-p...

Comment · 6 years ago

See also std::embed.

Comment · 7 years ago

An ecosystem has evolved around Borg. Custom hardware, kernel, schedulers, telemetry, atomic clocks, networking, security, management... have all evolved around Borg proper to meet the "enterprise" needs of one of the largest enterprises in the world. It has many niche (i.e. not generally useful) cababilites built to service hardware melting XXX megawatt applications like web indexing, gmail, colossus. Even if Kubernetes targeted this customer, Borg has a significant head start. At this point the Borg ecosystem is almost old enough to by cigarettes in Mountain View.

Comment · 7 years ago

A zero-day is an interesting label to put on a bug disclosed "after the company failed to fix the issue within 90 days". I guess, you learn something new every zero-day.

Comment · 7 years ago

The policy seems sane.

* They know when they can serve 0RTT from their cache safely because they can be reasonably certain if handling a cached request is side effect free.

* If connections to backend origins are reasonably persistent, there's not much latency reduction benefit from 0RTT compared to connections from consumer user agents.

Comment · 8 years ago

Oomd reminds me of userspace OOM handling mechanism proposed by David Reintjes of Google:

https://lwn.net/Articles/590960/

Comment · 8 years ago

Use go for what? DNS resolution? The default behavior is to use the system DNS resolver. The Go resolver will be used if the system is resolver is not avaialble (e.g. if the binary is compiled as pure go) or if the net.Resolver has the PreferGo flag set (which is false by default).

https://github.com/golang/go/blob/541f9c0345d4ec52d9f4be5913...

Comment · 8 years ago

By default, go compiles binaries linked to libc to use the system DNS resolver. It does re-implement a DNS resolver but it's only used if CGO is disabled at compilation time.

Comment · 8 years ago

Jerk is the derivative of acceleration. I haven't heard jank used in that context.

Comment · 8 years ago

Albeit this was years ago but I was referring to the construction linked from the original paper proposed in:

https://cs.nyu.edu/media/publications/TR2013-962.pdf

It’s pretty unweildy compared to HMAC construction because:

* each caveat addition requires local generation of a new asymmetric key pair

* the size of the macaroon grows linearly with the number of caveats. Each new caveat concatenates two asymmetric signatures to the append only signature. Each new caveat adds a public key to the macaroon ID.

* it requires a finalize step for security, meaning the final macaroon extender needs to know it’s the final extender.

It sounded rather impractical but I wouldn’t be surprised if improvements have been made since then.