None available

CPS don’t have security requirements apart from the authentication on our rest API wherein username and passwords are configurable

Configuration Persistence Service Project#CPSSECURITYREQUIREMENTS

 Please add a statement about this to the end of your architecture document (or in another wiki page), with a heading such as "CPS Security Requirements."

Please refer to the latest ONAP architecture diagram.

London-R12 Architecture Diagram

Please elaborate this statement: "Usernames and passwords are configurable by the clients via configuring the application .yml file".

Expectation: passwords are not in yml file. The yml should point to user store (e.g. LDAP or K8s secrets). 

Configuration Persistence Service Project#CPSSECURITYREQUIREMENTS

CPS don’t have security requirements apart from the authentication on our rest API wherein username and passwords are configurable.

CPS has no logging of sensitive information such as usernames and passwords in plain text. The log files are only accesible withing the  authorized users of the application deployment.

CPS is in the process (as part of ONAP service mesh implementation) of migrating to service mesh, currently CPS application is fully-compatible with all the requirements, to provide encryption in transit to avoid unauthorized accesses and data breaches.

CPS does not run docker containers or services as 'root'.

Please add these statements to a new Security Assurance section just after: Configuration Persistence Service Project#CPSSECURITYREQUIREMENTS.  — these statements are the same as under security requirements

Also add statements that indicate how you protect your username and password configurations. (See other questions on hashing of secrets, use of crypto and permissions on files.)

CPS does not have a UI and does not use javascript

The application uses Swagger for RESTful API, wherein it is set that Authorization headers are required for accessing API documentation.

Usernames and passwords are configured in .yml file of CPS for clients to configure.

When CPS is run with docker, the services use usernames and passwords that are stored as environment variables.

While for testing purposes, all credentials are hard-coded, for deployments, CPS uses K8s secrets which are generated and stored as the application is deployed.

How are usernames and passwords stored?

Are passwords stored hashed where CPS acts as an authenticator?

Please refer to comment above in Documentation security.

Usernames and passwords are

configurable by the clients via passing the environment variables for use in application.yml file

.

When CPS is run with docker, the services use username and passwords that are stored as environment variables.

For deployments, CPS uses K8s secrets which are generated and stored as the application is deployed.

Usernames and passwords are

configurable by the clients via passing the environment variables for use in application.yml file

.

When CPS is run with docker, the services use username and passwords that are stored as environment variables.

For deployments, CPS uses K8s secrets which are generated and stored as the application is deployed.

CPS is compliant and compatible with the ongoing service mesh implementation (see https://gerrit.onap.org/r/c/oom/+/124287) for ONAP. 

CPS service port names has been changed to include http in name.

Usernames and passwords are

configurable by the clients via passing the environment variables for use in application.yml file

.

When CPS is run with docker, the services use username and passwords that are stored as environment variables.

For deployments, CPS uses K8s secrets which are generated and stored as the application is deployed.

CPS is compliant and compatible with the ongoing service mesh implementation (see https://gerrit.onap.org/r/c/oom/+/124287) for ONAP. 

CPS service port names has been changed to include http in name.