Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

« Previous Version 4 Next »

Project Name:

  • Proposed name for the project: Secure Communication And Secret Server

Project description:

This project proposal tries address two areas in the ONAP deployment structure from a security perspective.

  1. Communication between micro services.
    • ONAP consists of multiple micro services which talk to each other.
      There are two types of communication. 

      1. REST API based communication.
      2. DMAPP publish/subscriber based communication.

      Since the communication is mostly over HTTP, there is a need to protect services from:

      • Bad actors stealing the data on the wire.
      • Receiving messages from bad actors.

  2. Storage of sensitive information such as passwords.
    • Many services in ONAP use password based authentication. Eg: Database servers, publish/subscribe brokers etc.
    • Passwords are stored in plain text files in many services.
    • With multiple instances of these services, the attach surface area becomes very big.

This project aims to provide solutions to the above needs by:

  1. Providing a service to secure communication among micro services via Mutual Authentication of end points (Mutual TLS) and HTTPS.
  2. Providing a secret service that will provide RESTful API to ADD, DELETE, UPDATE of secrets and secure storage of secrets using AES encryption.

Scope:

Internal CA Broker Service

The proposed project will provide an Internal CA Broker Service which will be used for certificate enrollment by micro services. The ultimate goal is to make sure that all micro services communicate securely between each other using the Interal CA for enrollment and then use TLS to establish secure communication channels between each other.

The CA Broker Service will support the following:

  • RESTful API support for Certificate Request Operations by micro services
    • Generate Certificate
    • Revocation of Certificate
    • Usage report updates
    • Token Authentication
  • An Admin interface
    • That will generate a self signed CA
    • Upload any admin generated CA Cert + Private Key pair
    • Usage reports on each key
    • Revoke certificates
    • Get CA Certificate in PEM/DER format
    • Token service to provide temporary tokens

There will also be a Client that will be part of the project written in either Python or Java that will be used to communicate with the CA Broker Service to enroll certificates.
It will have the following roles/abilities:

  • Generate RSA/ECDSA key pair using PKCS11
  • Securely store the private key.
    • Store the private key using TPM if it is available
  • PKCS10 CSR generation
  • Communicates with the previously described CA Broker Service over REST API
  • Periodically generates a usage report
  • Certificate Renewal
  • Discovery of Internal CA Broker Service

The below diagram illustrates how a micro service will communicate with the CA Broker Service to enroll its certificate.

Certificate Provisioning and Communication

The below diagram details the architechture blocks used previously in detail:

Secret Service

The project will also provide a Secret Service with the following features and capabilities:

  • RESTful API support
    • ADD
    • UPDATE
    • DELETE
    • Token based authentication for above requests
    • username and password based authentication will also be supported
  • Securely store secrets using AES encryption
  • Use TPM/SGX for key storage if available

The below diagram illustrates how a micro service will use the secret client agent to talk to the secret service to store or retrieve passwords.

Architecture Alignment:


Other Information:

  • TBD

Key Project Facts:

Primary Contact : Srinivasa Addepalli

Facts

Info

PTL (first and last name)
Jira Project NameTBD
Jira KeyTBD
Project IDTBD
Link to Wiki SpaceTBD

Release Components Name:

Note: refer to existing project for details on how to fill out this table

Components Name

Components Repository name

Maven Group ID

Components Description



org.onap.




Resources committed to the Release:

Note 1: No more than 5 committers per project. Balance the committers list and avoid members representing only one company.

Note 2: It is critical to complete all the information requested, that we help to fast forward the onboarding process.

Role

First Name Last Name

Linux Foundation ID

Email Address

Location

PTL



Committers


















Contributors













  • No labels