ONAP Next Generation Security & Logging Architecture

Overview: ONAP Next Generation Security & Logging Architecture, Design and Roadmap

• Provided Rationale for Service-Mesh Security: uniform, open-source- and standard-based security at the platform-level

• Istio was chosen for ONAP Service-Mesh Security to fulfill ONAP security requirements

• Defined ONAP Security Architecture, leveraging Istio, Keycloak, Cert-Mgr, Ingress, Egress

• Multi-Tenancy architecture and plan were addressed

• OOM team defined the service-mesh implementation priority for Istanbul; service-to-service mTLS first and then, AAA (AuthN, AuthZ, Audit)

• Currently, collecting feedback from NSA

• Implementation Plan for Istanbul:

  • Phase 1: OOM will contribute this mTLS with Service-Mesh (contribution target: SDC, DCAE, SO, AAI, DMaaP, SDNC)

    • make selected components Service-Mesh compatible

    • Configure service-to-service mTLS communication 

    • Configure peer authentication policies

    • Configure authorization policy for coarse-grained authorization

  • Phase 2: OOM plans to contribute on AAA, Multi-Tenancy and logging (stretch goals)

    • Deploy/Configure Keycloak as the reference IdAM

    • Configure Istiod for public key and JWT handling

    • Configure request authentication policies

    • Configure additional authorization policies

Migration from AAF to Service-Mesh Security

Why not ONAP AAF (Application AuthZ Framework)

• It is a solution for ONAP, which is maintained by ONAP only

• AAF CADI plugin supports Java only, where some ONAP components are written in other languages (Python, etc.)

• Clients in various languages could have language specific restrictions

• AAF needs to keep up with the latest security technology evolution, but no active support in ONAP

• AAF is not widely used by ONAP projects due to:

• Integration/enforcement of AuthN and AuthZ are done by each project

• Mutual-TLS enablement & Secrets/certificate management are done by each project

• For encryption, each project needs to understand AAF certificate management mechanism

• Compatibility with variety of external authentication systems is a challenge

• Third-party microservices requires modification to work with AAF

• SSO and Multi-factor authentication support is questionable

We want to achieve simpler, uniform, open source- and standard-based Security (Service Mesh-pattern Security):

• Eliminate or reduce microservice infrastructure level security tasks in services

• Security is handled at the platform level

• Enabling uniform security across applications

• Minimize code changes and increase stability

• Platform-agnostic abstraction reduces risks on integration, extensibility and customization

• Use of Sidecar, so security layer is transparent for the application

• External Interfaces secured at Ingress Gateway

• Internal Interfaces secured at Service Mesh Sidecar

• User Management  and RBAC is managed by open-source technologies

Benefits to ONAP, O-RAN and External Components

• The uniform, open-source-based and standard-based security would be a foundation for secure integration between ONAP / O-RAN and external components

• Product impacts for security would be minimum

• Ensure ONAP services have only the business logic of that service

• Third-party microservices can participate in ONAP security by leveraging the platform-level security (sidecar)

• Vendors can take advantage of open-source-based security, instead of having and maintaining their own security mechanism: cost effective

Service Mesh Security with Istio

The following diagram depicts the Istio mesh architecture overview:

Open

Why Istio?

Istio was chosen because it fulfills the current ONAP security requirements/needs with the following capabilities and yet provides future-proof mechanism.

However, please note that a new platform could be considered in the future as needed.

Istio authentication and authorization:

• Provides each service with a strong identity representing its role to enable interoperability across clusters and clouds.

• Secures service-to-service communication with authentication and authorization.

• Provides a key management system to automate key and certificate generation, distribution, and rotation.

Microservices have security needs:

• To defend against man-in-the-middle attacks, they need traffic encryption.

• To provide flexible service access control, they need mTLS (mutual TLS) and fine-grained access policies.

• To determine who did what at what time, they need auditing tools.

With Control and Data planes, mTLS, Ingress, Proxy and Egress, Istio provides Security features for :

• Strong identity

• Powerful policy

• Transparent TLS encryption

• Authentication, Authorization and Audit (AAA) tools to protect your services and data

Goals of Istio-based security are:

• Security by default: no changes needed to application code and infrastructure

• Defense in depth: integrate with existing security systems to provide multiple layers of defense

• Zero-trust network: build security solutions on distrusted networks

ONAP Security Architecture - Leveraging Istio, Keycloak, Cert-Mgr, Ingress, Egress

The following diagram depicts ONAP Security Architecture.

Security Functional Blocks

• Ingress Controller (realized by istio-ingress gateway)

• AuthN/AuthZ Gateway (sidecar) – future consideration

• ONAP IdAM (realized by Keycloak)

• User Administration

• Tenant Administration

• Proxy (sidecar) – for data plane

• oauth2-proxy

• External IdP (vendor-provided component)

• External IdAM

• Egress

• Istiod – control plane (pilot, citadel, galley, cert-mgr)

• Certificate Authority (CA)

Kubernetes Ingress vs. Istio Ingress Gateway

Kubernetes Ingress

• One NodePort per service

• It is a reverse proxy and Nginx is recommended

• Different ports for different applications

• It has limited traffic control/routing rules and capabilities

Istio Ingress Gateway

• It is a POD with Envoy that does the routing

• It is configured by Gateway and Virtual Service (which configures routing and enables intelligent routing)

• It can be configured for routing rules, traffic rate limiting, policy-based checking, metrics collections

Security Architecture Highlights

