Skip to content
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

Closed
wants to merge 5 commits into from
Closed

Use TLS authentication for cluster-api libvirt connection #296

wants to merge 5 commits into from

Conversation

bison
Copy link
Contributor

@bison bison commented Sep 20, 2018

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.

@openshift-ci-robot openshift-ci-robot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Sep 20, 2018
@openshift-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: bison
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: staebler

If they are not already assigned, you can assign the PR to them by writing /assign @staebler in a comment when ready.

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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@bison
Copy link
Contributor Author

bison commented Sep 20, 2018

/test golint
/test go-vet

Copy link
Member

@wking wking left a 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.

```

Note that authentication is not currently supported, but should be soon.
You can omit the `--network` flag if you're using the defualt
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"defualt" -> "default"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

@@ -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
Copy link
Member

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?

Copy link
Contributor Author

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
Copy link
Member

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?

Copy link
Contributor Author

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)
Copy link
Member

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?

Copy link
Contributor Author

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?

Copy link
Contributor Author

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.


cfg := &tls.CertCfg{
KeyUsages: x509.KeyUsageKeyEncipherment | x509.KeyUsageDigitalSignature,
ExtKeyUsages: []x509.ExtKeyUsage{x509.ExtKeyUsageServerAuth, x509.ExtKeyUsageClientAuth},
Copy link
Contributor

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops. No. Fixed.

@openshift-bot openshift-bot added needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. and removed needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. labels Sep 26, 2018
@bison
Copy link
Contributor Author

bison commented Sep 27, 2018

/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.
@openshift-ci-robot openshift-ci-robot added size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. and removed size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Sep 27, 2018
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
Copy link
Contributor Author

bison commented Sep 27, 2018

@wking / @crawford: What do you guys think of this at this point?

@crawford
Copy link
Contributor

@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.

@openshift-bot openshift-bot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Sep 30, 2018
@openshift-bot
Copy link
Contributor

@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.

@wking wking mentioned this pull request Oct 7, 2018
@sallyom
Copy link
Contributor

sallyom commented Oct 8, 2018

@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
Copy link
Contributor

crawford commented Dec 3, 2018

This looks abandoned so I'm going to close this out. @bison feel free to reopen this after you've rebased and incorporated the functionality in #427.

/close

@openshift-ci-robot
Copy link
Contributor

@crawford: Closed this PR.

In response to this:

This looks abandoned so I'm going to close this out. @bison feel free to reopen this after you've rebased and incorporated the functionality in #427.

/close

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. size/XL Denotes a PR that changes 500-999 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants