Using OAuth2.0 mTLS for Tacker¶
Overview¶
OAuth2.0 Mutual-TLS (mTLS) Client Authentication based on RFC8705 is implemented as an extension of Tacker. As an API client, Tacker can use an mTLS connection to access the LCM Notification server, External Monitoring tool server and External NFVO server.
Guide¶
Enable Tacker server to support mTLS Client Authentication by the
following steps in this guide. In this example, tacker.host is the domain
name used by the Tacker server.
Create private key and client certificate¶
In order to use mTLS, it is necessary to create a private key and client certificate. Although you typically use a certificate issued by a public CA, this guide describes how to create a self-signed certificate to test the mTLS functionality. If the certificate used for mTLS authentication was issued by a public CA, skip steps 1 to 3.
Generate an RSA private key.
$ openssl genrsa -out tacker_priv.key 4096 Generating RSA private key, 4096 bit long modulus (2 primes) .........................................+++++ .........................+++++ e is 65537 (0x010001)
Create a certificate signing request.
$ openssl req -new -key tacker_priv.key -out tacker_csr.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]: State or Province Name (full name) [Some-State]: Locality Name (eg, city) []: Organization Name (eg, company) [Internet Widgits Pty Ltd]: OpenstackORG Organizational Unit Name (eg, section) []: DevDept Common Name (e.g. server FQDN or YOUR name) []:tacker.host Email Address []: dev@tacker.host Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:
Use the root certificate to generate a self-signed certificate. The
oenssl x509command creates a certificate file. The options are:-req
Use CSR as an input.
-in csrfile
Use csrflie as input for certificate creation.
-CA cafile
Use cafile as the certificate of the signing CA.
-CAkey keyfile
Use keyfile as the CA private key.
-CAcreateserial
Generate serial numbers automatically.
-out certfile
Output the certificate to the path specified by certflie.
-days n
Set the certificate to expire in n days.
-sha384
Use the sha 384 algorithm to create a message digest of the certificate.
$ openssl x509 -req -in tacker_csr.csr \ -CA root_a.pem -CAkey root_a.key -CAcreateserial \ -out tacker_ca.pem -days 365 -sha384 Signature ok subject=C = JP, ST = Tokyo, L = Chiyoda-ku, O = OpenstackORG, OU = DevDept, CN = tacker.host, emailAddress = dev@tacker.host Getting CA Private Key
Merge the key and certificate into a single file. When two “BEGIN … END” sections are displayed using the cat command, you can see that the merge has succeeded.
$ cat tacker_ca.pem >> tacker_cert_and_key.pem $ cat tacker_priv.key >> tacker_cert_and_key.pem $ cat tacker_cert_and_key.pem -----BEGIN CERTIFICATE----- MIIEdzCCAl8CFGfZSo8q0f0AkmFHrDYAgOygq+X0MA0GCSqGSIb3DQEBCwUAMFYx CzAJBgNVBAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRl ... kMgBy0mLyN84vqY2GItKdYrBsEUWSif6i3tVTDa1r0gpf2o4PPOHUAaelStm3eqU KFoR418Y432RaxCEPrDOh11PAY80A/xDBhKPYM5XdRlRNtaMmdM4R2p2vw== -----END CERTIFICATE----- -----BEGIN RSA PRIVATE KEY----- MIIEpAIBAAKCAQEAt82fxcWknYkcXUuBZkk1f4M93peFh7PAgpXPMAcknp8dzm97 0veZnyh8a4PP7NBGPoKbuBERsVbd6O6HKn4qd8SYehyQ5oYbUVg5n1YsBnPHVq40 ... 4CmYegzdMh+VcDkN5vQu1wUSucqCXvzIVgNnbvmxbE7ZuDhCAHNhOvs5jPc1sh79 qAEY3/z0kZ3muKc3y9GqjdVzn6JgysXzUZ5bb3LvFe+nTYXsAU9gJw== -----END RSA PRIVATE KEY-----
Enable Tacker to support mTLS for access to Notification server¶
The following parts describe steps to enable mTLS only for access to Notification server and External Monitoring Tool server.
Modify the configuration file
tacker.confto enable SSL to implement HTTP support for the Tacker APIs. For the settings, specify the path where the certificate file created in the previous chapter is stored. The following settings are examples, and the certificate should be saved in a directory with appropriate authority.$ vi /etc/tacker/tacker.conf [v2_vnfm] notification_mtls_ca_cert_file = /etc/tacker/multi_ca.pem notification_mtls_client_cert_file = /etc/tacker/tacker_cert_and_key.pem
Restart Tacker service so that the modified configuration information takes effect.
$ sudo systemctl restart devstack@tacker
Enable Tacker to support mTLS for access to External NFVO server¶
The following parts describe steps to enable mTLS only for access to External NFVO server.
Modify the configuration file
tacker.confto enable SSL to implement HTTP support for the Tacker APIs. The client_id must be obtained from the authentication server used by the external NFVO. If you are using Keystone as the authentication server, you can use user_id as the client_id for mTLS authentication.$ vi /etc/tacker/tacker.conf [v2_nfvo] use_external_nfvo = True endpoint = https://endpoint.host token_endpoint = https://token_endpoint.host/identity/v3/OS-OAUTH2 client_id = 4241794bcc7349b68b1f7312d60bd835 mtls_ca_cert_file = /etc/tacker/multi_ca.pem mtls_client_cert_file = /etc/tacker/tacker_cert_and_key.pem
Restart Tacker service so that the modified configuration information takes effect.
$ sudo systemctl restart devstack@tacker
Verifying that Access to Each Server Uses mTLS¶
Access to external NFVO and notification servers is not output to the Tacker log. Therefore, check the access log of the external NFVO server and notification server when executing lcm operation, or use the packet capture software to confirm that the access to each server is the mTLS communication. If the packet capture shows that the client and server are sending certificates to each other during the handshake, you can verify that mTLS is enabled.
