Use attested-tls-proxy rather than cvm-reverse-proxy on Buildernet #65
Conversation
ameba23
changed the title
...net-gcp/mkosi.extra/etc/systemd/system/attested-tls-proxy-client.service.d/gcp-override.conf
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
For the first iteration, they could be running side be side (the previous reverse proxy and the new attested proxy server), right?
This way, we could have a fallback till we verify stability in further iterations, wdyt?
There was a problem hiding this comment.
I was thinking the other way around - for the first iteration we just want to know whether this works, and having a fallback might make us think it works when it doesn't. Once we know it works, add cvm-reverse-proxy as a fallback in case it stops working.
There was a problem hiding this comment.
we could consider creating a reproducible debian packaging pipeline for attested-tls-proxy to avoid building it manually while building the image. This would accelerate the image building process and rollout times
There was a problem hiding this comment.
Good idea. Here i was roughly following how the other rust projects on the main branch of this repo are build - with the build_rust_package.sh script, which isn't available on this branch.
It looks like we have a reproducible debian packaging pipeline for rbuilder - and since that is a rust project it would be probably quite easy to adapt it for this. In my experience i have had annoying issues with trying to get 100% reproducibility with docker - but if its working for rbuilder it will probably work for this project too.
Either way, i think it will be easiest to built the first few iterations like this, as it inevitable wont work the first few times.
| ExecStart=/usr/bin/attested-tls-proxy server \ | ||
| --listen-addr 0.0.0.0:7936 \ | ||
| --server-attestation-type azure-tdx \ | ||
| --tls-private-key-path var/lib/persistent/operator-api/key.pem \ |
There was a problem hiding this comment.
| --tls-private-key-path var/lib/persistent/operator-api/key.pem \ | |
| --tls-private-key-path %S/persistent/operator-api/key.pem \ |
There was a problem hiding this comment.
The file should probably be renamed to attested-tls-proxy-client.... Also the the main service file in buildernet image
There was a problem hiding this comment.
You mean the name of this file should match the service file it is overriding - in this case attested-tls-proxy-client.service?
| --client-attestation-type azure-tdx \ | ||
| --server-attestation-type none | ||
| --allowed-remote-attestation-type none | ||
| --tls-private-key-path var/lib/persistent/operator-api/key.pem \ |
There was a problem hiding this comment.
Should it really point to a Let's Encrypt certificate? If yes, we need to extend acme-le posthook to copy the certificate for this service separately, not re-using the path of operator-api
There was a problem hiding this comment.
Yes, this is the big difference between this and cvm-reverse-proxy - we require CA-signed certs. I agree its better to copy the pem files to a separate location for this service.
There was a problem hiding this comment.
I did this now, but i guess i need to set up a username and group for attested-tls-proxy. I can't see where that is being done for operator-api.
mkosi.images/buildernet/mkosi.conf
Outdated
| systemd-repart | ||
| systemd-resolved | ||
| tpm2-tools | ||
| libtss2-esys-3.0.2-0t64 |
There was a problem hiding this comment.
you can omit the package version. The main mkosi config file already points to a point in time snapshot repository which guarantees stable version of the packages.
There was a problem hiding this comment.
The package names should be alphabetically sorted
3 participants
This almost definitely will not work as-is - but its a rough sketch as a starting point.