1a2312bc61
This patch revises the structure of OAuth 2.0 Admin document by separating the Tacker as an API server and Tacker as an API client. And separates the HTTPS/mTLS document from the Oauth 2.0 document. Change-Id: I15fc20e49ebb39eea346c8a475db8b22b600d301 Depends-On: I2deb71242f555bbae5ee7c798add18490cb38344
8.8 KiB
Configuring Tacker as OAuth 2.0 Client
Note
The content of this document has been confirmed to work using Tacker 2024.1 Caracal.
Overview
As an API client, Tacker can use Oauth 2.0 Client Credentials Grant flow and OAuth 2.0 Mutual-TLS Client Authentication to access the Notification server and the External NFVO server. The OAuth 2.0 Client Credentials Grant flow of RFC6749 OAuth 2.0 Authorization Framework is prescribed in the API specification of ETSI NFV-SOL013 v3.4.1. And Tacker implements OAuth 2.0 Mutual-TLS Client Authentication based on RFC8705.
Guide for OAuth 2.0 Client Credentials Grant
You can enable Tacker as OAuth 2.0 Client Credentials Grant by following this guide.
Enable Client Credentials Grant for Access to Notification Server
If the certification of the notification authorization server is not
trusted, the configuration file /configuration/config can be modified to set the
verify_oauth2_ssl to false, then the backend no longer
verify the certification when it obtains the OAuth 2.0 access token. If
the certification of the notification callback API is not trusted, the
configuration file /configuration/config can be modified to set the
verify_notification_ssl to false, then the backend no
longer verify the certification when it sends a notification.
Modify the configuration file as needed.
$ vi /etc/tacker/tacker.conf [vnf_lcm] verify_notification_ssl = false [authentication] verify_oauth2_ssl = falseRestart Tacker service so that the modified configuration information takes effect.
$ sudo systemctl restart devstack@tacker.service
Verify that Access Uses Client Credentials Grant
Subscribe to a notification that requires OAuth 2.0 Client Credentials Grant to confirm that Tacker can send a notification successfully to Notification Server.
$ cat subsc_create_req.json
{
"filter": {
"vnfInstanceSubscriptionFilter":{
"vnfdIds": [
"108135bb-8f21-4b91-a548-4aad3cf72a87"
]
}
},
"callbackUri" : "$callback_uri",
"authentication": {
"authType":["OAUTH2_CLIENT_CREDENTIALS"],
"paramsOauth2ClientCredentials": {
"clientId": "$notification_oauth2_client_id",
"clientPassword": "$notification_oauth2_client_secret",
"tokenEndpoint": "$notification_oauth2_token_endpoint"
}
}
}
$ openstack vnflcm subsc create subsc_create_req.json --os-tacker-api-version 2
+--------------+----------------------------------------------------------------------------------------------------------+
| Field | Value |
+--------------+----------------------------------------------------------------------------------------------------------+
| Callback URI | $callback_uri |
| Filter | { |
| | "vnfInstanceSubscriptionFilter": { |
| | "vnfdIds": [ |
| | "108135bb-8f21-4b91-a548-4aad3cf72a87" |
| | ] |
| | } |
| | } |
| ID | b25c2d6f-6de4-450a-a25d-321868d3ed83 |
| Links | { |
| | "self": { |
| | "href": "https://$tacker_host_name/vnflcm/v2/subscriptions/b25c2d6f-6de4-450a-a25d-321868d3ed83" |
| | } |
| | } |
| verbosity | FULL |
+--------------+----------------------------------------------------------------------------------------------------------+Guide for OAuth 2.0 Mutual-TLS Client Authentication
To use Tacker as mTLS OAuth 2.0 client, client private key and
certificate will be necessary. You can reference /admin/configure_tls to
create private root CA, private key and certificate that will be
required in this guide. Because different authorization servers have
different ways of authenticating TLS certificates provided by client,
the relevant Subject Distinguished Names such as Common Name need to be
set when creating client certificate according to the authorization
server. The tacker_cert_and_key.pem file that is used in
this guide, can be created by concatenating the client certificate file
and client private key file.
$ cat tacker_client.pem tacker_client.key >> tacker_cert_and_key.pemYou can enable Tacker as a mTLS OAuth 2.0 client by the following steps in this guide.
Enable Mutual-TLS Client Authentication for Access to Notification server
The following parts describe steps to enable mTLS only for access to the Notification server.
Modify the configuration file
tacker.confto enable SSL to implement mTLS support. The following settings are examples, and the certificate should be saved in a directory with appropriate access permission.$ 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.pemRestart Tacker service so that the modified configuration information takes effect.
$ sudo systemctl restart devstack@tacker
Enable Mutual-TLS Client Authentication for Access to External NFVO server
The following parts describe steps to enable mTLS only for access to the External NFVO server.
Modify the configuration file
tacker.confto enable SSL to implement mTLS support. The client_id and client_password must be obtained from the authentication server used by the External NFVO server. 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/token client_id = client_id client_password = client_password mtls_ca_cert_file = /etc/tacker/multi_ca.pem mtls_client_cert_file = /etc/tacker/tacker_cert_and_key.pemRestart Tacker service so that the modified configuration information takes effect.
$ sudo systemctl restart devstack@tacker
Verify that Access Uses Mutual-TLS Client Authentication
Access to the External NFVO server and the Notification server is not outputted to the Tacker log. Therefore, check the access log of the External NFVO server and the Notification server when executing lcm operations, 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 the server are sending certificates to each other during the handshake, you can verify that mTLS is enabled.