...
iPage Status:
Component Status:
Last Reviewed on:
Certified by:
Table of Contents |
---|
1. High Level Component Definition and Architectural Relationships (template)
...
<< list the new capabilities that were introduced in this release, or a hot-link to the key features. New sub-chapter per release, as per a release notes document >>
6. Security ConformanceConformance
- Describe ONAP Component API and data security conformance
Describe the component Service Mesh conformance / plan for secure communications, routing,etc. Use of AAFauthentication and authorization configurationsDoes the component have AAF dependencies? If so, describe the current dependencies and a migration plan to
- Supporting of Authentication and Authorization
- e.g., coarse-grained authorization support
- e.g., fine-grained authorization support (how it is done?)
- Data protection
- Data at rest
- new data storage location/mechanism
- Describe Logging conformance
- Log field standards
- User sensitive data
- Logging destination STDOUT / STDERR conformance
- What is new in logging capabilities
- Identify data existing ;
- Container Hardening: Configuration of Docker / Kubernetes; following the benchmark (hardening plan)
- pen testing?
- non-root access. (e.g., container image needs privilege ??)
- SECCOM feedback:
- info: Pawel I'd like a few minutes to discuss logging (Python POC and Logging Arch)
They need to look at the K8s hardening guide from NSA ;) - Secure the Container Image repository
Hashing function to identify images
Digitally sign created images. Perform integrity check on images
Limit access of containers
Some things, like docker daemon, require root access. Others do not. Limit access and privileges where possible
Limit access per container, depending on what the NF requires
Linux Security Modules (LSM): fine grained control of user permissions
Leverage “fence” services to limit access via host OS
Namespaces, cgroups, etc. Segregate containers from other software on the host OS
Leverage service mesh architecture - confirmed, logs to STDOUT has been a Global Requirement since Jakarta. REQ-441 LOGS MANAGEMENT - PHASE 1: COMMON PLACE FOR DATA. Canonical List of TSC Best Practice and Global Requirements
remove the dependanciesHow does the component support authentication and authorization of its clients (Humans, other applications)?
- Describe the component data protection
- Data storage location/mechanism
- Data protection plan, such as data at rest, data-level access control, data in transit, others
- User sensitive data handling (e.g., password)
Describe the component / container hardeningThe component must run as non-root-based users. Does the component use non-root-access only? Otherwise, describe the reasons and non-root-access support plansDoes the component container require privilege access/right? If so, describe the reasons and migration plansIs the component image signed digitally for integrity? (TBD)Does the component use the basic image to conform to the global requirementJira server ONAP Jira serverId 425b2b0a-557c-3c0c-b515-579789cceedb key REQ-1073 Does the component follow the K8s hardening guide? e.g., from NSA, https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF
- Describe the component logging conformance
- Does the component conform to the Log field standards best practice,
? If not, please describe the reasons and support plans.Jira server ONAP Jira serverId 425b2b0a-557c-3c0c-b515-579789cceedb key REQ-1072 - Does the component exclude user sensitive data (e.g., password, private key, other credentials) from logging? If not, please describe the reasons and support plans.
- Does the component support the Logging destination STDOUT / STDERR conformance? If not, please describe the reasons and support plans.
- Does the component conform to the Log field standards best practice,
Documentation for the component securityDescribe the component security architecture and conformance in the document.
- The project should fill out a ONAP Security Review Questionnaire Template and review it with SECCOM.
- The project should follow the CISA Memory Safe Code guidance, not to introduce memory unsafe code, joint-guidance-exploring-memory-safety-in-critical-open-source-projects-508c.pdf, The-Case-for-Memory-Safe-Roadmaps-508c.pdf7: General section: Documentation change for this new capability?
7. Document Changes
8. References
...