...
- Proposed name for the project:
ConfigPersistencySvc
- Proposed name for the repository:
ConfigPersistencySvc
- Project Logo:
PROJECT DESCRIPTION
The Configuration Persistence Service is a platform component that is designed to serve as a data repository for Run time data that needs to be persistent. It is characterized by the following purpose statements:
...
Architecture Info | Wiki Links |
COMPONENT DESCRIPTION R6 | ARC RunTime DB Component Description - R6 Frankfurt |
COMPONENT DESCRIPTION R7 | ARC Configuration & Persistency Service (CnPS) Component Description - Guilin (R7) Release |
PROJECT PROPOSAL | RunTime Config DB Project Proposal (Oct 25 2019) |
ARCHITECTURE CPS FLOW
The following page contains the CPS flows.
...
CPS SECURITY REQUIREMENTS
Authentication and Authorization
- CPS uses Basic Authentication control provided by spring security
- Usernames and passwords are configurable by the clients via passing the environment variables for use in application.yml file.
- For deployments, CPS uses K8s secrets which are generated and stored as the application is deployed.
When CPS is run with docker, the services use usernames and passwords that are stored as environment variables.
HTTPS
- CPS is compatible and in the process of migrating to a service mesh via the ONAP service mesh implementation. (https://gerrit.onap.org/r/c/oom/+/124287)
Input ValidationLogging and Monitoring
- CPS uses spring boot boots Logback and Log4j for logging information without exposing credentials (usernames and passwords).
- CPS has no logging of sensitive information such as usernames and passwords in plain text. The log files are only accessible within the authorized users of the application deployment.
SECURITY ASSURANCE
Input Validation
- CPS uses spring boot input validation support for initial input validation.
- CPS uses java mechanisms to further validate inputs such as parameters.
- CPS accepts models and data which are validated via a third-party tool (OpenDayLight YANG parser).
Logging Authentication and MonitoringAuthorization
- CPS uses spring boots Logback and Log4j for logging information without exposing credentials (usernames and passwords)Basic Authentication control provided by spring security
- Usernames and passwords are configurable by the clients via passing the environment variables for use in application.yml file.
- For deployments, CPS uses K8s secrets which are generated and stored as the application is deployed.
When CPS is run with docker, the services use usernames and passwords that are stored as environment variables.
CPS does not run docker containers or services as 'root'.
- For deployments, CPS uses K8s secrets which are generated and stored as the application is deployed.
OPERATIONAL DESCRIPTION
C&PS DB operation is described. The following sections describe the basic operations of C&PS DB.
...
Next Step | Description | Response |
---|---|---|
1 | 1A. Name of the project is appropriate (no trademark issues etc.); 1B. Proposed repository name is all lower-case without any special characters | Official Name of the project will be CONFIGURATION PERSISTENCE SERVICE Apache Geode is also using CPS, but it is not trademarked. Geode CPS |
2 | Project contact name, company and email are defined and documented | Toine Siebelink is the PTL and info can be found at KEYPROJECTFACTS |
3 | Description of the project goal and its purpose are defined | The goal and purpose are on the project proposal: PROJECTDESCRIPTION |
4 | Scope and project plan are well defined | The scope is defined in the project proposal: SCOPE |
5 | Resources committed and available (company commitments, all people) | These can be found here: RESOURCES Repo TBD |
6 | Contributors identified (people who add code) +2 | These can be found here: RESOURCES |
7 | Initial list of committer identified (elected/proposed by initial contributors) +1 | These can be found here: RESOURCES |
8 | Meets ONAP TSC Policies (NFR, GR, Code review, Testing, Audits, Documenting Interface) | The C&PS team intends to follow all ONAP TSC Policies. |
9 | Proposal has been socialized with potentially interested or affected projects (e.g. AAI, CDS, SO) and/or parties | TSC - TSC 2020-10-01 Requirement S/C - ONAP R8 Modeling High Level Requirements Architecture S/C - Modeling S/C - ONAP R7 Resource IM Call 2020-9-21 E2E Network Slicing (Requirements/Use Cases) SON PCI (Requirement/Use Cases) |
10 | Cross Project Dependencies (XPDs). In the case where a project will require changes in other projects, those projects are listed in the proposal, and a sponsoring developer in the project has been identified | There are no changes required upon other ONAP Platform component projects. |
11 | Tools have been identified and discussed with relevant partners (Linux Foundation, IT). Once the project pass the review:
| 1. Tool Chain: (action) 2. Tools: (action) 3. Code Review: using Gerrit for Code Review. 4. Testing: unit, integration test will be part of the developer work; ONAP goal for 55% testing code coverage. Will be using SonarQube. 5. Project Page: Configuration & Persistency Service R7 Developer page: Configuration & Persistency Service PoC |
...