Building jq portably is annoying, and the way we were doing it (which we
iirc stole from some google project?) sucked. Let's use a Go jq clone
instead.
This is an alternative for 1535. jq is currently used only in one
script, which could really be replaced by a Go program, but let's keep
it simple for now.
Change-Id: Ie25dffadd545df143490f510e9b75a74adf81492
Reviewed-on: https://gerrit.hackerspace.pl/c/hscloud/+/1540
Reviewed-by: palid <palid@hackerspace.pl>
Fixes after the security bugfix last week.
Not yet rolled out to qa/prod.
Change-Id: I52de0dc1d082fd1c6269025b1f41d87c02c67113
Reviewed-on: https://gerrit.hackerspace.pl/c/hscloud/+/1536
Reviewed-by: q3k <q3k@hackerspace.pl>
Public pull ACL in the middle had priority over our more specific rules
- moving these to the top fixes common registry namespace ACLs.
Change-Id: Ia6f05cef09c0db4eb71155d2c0e2d9944b81f903
Reviewed-on: https://gerrit.hackerspace.pl/c/hscloud/+/1522
Reviewed-by: q3k <q3k@hackerspace.pl>
This replaces the old clustercfg script with a brand spanking new
mostly-equivalent Go reimplementation. But it's not exactly the same,
here are the differences:
1. No cluster deployment logic anymore - we expect everyone to use ops/
machine at this point.
2. All certs/keys are Ed25519 and do not expire by default - but
support for short-lived certificates is there, and is actually more
generic and reusable. Currently it's only used for admincreds.
3. Speaking of admincreds: the new admincreds automatically figure out
your username.
4. admincreds also doesn't shell out to kubectl anymore, and doesn't
override your default context. The generated creds can live
peacefully alongside your normal prodaccess creds.
5. gencerts (the new nodestrap without deployment support) now
automatically generates certs for all nodes, based on local Nix
modules in ops/.
6. No secretstore support. This will be changed once we rebuild
secretstore in Go. For now users are expected to manually run
secretstore sync on cluster/secrets.
Change-Id: Ida935f44e04fd933df125905eee10121ac078495
Reviewed-on: https://gerrit.hackerspace.pl/c/hscloud/+/1498
Reviewed-by: q3k <q3k@hackerspace.pl>
This allows us to access hscloud nix 'facts' from Go.
Change-Id: Ic8fc3350a7d073947c44529fcae0bbb8627421aa
Reviewed-on: https://gerrit.hackerspace.pl/c/hscloud/+/1508
Reviewed-by: q3k <q3k@hackerspace.pl>
hermetic python introduced in f21ca38 depends on libcrypt.so.1 which is
provided by libxcrypt
Change-Id: Iff6e34bb75320bb300811878eeb0b0bc95783697
Reviewed-on: https://gerrit.hackerspace.pl/c/hscloud/+/1504
Reviewed-by: q3k <q3k@hackerspace.pl>
This reimplements capacifier, one of the earliest
just-some-flask-code-on-boston-packets services, in Go.
It's a minimum reimplementation, as this service is generally deprecated
- but some stuff still depends on it. So we do away with capacifier v0's
bespoke rule language and just hardcode everything. It's not like any of
these rules ever changed, anyway.
This is not yet deployed.
Change-Id: Id65ef92784a524c32ae5223cd5460736ac683116
Reviewed-on: https://gerrit.hackerspace.pl/c/hscloud/+/1509
Reviewed-by: ironbound <ironbound@hackerspace.pl>
Seems like they aren't actually setting it on their end.
Change-Id: Ia751cd1560196ae44be15f759681dd9d679370da
Reviewed-on: https://gerrit.hackerspace.pl/c/hscloud/+/1485
Reviewed-by: q3k <q3k@hackerspace.pl>
This completes the migration away from the old CA/cert infrastructure.
The tool which was used to generate all these certs will come next. It's
effectively a reimplementation of clustercfg in Go.
We also removed the unused kube-serviceaccounts cert, which was
generated by the old tooling for no good reason (we only need a key for
service accounts, not an actual cert...).
Change-Id: Ied9e5d8fc90c64a6b4b9fdd20c33981410c884b4
Reviewed-on: https://gerrit.hackerspace.pl/c/hscloud/+/1501
Reviewed-by: q3k <q3k@hackerspace.pl>
This finishes the regeneration of all cluster CAs/certs to be never
expiring ED25519 certs.
We still have leftovers of the old Kube CA (and it's still being
accepted in Kubernetes components). Cleaning that up is the next step.
Change-Id: I883f94fd8cef3e3b5feefdf56ee106e462bb04a9
Reviewed-on: https://gerrit.hackerspace.pl/c/hscloud/+/1500
Reviewed-by: q3k <q3k@hackerspace.pl>
This is already deployed, and it allows Kubernetes components
(temporary) freedom to use the old or new CA cert.
Change-Id: I8ac7f773a333c30fa22902b8edc327c0c700a482
Reviewed-on: https://gerrit.hackerspace.pl/c/hscloud/+/1490
Reviewed-by: q3k <q3k@hackerspace.pl>
This gets rid of cfssl for the kubernetes bits of prodvider, instead
using plain crypto/x509. This also allows to support our new fancy
ED25519 CA.
Change-Id: If677b3f4523014f56ea802b87499d1c0eb6d92e9
Reviewed-on: https://gerrit.hackerspace.pl/c/hscloud/+/1489
Reviewed-by: q3k <q3k@hackerspace.pl>
Done:
1. etcd peer CA & certs
2. etcd client CA & certs
3. kube CA (currently all components set to accept both new and old CA,
new CA called ca-kube-new)
4. kube apiserver
5. kubelet & kube-proxy
6. prodvider intermediate
TODO:
1. kubernetes controller-manager & kubernetes scheduler
2. kubefront CA
3. admitomatic?
4. undo bundle on kube CA components to fully transition away from old
CA
Change-Id: If529eeaed9a6a2063bed23c9d81c57b36b9a0115
Reviewed-on: https://gerrit.hackerspace.pl/c/hscloud/+/1487
Reviewed-by: q3k <q3k@hackerspace.pl>
q3k
palid
ar
informatic
implr
vuko