-
Notifications
You must be signed in to change notification settings - Fork 13
Use attested-tls-proxy rather than cvm-reverse-proxy on Buildernet #65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: trunk/buildernet
Are you sure you want to change the base?
Conversation
...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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
| 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| --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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
This almost definitely will not work as-is - but its a rough sketch as a starting point.