| Vijay VK | 2648c6d | 2018-09-19 04:30:37 +0100 | [diff] [blame] | 1 | .. This work is licensed under a Creative Commons Attribution 4.0 International License. |
| 2 | .. http://creativecommons.org/licenses/by/4.0 |
| deen1985 | de4f978 | 2021-03-25 17:33:35 +0100 | [diff] [blame] | 3 | .. _tls_enablement: |
| Vijay VK | 2648c6d | 2018-09-19 04:30:37 +0100 | [diff] [blame] | 4 | |
| 5 | TLS Support |
| 6 | =========== |
| 7 | |
| Jack Lucas | 5e9c126 | 2023-03-20 11:33:05 -0400 | [diff] [blame^] | 8 | Beginning with the London release, ONAP is using a service mesh (Istio) to encrypt and authenticate traffic between ONAP components. In earlier releases, each component was responsible for protecting its HTTP interfaces with TLS, |
| 9 | using certificates generated by the (now obsolete) AAF component. |
| Vijay VK | 2648c6d | 2018-09-19 04:30:37 +0100 | [diff] [blame] | 10 | |
| Jack Lucas | 5e9c126 | 2023-03-20 11:33:05 -0400 | [diff] [blame^] | 11 | Some DCAE components offer HTTP interfaces to clients outside the ONAP Kubernetes cluster. In earlier releases, ONAP offered a mechanism allowing components to obtain |
| 12 | TLS certificates from an external source using the CMPv2 protocol. (See `these design notes <https://wiki.onap.org/display/DW/DCAE+CertService+integration>`_ for details on how that approach worked in conjunction with AAF.) |
| 13 | Beginning with the London release, external HTTP interfaces should be exposed via the Istio Gateway. The gateway can terminate TLS and can be configured with the necessary certificates. |