SPIFFE
SA is at cluster level.
So Nepheo could not use SA
Every CSP has workload identity
spiffe is standard:
- spiffe id. It is URL.
- spiffe verifiable documents (SVIDs): cert or toekn
- The spiffe workload API.
spire: spiffe Runtime Environment.
- A toolchain of API for establising trust based on spifee
- provides out of the box attestation plugins
Expiry is short. can be 4 hours. So no need of revocation
* spire agent can be colocated. it is dameonset in K8s.
=========
Nephio
ss7, sigtra, ngin, CN model (e.g. ORAN)
DISH is on AWS
CP based requirement for identity
Nephio SIG security wiki page has all details
Porch : Package Orchestration KPT
KPT does in place substitution
5G requirements / usecases
IMS, SMO , IMS
LF article about Nephio spifee implementation at LF wiki
Catalog packages at GitOps
Each cluster shall have its own repo
Identity federation is based on cert chain.
R3 Oct 23 of Nephio.
It is proposed solution. It will be upstream.
Workload identity solution shall not be native to specific cloud provider.
Identity federation across CSPs.
Google, E//, RedHat are in Nephio
SPIRE's alternative may be due to speicfic attestion plugin
What protocol between SPIRE Agent and SPIRE server? Bootstrap trust. it is pre-provision aspect. REST API and TLS. x.509 cert will be pulled. protocol is spire specific
Today's attestation is based on SA, pod labels, namespace.
CA, Cert Manager can be used.
Network Automation
Telecom Networks are complex due to multi layer, multi vendor
N/w Management -> SDN -> Intent Based Networking (programable and declarative) -> Cloud Native Networking
Earlier Monolithic NMS with FCAPS
Now : CICD, Microservice, K8s.
NSP (N/s Service Platform) is for IP and optical domain
It has API (OpenAPI Spec).
Model-driven mediation
Framework has orchestration
Contributed by Nokia: Kubenet, gNMIc, SDCIO
1. Unified Artifactory Manager Component
It uses Kubespray
UAM creates CRs. CRs are consumed by deployer. Deployer is short lived job.
2. Telemetry:
A: internal NSP components
B: External system
Four Core Principle
1. Model driven
2. Vendor & Mediation Agnostic
3. Horizontal scale
4. Resilent
Six Layers
6. Analytics and optimization layer
5. o/p / storage layer : Kafka
3.and 4 make it model driven
4. Normalization Layer
3. Mapping layer
2. Collector layer (SNMP, gNMI)
1. N/w layer
Architecture
UAM, Restconf GW
source : from network using SNMP, gNMI
Sink: influxDB, Prm, VErtica, Kafka, PostgreSQL, File
Source and Sink are connected using NATS. NATS also connected with multiple transform worker using transformer CR from UAM
gNMIc
1. single mode
2. CLI mode (auto complete option)
3. cluster mode (more replica. one is leader).
Kubenet and SDCIO
declarative model and event driven reconciliation. It is more n/w automation using K8s. Gitops principle.
Arch:
SDCIO Schema Driven Configuration.
IPAM etc are CRD to build abstract network configuration.
Config CR and ConfigSet CR, RunningConfig, UnmanagedConfig. It has different backend own etcd.
YANG by schema server.
==========================
BNG, CUPS specific implementation
Kubenet Nephio are solving same problem? May be overlap.
APIs for sink? customer provides sink.
Kubenet is automation. more than NMS
Slide 21: Cisco Prime
