You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

Page Status:
Component Status:

Last Reviewed on:

Certified by:

1. High Level Component Definition and Architectural Relationships (template)






2. Component API definitions

Template Component provides the following interfaces:

Offered Interface NameOffered Interface Description


ModelAPI Specs (Swagger)
xxxE-1External Interface Definition. 

capabilities

x.y.z (according to strategy)

model-a

model-b


xxxI-2Internal interfaces if we want to raise them

 Display and update:

xxxxx





Note:   xxxI interface is a internal interface.  xxxxE interface is a external interface

Template Component consumes the following Interfaces:


Consumed Interface NameConsumed Interface Description



















3. Component Description:

A more detailed figure and description of the component.

<< link to project-specific description elsewhere >>

4. Component Deployment Architecture

Should reference the deployment section in the component description template

5. New Release Capabilities

<< 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 Conformance

  • Describe ONAP API and data security conformance 
    • Service Mesh conformance / plan for secure communications, routing, etc. 
    • Use of AAF ? If so, a migration plan to Service Mesh and new security architecture
    • 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 (question)
    • 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
  • 7: General section: Documentation change for this new capability? 

7. Document Changes

8. References

to any supporting docs that are not referenced in other templates

  • No labels