-
Notifications
You must be signed in to change notification settings - Fork 48
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
[tls] nova novncproxy to support vencrypt #748
[tls] nova novncproxy to support vencrypt #748
Conversation
Restructures the tls section of the novncproxy API to support passing a secret name which holds the cert/key to be used for vencrypt. The CA to validate the vnc server is part of the global bundle. Jira: OSPRH-6552
Issues a certificate for nova novncproxy if PodLevel tls is enabled and configures it as vencrypt secret on the novnc proxy. Depends-On: openstack-k8s-operators/nova-operator#748 Depends-On: openstack-k8s-operators/dataplane-operator#862 JIRA: OSPRH-6552
Issues a certificate for nova novncproxy if PodLevel tls is enabled and configures it as vencrypt secret on the novnc proxy. Depends-On: openstack-k8s-operators#779 Depends-On: openstack-k8s-operators/nova-operator#748 Depends-On: openstack-k8s-operators/dataplane-operator#862 JIRA: OSPRH-6552
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.
Looks good to me. Thanks for adding the env test coverage too.
@@ -139,6 +139,12 @@ notify_on_state_change = vm_and_task_state | |||
enabled = True | |||
novncproxy_host = "::0" | |||
novncproxy_port = 6080 | |||
{{if (index . "VencryptClientKey") }} | |||
auth_schemes=vencrypt,none |
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.
so "none" here allows the proxy to fall back to not encrypted connection if the qemu side of the connection does not support encryption. I'm wondering if we need to allow this.
First I thought that in greendfield we don't need this as either TLS is enabled in the whole deployment or not. But I guess we need to support deploying without TLS, booting instances, and then enabling TLS in the deployment. At that point the existing qemu instances will not support TLS. So we need the fallback.
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 correct thats the use case we'd need this for. and since the computes config is controlling if the vencrypt is used I think its not a big issue.
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.
yepp fine by me.
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 what its worth i believe that we are not currently planning to support enabling tls after the fact as a documented procedure but I'm fine with making the code capable of that so that we can actually do it when a customer or PM asks.
i was wondering the same as gibi but I'm fine with that answer.
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 already got that request. E.g. for adoption if someone has not tlse on the current env, it should stay the same, but possible to be enabled as a day 2 thing after adoption. the procedure is on our list to be tested/document.
Build failed (check pipeline). Post https://review.rdoproject.org/zuul/buildset/598eea0b7aaf4b49868ef7309df5bd27 ❌ openstack-k8s-operators-content-provider FAILURE in 13m 15s |
Issues a certificate for nova novncproxy if PodLevel tls is enabled and configures it as vencrypt secret on the novnc proxy. Depends-On: openstack-k8s-operators#779 Depends-On: openstack-k8s-operators/nova-operator#748 Depends-On: openstack-k8s-operators/dataplane-operator#862 JIRA: OSPRH-6552
build failure seems to be due to non backward compatible change in the CRD
|
yes it is a breaking change. what I could do is
|
Yeah that is the way forward I guess. Unfortunately the tempest coverage on openstack-operator does not include the vnc tests so we cannot use the test result there to force merge this PR. |
Build failed (check pipeline). Post https://review.rdoproject.org/zuul/buildset/926df67f1d9b4ab991932521bb69d253 ❌ openstack-k8s-operators-content-provider FAILURE in 13m 30s |
will be removed/reverted in a follow up.
3a957b9
to
b06b9bc
Compare
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.
this looks good to me too
just one thing to note is this might conflict with the work kamil is doing on observed generations but there is no way to really avoid that.
@@ -139,6 +139,12 @@ notify_on_state_change = vm_and_task_state | |||
enabled = True | |||
novncproxy_host = "::0" | |||
novncproxy_port = 6080 | |||
{{if (index . "VencryptClientKey") }} | |||
auth_schemes=vencrypt,none |
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 what its worth i believe that we are not currently planning to support enabling tls after the fact as a documented procedure but I'm fine with making the code capable of that so that we can actually do it when a customer or PM asks.
i was wondering the same as gibi but I'm fine with that answer.
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.
thanks for doing the extra dance with the deprecation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: gibizer, SeanMooney, stuggi 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 |
Note, tempest vnc tests will fail. that is expected with the current openstack-operator version. we should override it. basically with moving the params, but still have the deprecated one, the openstack-operator expects that from the route -> vnc proxy it is possible to use tls while it isn't right now. |
or we temporary disable tempest.api.compute.servers.test_novnc.NoVNCConsoleTestJSON if you prefer |
I will override the job if this test fail. I will expect a clean result in the follow up where the deprecated field is dropped. |
Build failed (check pipeline). Post https://review.rdoproject.org/zuul/buildset/5dcf4df7ffe4465a8ac634d3ba09f106 ✔️ openstack-k8s-operators-content-provider SUCCESS in 3h 02m 47s |
|
The rest of the tempest is green so I'm merging this. |
Issues a certificate for nova novncproxy if PodLevel tls is enabled and configures it as vencrypt secret on the novnc proxy. Depends-On: openstack-k8s-operators#779 Depends-On: openstack-k8s-operators/nova-operator#748 Depends-On: openstack-k8s-operators/dataplane-operator#862 JIRA: OSPRH-6552
Issues a certificate for nova novncproxy if PodLevel tls is enabled and configures it as vencrypt secret on the novnc proxy. Depends-On: openstack-k8s-operators#779 Depends-On: openstack-k8s-operators/nova-operator#748 Depends-On: openstack-k8s-operators/dataplane-operator#862 JIRA: OSPRH-6552
Issues a certificate for nova novncproxy if PodLevel tls is enabled and configures it as vencrypt secret on the novnc proxy. Depends-On: openstack-k8s-operators#779 Depends-On: openstack-k8s-operators/nova-operator#748 Depends-On: openstack-k8s-operators/dataplane-operator#862 JIRA: OSPRH-6552
Restructures the tls section of the novncproxy API to support passing a secret name which holds the cert/key to be used for vencrypt. The CA to validate the vnc server is part of the global bundle.
Jira: OSPRH-6552