• Use of control plane and pluggable sidecar (platform container) proxies to protect application service

• Intercept traffic and check AuthN/AuthZ with IdAM and IdP

• Support SSO for Human user access request

• Compatibility with variety of external authN/authZ systems (e.g., external IdP, IdAM)

• Allowing external IdP(s) and IdAM(s)

• Enabling a foundation for authN federation

• RBAC support, based on user role, group & permission

• Multi-Tenancy support

ONAP Component Security Requirements

The following is ONAP component security requirements.

Open

ONAP OOM Plan - Istanbul Priorities

The following diagram depicts ONAP OOM plan and Istanbul priorities:

note:

1. Istio 1.10 is used

2. for Istanbul, the ONAP default IdAM (realized by Keycloak) will be used as the reference implementation/configuration. 

3. Keycloak internal IdP will be used

4. Multi-tenancy support of external IdAM and IdP will not configured

ONAP Component mTLS (A): make core ONAP deployable on Service Mesh (mTLS first without AAA): basic_onboarding, basic_vm automated integration tests

• Service Mesh compatibility: 

  • DMaaP Compatibility on service mesh

  • Cassandra (and Istio 1.10?) 

  • AAI is ongoing

    • issue on jobs; trying here to "quitquitquit" solution (cleanly exit the server)

    • issue on sparky be: there's an aaf leftover part

    • cannot test part needing cassandra for now

  • SDC is ongoing

  • SO is planned

  • DCAE is ongoing

  • SDNC is planned

• Better use of Service Mesh within components:

  • SO: patch ongoing: https://gerrit.onap.org/r/c/so/+/122263

• Plan to check if we can run without authentication on these components; also check if we enlarge # of components

Communication Protocol between Service and Proxy and between Proxies

• The communication protocol between Service and Proxy is "HTTP".

  • Service-Mesh Security architecture supports security at the platform level

  • Application does not handle security directly

  • For that, Service and the corresponding Proxy will sit on the same POD to make their communication internal

• The communication protocol between Proxies is mTLS via "HTTPs".

ONAP Component AAA (B) – stretch goal for Istanbul

• onboard roles and realm on Keycloak for tests / reference implementation (use of OIDC / JWT)

• add oauth2-proxy in the solution to redirect unauthenticated traffic to SSO Portal (keycloak as example)

• add some rules to enforce (AuthorizationPolicy)

• add some service accounts (work ongoing)

OAuth2-based Access Token AuthN/AuthZ

The following diagram depicts OAuth2-based Access Token AuthN/AuthZ.

• If the access token is used (unless self-contained access token), the Resource Server needs to ask the Authorization Server for the access token validation.

• This can cause chatty communication between the Resource Server and the Authorization Server.

• By leveraging the JWT (JSON Web Token), the above chatty communication can be reduced.

• In ONAP, the JWT is used for the browser client and application client request authN and authZ - see the following

OAuth2-based JWT AuthN/AuthZ

The following diagram depicts OAuth2-based JWT AuthN/AuthZ.

• By leveraging the JWT (JSON Web Token), the chatty communication between the ResourceServer and the Authorization Server can be removed.

• In ONAP, the JWT is used for the browser client and application client request authN and authZ - see the following

ONAP Browser Client Request Authentication and Authorization Use Case

The following diagram depicts the browser client request authentication and authorization process.

Machine Client Request Authentication and Authorization

The following diagram depicts the machine client request authentication and authorization process, by leveraging IdAM and Istio which support JWT.

Request Authentication Configuration

Request authentication policies specify the values needed to validate a JWT. Istio checks the presented token.

• If presented requests are against the rules in the request authentication policy, it rejects requests with invalid tokens

• When requests carry no token, they are accepted, but authorization policies can validate requests

• If more than one policy matches a workload, Istio combines all rules 

See the authentication policy section for details.

Service-2-Service (Peer) mTLS Communication With Istio

• The Service-to-Service authN is supported by leveraging mTLS certificates, instead of username/password

• Also, authorization will be supported for mTLS by Istio authorization configuration

• Two services will communicate using a direct connection (e.g., via REST APIs) without passing thru Ingress Controller or MSB

mTLS Certification Management

The following diagram depicts the Istio Certificate management and interaction with the Proxy (istio-agent and envoy proxy work together with istiod to automate key and certificate roation):

mTLS Service-2-Service Secure communication with Authentication and Authorization 

The following diagram depicts the Service-to-Service mTLS secure communication with Authentication and Authorization:

Authentication Mode

Peer authentication policies specify the mTLS mode that Istio enforces on target workloads:

• PERMISSIVE: workloads accept both mTLS and plain text traffic

• STRICT: workloads accepts only mTLS traffic

• DISABLE: mTLS is disabled

A permissive mode allows a service to accept both plaintext traffic and mutual TLS traffic at the same time. During the transition period, the permissive mode would be allowed for non-Istio clients communicate with non-Istio servers. Once ONAP components are Service-Mesh enabled, the permissive mode could be disabled.

Authentication Policy Configuration

Note: during Istanbul, peer authentication will be configured first (high priority). Then, OOM will visit the request authentication.

Authentication Policies are configured in .yaml files, and are saved in the Istio configuration storage once deployed. The Istio controller watches the configuration storage. Upon any policy changes, Istio sends configurations to the targeted endpoints (e.g., Envoy Proxy). Once the proxy receives the configuration, the new authentication requirement takes effect immediately on that pod.