Authenticated Topic Provisioning
An Authenticated Topic in ONAP refers to a Message Router topic with the following characteristics:
client applications (i.e. publishers or subscribers) will connect to a Message Router instance using either
the Message Router REST API on secure port (3905)
the Native Kafka API on secure port ( TBD)
client AAF credentials will be used to:
authenticate the client
authorize the client for the action (pub or sub) on the specific topic
In order to properly provision an Authenticated Topic, the AAF permissions for managing topic namespaces, creating topics, and creating and granting the permissions for client actions on a specific topic, all must be coordinated using various APIs. This functionality is provided by the DMaaP Bus Controller API, and is intended to used as a convenient way for applications to use DMaaP resources like Authenticated Topics.
This article will describe how to provision an Authenticated Topic using the DMaaP Bus Controller in ONAP Dublin.
There are 3 ways to utilize the DMaaP Bus Controller API:
Static - some topics are known in advance as part of Release planning and need to be provisioned in all ONAP deployments. These are provisioned during the DMaaP deployment process.
DCAE - some topics are needed by microservices managed by DCAE. These topics are provisioned by the DMaaP Plugin used in DCAE deployments.
On Demand - a user could use an http client (e.g. curl) to provision a topic. This might be needed in a dev environment, or in some other deployment scenario.
The remaining sections describe each of these methods.
Prerequisites
The AAF Identity used by the client application needs to exist in the AAF instance that DMaaP components are referencing. In a standalone ONAP deployment, this means that AAF must be deployed and the AAF bootstrap provisioning must have successfully completed. An application should follow the directions from the AAF team for establishing a new Identity that is included in future AAF bootstraps.
The Identity used by Bus Controller (i.e. dmaap-bc) must be granted the necessary permissions to create topics and AAF Roles associated with the topics. This makes Bus Controller a "trusted provisioner". The AAF bootstrap should include all the steps necessary to satisfy this prerequisite.
(Future) The Identity used by the client to the Bus Controller API must be authorized to invoke the /topics API. AAF Authentication and Authorization of usage of the Bus Controller API assures that only authorized clients will make provisioning changes.
Static
An Authenticated Topic created using the Static method is provisioned during the deployment of the message-router component. A post-install job associated with the message-router chart will provision all topics found in a well known ConfigMap. To add a new topic using this method, simply add a new file to the following OOM directory: oom/kubernetes/dmaap/components/message-router/resources/topics
The format of this file should be a valid JSON request to the Bus Controller POST /topics API
The post-install job runs the dbc-client container, which is authorized to make Bus Controller API calls.
NOTE: Any ONAP component could utilize this method (i.e. post-install script reading a ConfigMap) to tie provisioning of an Authenticated Topic to their component deployment. This would introduce a deployment ordering dependency on DMaaP, but that probably already is necessary for normal operations.
DCAE
An Authenticated Topic created using the DCAE method is provisioned using the Cloudify DMaaP Plugin during deployment of the microservice. The details about the topic and application Identity are specified in the application blueprint. Refer to Secure & Dynamic Feed/Topic support for DCAE MicroServices for an excellent explanation and demo.
On Demand
An Authenticated Topic created using the On Demand method is always available in an ONAP DMaaP deployment. A user can use an http client application such as curl or postman to make a request to the Bus Controller POST /topics API.