provider/openstack: Support client certificates

[ZZelle]

Official OpenStack clients commonly[*] support specifying a client
certificate/key to enable SSL client authentication when communicating
with OpenStack services. This patch enables such feature in Terraform
with new parameters and environment variables:

• 'cert' provider parameter or OS_CERT env variable to specify client
  certificate file,
• 'key' provider parameter or OS_KEY env variable to specify client
  certificate private key file.

[*] keystoneclient, neutronclient, glanceclient, cinderclient, novaclient, heatclient support it; openstackclient, swiftclient support it but in trunk branch.
http://docs.openstack.org/releasenotes/python-openstackclient/unreleased.html

[jen20]

@phinze might this benefit from the work you did for on-prem certificate validation?

[jtopjian]

@jen20 I don't think so. I reviewed #6453 and I think this PR is different.

@ZZelle Thank you for this patch and I'm really sorry for the delay in looking at it. If I understand this PR correctly, this is to enable a user to specify a cert and key rather than a username and password, correct? Or is the cert and key used as a first level of authentication and a username and password are still used? If the latter, then this PR makes sense to me and I think it can be merged. However, it'd be helpful to know how one could quickly configure devstack to verify this operation -- thoughts on that?

[ZZelle]

@jtopjian theorically both cases are possible BUT in practice OpenStack clients support only the 2nd case: client cert as 1st level auth, user/pass as a 2nd one. That's why this commit focuses only on the 2nd case.

AFAIK, devstack is not able to deploy such infrastructure. You can perhaps change keystone's apache2 configuration to require users to use client certs BUT imo, the easiest solution to verify this commit is to deploy a normal devstack infrastructure and "hides" it behind a SSL proxy which requires client certificates. A typical example with Nginx:

 # cat /etc/nginx/sites-enabled/secure
 server {
  listen              443 ssl;
  ssl_certificate     /etc/nginx/server.crt;
  ssl_certificate_key /etc/nginx/server.key;

  # NOTE(zzelle): the client certificate part
  # CA to check client certs
  ssl_client_certificate ca.client.crt;
  # Client cert check must succeed
  ssl_verify_client on;

  location /identity {
    proxy_pass http://<keystone-host-port>/;

    # NOTE(zzelle): rewrite location headers + bodies
    proxy_set_header Host TOREWRITE;
    proxy_redirect http://TOREWRITE https://$http_host/identity;
    sub_filter     http://TOREWRITE https://$http_host/identity;
    sub_filter_once off;
    sub_filter_types *;
  }

  location /compute {
    proxy_pass http://<nova-host-port>/;

    # NOTE(zzelle): rewrite location headers + bodies
    proxy_set_header Host TOREWRITE;
    proxy_redirect http://TOREWRITE https://$http_host/compute;
    sub_filter     http://TOREWRITE https://$http_host/compute;
    sub_filter_once off;
    sub_filter_types *;
  }
}

You must define also a new region secure in keystone which points to Nginx SSL proxy and must be used by Terraform:

keystone endpoint-create --region secure --service keystone --publicurl 'https://<proxy>/identity/v2.0
keystone endpoint-create --region secure --service nova --publicurl 'https://<proxy>/compute/v2/%(tenant_id)s'

or:

openstack endpoint create keystone --region secure  --publicurl 'https://<proxy>/identity/v2.0
openstack endpoint create nova --region secure --publicurl 'https://<proxy>/compute/v2/%(tenant_id)s'

PS: https://github.com/OpenVPN/openvpn/tree/master/sample/sample-keys provides sample keys which avoids to build the ca + server/client certificates

PS2 : You can also look in https://review.openstack.org/303863 comments which provides more information

PS3: if you need some support, i am zzelle in #openstack-dev freenode channel

[ZZelle]

@jen20 I don't think so. I reviewed #6453 and I think this PR is different.

Yes, they are different: this PR focuses on client cert authentication support (ie: server checks client certificate is valid) where #6453 focuses on ca management for server cert check (ie: client checks server cert is valid)

[jtopjian]

@ZZelle Thank you for the detailed info! I was indeed able to get a test environment working with this. In addition, this does not cause failures with any current acceptance tests, but that was more or less a given.

This is good to go! Thank you for your help and contribution! 😄

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.