-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Use TLS authentication for cluster-api libvirt connection #296
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: bison If they are not already assigned, you can assign the PR to them by writing The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/test golint |
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.
Overall approach looks good to me.
Documentation/dev/libvirt-howto.md
Outdated
``` | ||
|
||
Note that authentication is not currently supported, but should be soon. | ||
You can omit the `--network` flag if you're using the defualt |
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.
"defualt" -> "default"
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.
Fixed.
Documentation/dev/libvirt-howto.md
Outdated
@@ -74,45 +83,7 @@ On Debian based distros, modify `/etc/default/libvirtd` and set: | |||
libvirtd_opts="--listen" | |||
``` | |||
|
|||
Next, restart libvirt: `systemctl restart libvirtd` | |||
|
|||
Finally, if you have a firewall, you may have to allow connections from the IP |
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.
Where's this going? Don't we still need to open up the firewall to let these connections through?
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.
We shouldn't need this any of this if we're deriving the libvirt URL from the cluster network. Rules will already be added by libvirt to allow traffic to the bridge / gateway from the nodes.
# and that the cluster-api controller pod will be able to connect | ||
# to. Often 192.168.122.1 is the default for the virbr0 interface. | ||
uri: qemu+tcp://192.168.122.1/system | ||
uri: qemu:///system |
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.
Without the IP address, how does the cluster API controller talk to libvirtd
?
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.
See below. It's talking via the gateway / bridge now.
return "", err | ||
} | ||
|
||
uri := fmt.Sprintf("qemu+tls://%s/system?pkipath=%s", gateway.String(), libvirtPKIPath) |
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.
Ah, this is why you can drop the IP from the config. I'm a bit nervous about assuming QEMU. Won't that break non-Linux libvirt even more (#201). Can we stick with the IP-form in the config and drop the libvirtURI
helper?
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.
Hmm, I'd really like to stick with something close to this. The current default in the config is kind of a hack. It's just relying on a popularly configured default network that is totally unrelated to the infrastructure being defined for the cluster.
What if I parse the URL that's in the config here and generate this a little more carefully, keeping the driver and other options?
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.
Changed this to be a bit smarter and added some tests.
hack/libvirt-ca/main.go
Outdated
|
||
cfg := &tls.CertCfg{ | ||
KeyUsages: x509.KeyUsageKeyEncipherment | x509.KeyUsageDigitalSignature, | ||
ExtKeyUsages: []x509.ExtKeyUsage{x509.ExtKeyUsageServerAuth, x509.ExtKeyUsageClientAuth}, |
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.
Does libvirt explicitly require a client auth EKU on the server cert?
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.
Oops. No. Fixed.
/test e2e-aws-smoke |
Adds a script to help with one-time generation of TLS asserts for libvirt.
Renders a secret containing pre-generated libvirt TLS credentials to be used by the cluster-api components.
Generates the libvirt URI used by the cluster-api based on the cluster network. This lets the installer talk to libvirt over the local socket, while the cluster-api uses a TLS connection.
Bumps the machine-api-operator image to include support for mounting the libvirt credentials secret.
Updates the documentation for the libvirt development setup to include TLS authentication between the cluster-api and the host libvirtd.
@bison I think it is not an immediate requirement, so we are deferring the review for now while we finish up some of the large work. We'll follow up once we have some spare cycles. |
@bison: PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
@bison I have a WIP PR [1] for handling cloud creds (aws and openstack) and also have stubbed out something for libvirt creds. The cloud-creds secret is generated in tectonic svc, not bootkube svc. After you rebase this PR, we can see if it makes sense to include the libvirt creds secret generation with this cloud-creds secret PR er not. [1] #427 |
@crawford: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
This enables TLS authentication for the connection from the in-cluster cluster-api components to the host libvirtd. It includes a script under
hack/
to generate the necessary TLS assets, and includes Terraform changes to conditionally render a secret containing the client credentials.@crawford mentioned that it might be best to hold off on this until the asset generation is rewritten, but I wanted to get something up for reference. If this needs to be put on hold, that's fine. I can rebase when ready.