...

1. Kubernetes interface is REST. Exact supported version of kubernetes has to be specified by every ONAP release
2. Database interface depends on DB type but only encrypted communication should be used
3. xNF interface depends on particular xNF but all xNFs should support secure protocols for communication
4. NFVI interface is REST (usually OpenStack or Kubernetes)
5. IAM interface is Open ID Connect
   1. if operator already has OIDC compatible solution ONAP should just use it
   2. if operator has Identity Provider (LDAP/Kerberos/etc) external OIDC solution should be deployed (ie keycloak) with operator IdP configured as backend
   3. In testing environment external OIDC solution should be deployed and bootstraped with test users
6. CA interface can be one of:
   1. Manual interaction by deployer that will retrieve certificates and the bootstrap ONAP instance with them
   2. One of automated certificate retrieval protocols (ACME, CMPv2 etc)
   3. In testing environment external CA (and ONAP should use automated certificate retrieval as described in b) solution should be deployed

Requirements

...

on interfaces

Kubernetes

1. Cluster should be configured according to CIS guidelineKubernetes Benchmark
2. Encryption at rest should be properly configured to ensure that secrets are never stored in the plain text

...

1. Each DB should be configured according to corresponding CIS guideline
2. All DB should be already created or ONAP should be provided with user that is capable of creating DB
3. If ONAP creates a DB a dedicated user account with privileges limited to that DB should be created. Password used for this user cannot be hardcoded in ONAP source.

xNF

...

1. Define by the  ONAP VNF security requirements

NFVI

...

1. Defined by the CNTT Reference Architecture 1 & 2

IAM

1. IAM has to must support OpenID connect Connect standard

CA

1. If automated certificate retrieval is used one of .... has to be supported by the CA (CMPv2, ACME, SCEP)

Requirements

...

on exposed interfaces

1. North and south interfaces should be separated (ie different instance of ingress controller) to allow to configure operator network policy properlyprovide operator deployment flexibility
2. All Northbound interfaces has to musts be protected using TLS
3. All Northbound interfaces has to must support SSO
4. All Northbound interfaces has to must support RBAC
5. All roles used in ONAP have to be documented
6. All forms should validate and sanitize their input provided by the user
7. Southbound interfaces has to fulfill must satisfy VNF security requirements
8. ...

...

1. ONAP should not include any user database
2. ONAP should not implement RBAC on it's own but depend on external component to provide it
3. ONAP should not implement CA functionality but depend on external component to provide it
4. ONAP components should use mTLS instead of username/password for authentication between each other
5. ONAP should configure network policies so that only desired components can communicate with each other
6. ONAP have to must store all sensitive material (keys, passwords) in kubernetes Kubernetes secrets
7. ONAP docker images have to be hardened (see CIS Docker Benchmark)
8. ONAP can must use only approved docker base images
9. ONAP should log all important events in the to a centralized placelocation
10. ONAP should log security audit logs to a secure location
11. ONAP logs cannot include any secret material (e.g., passwords and keys)
12. All ONAP components have to must support OIDC
13. ...

Current ONAP security model

Cloud-Native ONAP security model

1. Every component in it's its own namespace
2. All "common" components in separate namespaces
3. No implicit dependencies between common components and ONAP
4. No nodeports unless really required
5. istio-ingress used as ingress controller
6. Up to 4 entrypoints for deployment. For example
   1. simpledemo.onap.org (UI)
   2. south.simpledemo.onap.org (southbound interfaces)
   3. iam.simpledemo.onap.org (keycloak)
   4. api.simpledemo.onap.org (API for OSS/BSS)
7. Every entrypoint exposed as a separate ingress instance
8. Every ingress gateway does terminates the SSL termination and reencrypts the traffic and send to the TSL and re-encrypts the payload before sending to the destination component using mTLS
9. Istio ISTIO network policy must be configured in a way so that only desired authorized services can communicate with each other
10. Auth between services done using certs (via mTLS)
11. OpenID Connect used to authenticate user
12. In testing deployment keycloak is used but can be replaced with anything else compatible with OIDC
13. Cert-manager and citadel used to retrieve certificates
14. Kubernetes is configured to use encryption at rest plugin
15. ISTIO automated sidecar injection is configured in underlying kubernetesKubernetes
16. No root pods
17. All DB are considered as external
18. Documented roles
19. Ability to integrate with LDAP, Kerberos, AAF as IdP
20. Ability to retrieve the certificate from external CA

...