Certificate and Secret Management Service (CSM)
- 1 Project Name:
- 2 Meetings
- 3 Project description:
- 4 Scope:
- 4.1 Certificate Management Service
- 4.1.1 The below diagram illustrates Best Practices of Certificate Enrollment that is end-point initiated.
- 4.1.2 The below diagram illustrates Certificate Enrollment that is Middle Man initiated
- 4.1.3 This diagram shows mapping of Certificate Provisioing in ONAP context.
- 4.1.4 The below diagram details the architechture blocks used previously in detail:
- 4.1.5 The below diagram the same architecture blocks as above with a Sidecar service:
- 4.1.6 Use Case Sequence Diagrams
- 4.2 Secret Management Service
- 4.3 SoftHSMv2 +TPM2-Plugin
- 4.1 Certificate Management Service
- 5 Architecture Alignment:
Project Name:
Proposed name for the project:
Certificate and Secret Management Service
Proposed name for the repository : csm
Meetings
[csm] Team ONAP7, Thr. UTC 04:00 / Thr. China 12:00 / Wed Eastern 23:00 / Wed Pacific 20:00
Slides presented at Beijing Developer Forum, Santa Clara.
Project description:
This project proposal address two areas in the ONAP deployment structure from a security perspective.
Secure Communication between microservices.
Current state and need
ONAP consists of multiple micro services which talk to each other.
There are two types of communication.REST API based communication.
DMAAP 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
Requirement:
Enable TLS1.2+ for securing communication among the services. Java and Python libraries do support this functionality, but easy certificate provisioning is required for Mutual TLS. This project aims to simplify PKI - certificate provisioning via a simple and secure CA service that stores private keys (CA private key at CA and user certificate private keys) securely using hardware security.
Storage of sensitive information such as passwords.
Current state and gaps
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.
Hence there is a need to ensure that attack surface related to password exposure is reduced.
Requirement:
Need for secure secret management. Services are expected to get the secret only on needed basis using secret reference and remove the secrets once they are used up.
This project aims to provide solutions to the above needs by:
Provide Certificate Management Service (CA Service) to provision signed certificates required for Mutual TLS.
Provide Certificate Request Agent SDK
Provide hardware security plugin for storing private keys and for performing crypto operations that require private keys.
GUI/CLI for Certificate Management Service
Provide Secret Management Service for adding/deleting/updating/reading secrets.
Provide Secret Client Agent SDK
GUI/CLI for Secret Management Service.
Scope:
Certificate Management Service
The proposed project will provide a Certificate Management 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 CA for enrollment and then use TLS to establish secure communication channels between each other.
The Certificate Management 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 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 Certificate Management Service over REST API
Periodically generates a usage report
Certificate Renewal
Discovery of Certificate Management Service
The below diagram illustrates Best Practices of Certificate Enrollment that is end-point initiated.
The below diagram illustrates Certificate Enrollment that is Middle Man initiated
This diagram shows mapping of Certificate Provisioing in ONAP context.
The below diagram details the architechture blocks used previously in detail:
The below diagram the same architecture blocks as above with a Sidecar service:
Use Case Sequence Diagrams
Secret Management Service
The project will also provide a Secret Management Service with the following features and capabilities:
Support multiple Secret domains
Each domain can be used to multiple secrets
Each domain is associated with various policies
Each secret can have multiple key value pairs
Certificate based authentication
Authenticate users with AAF
Token based authentication
Securely store secrets using AES encryption
Use TPM/SGX for key storage if available
RESTful API support for ADD, UPDATE, DELETE of secrets
The below diagram illustraces the Secret Service High Level Flow in an ONAP Context
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.
SoftHSMv2 +TPM2-Plugin
This project provides SoftHSMv2 with an extended capabilities to leverage TPM2.0 hardware capabilities to generate RSA/ECC keypairs and import keys generated outside of TPM2.0 module. This is achieved by modifying SoftHSMv2, adding an adapter layer between SofhHSMv2 and TPM2-Plugin.
Bullseys coverage tool is used to measure the codes coverage:
Architecture Alignment:
CSM is a common service across ONAP components.
Other Information:
Seed code:
Vault project: https://github.com/hashicorp/vault
Key Project Facts:
Primary Contact : @Srinivasa Addepalli
Facts | Info |
---|---|
PTL (first and last name) | |
Jira Project Name | TBD |
Jira Key | TBD |
Project ID | TBD |
Link to Wiki Space | TBD |
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 |
---|---|---|---|
sms | aaf/sms | org.onap.aaf.sms | Secret Management Service that will contain the webservice as well as client code for managing and accessing secrets. |
sshsm | aaf/sshsm | org.onap.aaf.sshsm | A repository for softhsm modifications and hardware security plugin |
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 | Kiran Kamineni | kirankamineni | kiran.k.kamineni@intel.com | Santa Clara, CA |
Committers | Kiran Kamineni | kirankamineni | kiran.k.kamineni@intel.com | Santa Clara, CA |
Girish Havaldar | giri | hg0071052@techmahindra.com | Bangalore, India | |
Contributors | Vamshi Namilikonda | vamshi.nemalikonda | Pune, India | |
Manjunath Ranganathaiah | mrangana | Santa Clara, CA, USA | ||
Ning Sun | ningsun | Santa Clara, CA, USA |