Hitachi, Ltd. OSS Solution Center., profile picture
Uploaded byHitachi, Ltd. OSS Solution Center.
PPTX, PDF794 views

Lightweight Zero-trust Network Implementation and Transition with Keycloak and NGINX

This document discusses implementing a lightweight zero-trust network using the open source tools Keycloak and NGINX. It begins by explaining the transition from a traditional network security model with clear boundaries between public and private networks to a zero-trust model where security boundaries are defined individually for each service or pod. It then covers how to implement the underlying technologies of JWT validation, mutual TLS authentication, and OAuth MTLS using Keycloak as an authorization server and NGINX as an API gateway. Additional topics discussed include how to secure east-west internal traffic and resolve potential policy decision point chokepoints.

Download to read offline
© Hitachi, Ltd. 2021. All rights reserved. Lightweight Zero-trust Network Implementation and Transition with Keycloak and NGINX Open Source Summit Japan 2021 Hitachi, Ltd. OSS Solution Center Yoshiyuki Tabata
1 © Hitachi, Ltd. 2021. All rights reserved. About the speaker • Consultant of API system  For example, building a high-security banking API system. • Contributor of 3scale (OSS of API Management)  Developed features around security and access control.  “Edge Limiting”, “RBAC”, “OAuth MTLS”, … • Contributor of Keycloak (OSS of Identity Management)  Developed features required for API use cases based on OAuth/OIDC.  “Token Revocation”, “Refresh token setting per client”, … Yoshiyuki Tabata  Software Engineer  OSS Solution Center, Hitachi, Ltd.  GitHub: @y-tabata
2 © Hitachi, Ltd. 2021. All rights reserved. Session Overview (1/3) API Gateway Authorization Server Client App Resource Server Resource Server - In the traditional API system, the security boundary between the public network and the private network is clear, so we only needed to focus on it. Security Boundary Expose API! Call API Delegate Authentication and Authorization Build API system by following OAuth 2.0 the de facto standard of API security private network public network
3 © Hitachi, Ltd. 2021. All rights reserved. - In the world of microservice, various services expose their APIs, it's much difficult to define a security boundary between the public network and the private network. Session Overview (2/3) Authorization Server Client App Call API Delegate Authentication and Authorization Expose API! Expose API! Expose API! Expose API! Expose API! Expose API! Expose API! Call API Call API Call API Call API Call API Call API Call API Build API system by following OAuth 2.0 the de facto standard of API security
4 © Hitachi, Ltd. 2021. All rights reserved. zero-trust network - So we need to consider introducing "zero-trust network" to secure each service independently (per service/pod). Session Overview (3/3) Client App Call API Call API Call API Call API Call API Call API security boundary security boundary security boundary security boundary security boundary security boundary security boundary security boundary We propose Lightweight zero-trust network implementation typical way to achieve zero-trust network is with service mesh, but  it needs rich resources for its rich features  it affects the architecture a lot
© Hitachi, Ltd. 2021. All rights reserved. Contents 5 1. What is zero-trust network? 2. How to achieve the underlying technology behind zero-trust network 3. Transition from traditional security boundary definition to per service/pod definition 4. Additional topic 1: How to achieve east-west traffic 5. Additional topic 2: How to resolve chokepoint issue of Policy Decision Point
© Hitachi, Ltd. 2021. All rights reserved. Contents 6 1. What is zero-trust network? 2. How to achieve the underlying technology behind zero-trust network 3. Transition from traditional security boundary definition to per service/pod definition 4. Additional topic 1: How to achieve east-west traffic 5. Additional topic 2: How to resolve chokepoint issue of Policy Decision Point
7 © Hitachi, Ltd. 2021. All rights reserved. - To treat the system internal network the same as the public network. - The underlying technology behind zero-trust network is  JWT validation  mutual TLS What is zero-trust network? - Underlying technology Source: Istio (https://istio.io/latest/docs/concepts/security/) Istio only requires mTLS in the system internal network, but JWT validation is said to be also needed among API security professionals. Require mTLS and JWT validation in the public network.
8 © Hitachi, Ltd. 2021. All rights reserved. - In the context of OAuth 2.0, what the JWT (presented during an API call) means is OAuth 2.0 Access Token. - Access token is issued by an authorization server as representing an authorization. Underlying technology 1 - JWT validation API Gateway Authorization Server Client App 3. Call API w/ Access Token (JWT) 2. Issue Access Token after Authentication and Authorization Typical OAuth 2.0 authorization code flow 1. Delegate Authentication and Authorization - Generally, validate JWT with authorization server, i.e. following Token Introspection: RFC 7662. - What validate:  Signature: check the JWT is not tampered  Expiry: check the JWT is not expired  Scope: check the client was authorized to call the API  Audience: check the resource server (API GW) is intended to return the response Token Introspection
9 © Hitachi, Ltd. 2021. All rights reserved. during TLS handshake - As the same as authenticating the server using a server certificate, authenticate the client using a client certificate. Underlying technology 2 - mutual TLS API Gateway Client App presenting the client certificate presenting the server certificate verify client certificate using trusted CA certificates
10 © Hitachi, Ltd. 2021. All rights reserved. - In the context of OAuth 2.0, OAuth 2.0 Mutual-TLS Client Certificate-Bound Access Tokens (hereinafter OAuth MTLS) is defined in RFC 8705. - OAuth MTLS prevents access token theft. Underlying technology 2’ - OAuth MTLS (RFC 8705) API Gateway Client App - verify client certificate using trusted CA certificates - verify the hash of client certificate equals one in the Access Token Authorization Server 3. Call API w/ Access Token (JWT) (present client certificate during TLS handshake) 2. Issue Access Token (Access Token includes hash of client certificate) 1. Delegate AuthN/AuthZ (present client certificate during TLS handshake)
11 © Hitachi, Ltd. 2021. All rights reserved. - Extending token introspection, resource server can delegate client certificate check to authorization server. Underlying technology 2’ - OAuth MTLS (RFC 8705) API Gateway Client App delegate client certificate check to authorization server Authorization Server 3. Call API w/ Access Token (JWT) (present client certificate during TLS handshake) 2. Issue Access Token (Access Token includes hash of client certificate) 1. Delegate AuthN/AuthZ (present client certificate during TLS handshake) mTLS OAuth MTLS manage trusted CA certificates Both authorization server and resource server (API GW) Authorization server only prevents access token theft No Yes If you publish your API to a large number of unspecified clients on the public network, OAuth MTLS may suitable.
© Hitachi, Ltd. 2021. All rights reserved. Contents 12 1. What is zero-trust network? 2. How to achieve the underlying technology behind zero-trust network 3. Transition from traditional security boundary definition to per service/pod definition 4. Additional topic 1: How to achieve east-west traffic 5. Additional topic 2: How to resolve chokepoint issue of Policy Decision Point
13 © Hitachi, Ltd. 2021. All rights reserved. - We use Keycloak as Authorization Server, NGINX as API Gateway. What OSS do we use? NGINX (API Gateway) Keycloak (Authorization Server) Client App 3. Call API w/ Access Token (JWT) 2. Issue Access Token after Authentication and Authorization 1. Delegate Authentication and Authorization Token Introspection
14 © Hitachi, Ltd. 2021. All rights reserved. - Keycloak is an identity management OSS. - Keycloak provides OAuth 2.0 authorization server features. What is Keycloak? Major features  Supports OAuth 2.0 / OpenID Connect and SAML  Can be linked with LDAP and Active Directory  Also supports social login with such as GitHub ID management and authentication social login (Identity Brokering) ID federation corresponding to major standards (Including OAuth 2.0 authorization server) Keycloak LDAP Active Directory RDB OpenID Connect SAML GitHub Twitter Facebook
15 © Hitachi, Ltd. 2021. All rights reserved. - Keycloak supports Token Introspection as a standard feature. - NGINX supports ngx_http_auth_request_module module which implements client authorization based on the result of a subrequest. If the subrequest returns a 2xx response code, access is allowed. If it returns 401 or 403, access is denied with the corresponding error code. How to achieve JWT validation NGINX Keycloak Client App 3. Call API w/ Access Token (JWT) 2. Issue Access Token after Authentication and Authorization 1. Delegate Authentication and Authorization NGINX delegates JWT validation to Keycloak  send introspection request to Keycloak's token introspection endpoint  proxy to resource server if access token is active  deny access if access token is not active Token Introspection
16 © Hitachi, Ltd. 2021. All rights reserved. - NGINX supports ssl_verify_client syntax which enables verification of client certificates. Trusted CA certificates are specified in ssl_client_certificate syntax. How to achieve mTLS during TLS handshake NGINX Client App presenting the client certificate presenting the server certificate verify client certificate using trusted CA certificates
17 © Hitachi, Ltd. 2021. All rights reserved. - NGINX supports optional_no_ca parameter in ssl_verify_client syntax, which requests client certificate but does not require it to be signed by a trusted CA certificate. This is intended for use in cases when a service that is external to NGINX performs the actual certificate verification. - $ssl_client_escaped_cert variable returns client certificate in the PEM format for an established SSL connection. How to achieve OAuth MTLS NGINX Client App send access token and client certificate to token introspection endpoint Keycloak 3. Call API w/ Access Token (JWT) (present client certificate during TLS handshake) 2. Issue Access Token (Access Token includes hash of client certificate) 1. Delegate AuthN/AuthZ (present client certificate during TLS handshake) Token Introspection by using SPI, we can extend token introspection to check client certificate at Keycloak
© Hitachi, Ltd. 2021. All rights reserved. Contents 18 1. What is zero-trust network? 2. How to achieve the underlying technology behind zero-trust network 3. Transition from traditional security boundary definition to per service/pod definition 4. Additional topic 1: How to achieve east-west traffic 5. Additional topic 2: How to resolve chokepoint issue of Policy Decision Point
19 © Hitachi, Ltd. 2021. All rights reserved. - So far, we explained how to use Keycloak and NGINX to achieve the underlying technology behind zero-trust network. - From here, we make the grain size of security boundary finer. Security boundary transition scenario NGINX Keycloak Client App Resource Server Resource Server Security Boundary Expose API! Call API Delegate Authentication and Authorization private network public network
20 © Hitachi, Ltd. 2021. All rights reserved. - First of all, lifting the existing system to the world of containers. - Compared to cloud services, in NGINX, this API Gateway lifting is very easy because we can reuse the NGINX conf file, for example, using server-snippet and location-snippet annotations, or using custom resources named VirtualServer. Step 1: Change API Gateway to NGINX Ingress Controller NGINX Ingress Controller Keycloak Client App Resource Server Resource Server Security Boundary Call API Delegate Authentication and Authorization private network public network
21 © Hitachi, Ltd. 2021. All rights reserved. Security Boundary Security Boundary - This step is useful if the resource server's service takes a little time to be modified. - Again we can reuse the NGINX conf file. - To pass through client certificates at NGINX Ingress Controller, we use custom resources named TransportServer to configure stream context. Step 2: Shift security boundary to per service NGINX Ingress Controller Keycloak Client App Proxy Service Proxy Service Call API Delegate Authentication and Authorization Resource Server Resource Server
22 © Hitachi, Ltd. 2021. All rights reserved. Security Boundary Security Boundary - Achieve so-called sidecar. - Again we can reuse the NGINX conf file and we can reuse TransportServer setting too. - API call is first sent to proxy container, and if all checks are passed, proxy to resource server container. Step 3: Shift security boundary to per pod NGINX Ingress Controller Keycloak Client App Call API Delegate Authentication and Authorization Resource Server Resource Server container Proxy container
© Hitachi, Ltd. 2021. All rights reserved. Contents 23 1. What is zero-trust network? 2. How to achieve the underlying technology behind zero-trust network 3. Transition from traditional security boundary definition to per service/pod definition 4. Additional topic 1: How to achieve east-west traffic 5. Additional topic 2: How to resolve chokepoint issue of Policy Decision Point
24 © Hitachi, Ltd. 2021. All rights reserved. - So far, we targeted north-south traffic, i.e. traffic from client to resource server, from external to internal. How to achieve east-west traffic NGINX Ingress Controller Keycloak Client App Call API Delegate Authentication and Authorization Resource Server Resource Server container Proxy container
25 © Hitachi, Ltd. 2021. All rights reserved. - So far, we targeted north-south traffic, i.e. traffic from client to resource server, from external to internal. - How to achieve east-west traffic, i.e. traffic from internal to internal? - For example, when the resource server wants to get resources from other services. How to achieve east-west traffic NGINX Ingress Controller Keycloak Client App Call API Delegate Authentication and Authorization Another Service Resource Server container Proxy container ? Resource Server
26 © Hitachi, Ltd. 2021. All rights reserved. - So far, we targeted north-south traffic, i.e. traffic from client to resource server, from external to internal. - How to achieve east-west traffic, i.e. traffic from internal to internal? - For example, when the resource server wants to get resources from other services. - In this case, resource server container should send a request using again the proxy container. How to achieve east-west traffic NGINX Ingress Controller Keycloak Client App Call API Delegate Authentication and Authorization Another Service Resource Server container Proxy container Resource Server
27 © Hitachi, Ltd. 2021. All rights reserved. - To validate JWT, the proxy container must send JWT.  Option A: send the same access token which client sent  Option B: send the different access token getting from authorization server by following OAuth 2.0 Token Exchange: RFC 8693 - Both options, need to get user's consent. How to achieve JWT validation (east-west traffic) Proxy container Another Service Resource Server container Keycloak Option A: same Access Token Option B: different Access Token Token Exchange AT AT AT AT AT’ AT’
28 © Hitachi, Ltd. 2021. All rights reserved. - Audience check is very important for this case. - Without Audience check, user's resources may be provided to malicious service. How to achieve JWT validation (east-west traffic) Another Service Malicious Service Client App may redirect access token to other services without user's consent AT AT must validate Audience to check this service is intended to return the response
29 © Hitachi, Ltd. 2021. All rights reserved. - As same in the case of north-south traffic, there are 2 methods, mTLS and OAuth MTLS. - Different in the case of north-south traffic, the requesting parties are limited, so mTLS may be enough. (OAuth MTLS may be over-engineered.) - We can add client certificate and key with proxy_ssl_certificate syntax and proxy_ssl_certificate_key syntax. How to achieve mTLS (east-west traffic) during TLS handshake presenting the client certificate presenting the server certificate verify client certificate using trusted CA certificates Proxy container Another Service
© Hitachi, Ltd. 2021. All rights reserved. Contents 30 1. What is zero-trust network? 2. How to achieve the underlying technology behind zero-trust network 3. Transition from traditional security boundary definition to per service/pod definition 4. Additional topic 1: How to achieve east-west traffic 5. Additional topic 2: How to resolve chokepoint issue of Policy Decision Point
31 © Hitachi, Ltd. 2021. All rights reserved. - As the number of API calls increases, Keycloak may become a chokepoint of this architecture, because Keycloak is accessed every time API calls. - In Zero Trust Architecture, NIST SP 800-207, Keycloak is PE (Policy Engine), and NGINX is PEP (Policy Enforcement Point) + PA (Policy Administrator). - From here, we consider how to reduce the load of PE. Where is the chokepoint? Client App PEP + PA Keycloak 3. Call API w/ Access Token (JWT) (present client certificate during TLS handshake) 2. Issue Access Token (Access Token includes hash of client certificate) 1. Delegate AuthN/AuthZ (present client certificate during TLS handshake) Token Introspection PE NGINX
32 © Hitachi, Ltd. 2021. All rights reserved. - Considering using Open Policy Agent (OPA), the defacto standard OSS of PE (Policy Engine).  Option A: cache token introspection responses  Option B: make OPA act as PE and Keycloak act as PIP (Policy Information Point) How to reduce the load of PE (Keycloak) Client App Keycloak 3. Call API w/ Access Token (JWT) (present client certificate during TLS handshake) 2. Issue Access Token (Access Token includes hash of client certificate) 1. Delegate AuthN/AuthZ (present client certificate during TLS handshake) Token Introspection NGINX OPA +
33 © Hitachi, Ltd. 2021. All rights reserved. - Caching token introspection responses, we can reduce the access frequency to Keycloak. - Even if the access token is revoked at Keycloak, it's not revoked at resource server immediately, so the access token lifespan should be proper short value. Option A: Cache token introspection responses Client App Keycloak 3. Call API w/ Access Token (JWT) (present client certificate during TLS handshake) 2. Issue Access Token (Access Token includes hash of client certificate) 1. Delegate AuthN/AuthZ (present client certificate during TLS handshake) NGINX OPA 4. Delegate JWT validation MongoDB 5. Check cache 7. Save result 6. Token Introspection (if cache miss)
34 © Hitachi, Ltd. 2021. All rights reserved. - OPA container becomes PE completely, and Keycloak becomes PIP, only provides information for decisions to grant access. Option B: Make OPA act as PE and Keycloak act as PIP Client App Keycloak 3. Call API w/ Access Token (JWT) (present client certificate during TLS handshake) 2. Issue Access Token (Access Token includes hash of client certificate) 1. Delegate AuthN/AuthZ (present client certificate during TLS handshake) I. Notify resource (User, Client, Key, …) and operation (Create, Update, Delete, …) NGINX OPA 4. Delegate JWT validation MongoDB 5. Check data II. Save data Converter OPA by using SPI, we can extend event listener feature to notify operation to converter
35 © Hitachi, Ltd. 2021. All rights reserved. - Option B is an ideal implementation, but it is expensive to implement. - Option A, on the other hand, has the security concern that access token revocation cannot be synchronized immediately, although the implementation cost is minimal. - A hybrid proposal may be the most acceptable implementation.  caches the results of token introspection  synchronizes only token revocation notifications How to reduce the load of PE (Keycloak) Option A: cache token introspection responses Option B: make OPA act as PE and Keycloak act as PIP need to prepare Converter No Yes implement SPI No Yes synchronize access token revocation immediately No Yes
36 © Hitachi, Ltd. 2021. All rights reserved. Summary • The underlying technology behind zero-trust network is JWT validation and mTLS.  OAuth MTLS (RFC 8705) is forwards-compatible with mTLS. • By using Keycloak and NGINX, we can achieve the underlying technology, and transit from traditional security boundary definition to per service/pod definition smoothly.  Not only north-south traffic but also east-west traffic can be covered. • By using OPA, we can reduce the load of Keycloak (PE).
37 © Hitachi, Ltd. 2021. All rights reserved. Trademarks • OpenID is a trademark or registered trademark of OpenID Foundation in the United States and other countries. • GitHub is a trademark or registered trademark of GitHub, Inc. in the United States and other countries. • Facebook is a registered trademark of Facebook, Inc. • Twitter is a registered trademark of Twitter, Inc. • The Kubernetes logo is a registered trademark of The Linux Foundation. • Red Hat, and 3scale are registered trademarks of Red Hat, Inc. in the United States and other countries. • NGINX is a trademark of F5 Networks, Inc. in the U.S. and in certain other countries. • Istio is a trademark or registered trademark of Google LLC. • Other brand names and product names used in this material are trademarks, registered trademarks, or trade names of their respective holders.
Lightweight Zero-trust Network Implementation and Transition with Keycloak and NGINX

More Related Content

PPTX
KeycloakでFAPIに対応した高セキュリティなAPIを公開する
byHitachi, Ltd. OSS Solution Center.
 
PDF
Implementing security requirements for banking API system using Open Source ...
byYuichi Nakamura
 
PPTX
Introducing NGINX App Protect (Japanese Webinar)
byNGINX, Inc.
 
PDF
OAuth / OpenID Connectを中心とするAPIセキュリティについて #yuzawaws
byTatsuo Kudo
 
PPTX
Keycloak入門
byHiroyuki Wada
 
PDF
#APIOps- Agile API Development powered by API Connect
bypramodvallanur
 
PPTX
Keycloakの全体像: 基本概念、ユースケース、そして最新の開発動向
byHitachi, Ltd. OSS Solution Center.
 
PDF
Developer Tutorial: WebAuthn for Web & FIDO2 for Android
byFIDO Alliance
 
KeycloakでFAPIに対応した高セキュリティなAPIを公開する
byHitachi, Ltd. OSS Solution Center.
 
Implementing security requirements for banking API system using Open Source ...
byYuichi Nakamura
 
Introducing NGINX App Protect (Japanese Webinar)
byNGINX, Inc.
 
OAuth / OpenID Connectを中心とするAPIセキュリティについて #yuzawaws
byTatsuo Kudo
 
Keycloak入門
byHiroyuki Wada
 
#APIOps- Agile API Development powered by API Connect
bypramodvallanur
 
Keycloakの全体像: 基本概念、ユースケース、そして最新の開発動向
byHitachi, Ltd. OSS Solution Center.
 
Developer Tutorial: WebAuthn for Web & FIDO2 for Android
byFIDO Alliance
 

What's hot

PDF
FAPI (Financial-grade API) and CIBA (Client Initiated Backchannel Authenticat...
byTatsuo Kudo
 
PPTX
Building secure applications with keycloak
byAbhishek Koserwal
 
PPTX
Draft: building secure applications with keycloak (oidc/jwt)
byAbhishek Koserwal
 
PDF
Secure and Integrated - Using IAM with Amazon MSK | Mitchell Henderson, AWS
byHostedbyConfluent
 
PPTX
最近のKeycloakのご紹介 ~クライアントポリシーとFAPI~
byHitachi, Ltd. OSS Solution Center.
 
PPTX
KeycloakでAPI認可に入門する
byHitachi, Ltd. OSS Solution Center.
 
PDF
SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014
byNov Matake
 
PDF
Keycloak拡張入門
byHiroyuki Wada
 
PDF
OpenID Connect入門
by土岐 孝平
 
PDF
[Cloud OnAir] Apigee でかんたん API 管理 2019年12月12日 放送
byGoogle Cloud Platform - Japan
 
PDF
GitOps with ArgoCD
byCloudOps2005
 
PPTX
User Management Life Cycle with Keycloak
byMuhammad Edwin
 
PPTX
Keycloakのステップアップ認証について
byHitachi, Ltd. OSS Solution Center.
 
PDF
Keycloak開発入門
byYuichi Nakamura
 
PDF
認証の課題とID連携の実装 〜ハンズオン〜
byMasaru Kurahayashi
 
PDF
Why API Ops is the Next Wave of DevOps
byJohn Musser
 
PDF
GitOps with Amazon EKS Anywhere by Dan Budris
byWeaveworks
 
PDF
Hashicorp Vault: Open Source Secrets Management at #OPEN18
byKangaroot
 
PDF
ArgoCD Meetup PPT final.pdf
byamanmakwana3
 
PDF
Apache NiFi Record Processing
byBryan Bende
 
FAPI (Financial-grade API) and CIBA (Client Initiated Backchannel Authenticat...
byTatsuo Kudo
 
Building secure applications with keycloak
byAbhishek Koserwal
 
Draft: building secure applications with keycloak (oidc/jwt)
byAbhishek Koserwal
 
Secure and Integrated - Using IAM with Amazon MSK | Mitchell Henderson, AWS
byHostedbyConfluent
 
最近のKeycloakのご紹介 ~クライアントポリシーとFAPI~
byHitachi, Ltd. OSS Solution Center.
 
KeycloakでAPI認可に入門する
byHitachi, Ltd. OSS Solution Center.
 
SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014
byNov Matake
 
Keycloak拡張入門
byHiroyuki Wada
 
OpenID Connect入門
by土岐 孝平
 
[Cloud OnAir] Apigee でかんたん API 管理 2019年12月12日 放送
byGoogle Cloud Platform - Japan
 
GitOps with ArgoCD
byCloudOps2005
 
User Management Life Cycle with Keycloak
byMuhammad Edwin
 
Keycloakのステップアップ認証について
byHitachi, Ltd. OSS Solution Center.
 
Keycloak開発入門
byYuichi Nakamura
 
認証の課題とID連携の実装 〜ハンズオン〜
byMasaru Kurahayashi
 
Why API Ops is the Next Wave of DevOps
byJohn Musser
 
GitOps with Amazon EKS Anywhere by Dan Budris
byWeaveworks
 
Hashicorp Vault: Open Source Secrets Management at #OPEN18
byKangaroot
 
ArgoCD Meetup PPT final.pdf
byamanmakwana3
 
Apache NiFi Record Processing
byBryan Bende
 

Similar to Lightweight Zero-trust Network Implementation and Transition with Keycloak and NGINX

PPTX
How Does a Workload Authenticate an API Request?: Implementing Transaction To...
byHitachi, Ltd. OSS Solution Center.
 
PDF
API Security In Cloud Native Era
byWSO2
 
PPTX
OAuth Well Played – Mods and Combos for the Cloud Native API Security Game - ...
byNordic APIs
 
PDF
apidays Paris 2022 - Securing APIs in Open Banking, Takashi Norimatsu, Hitachi
byapidays
 
PDF
#5 WSO2 Masterclassitalia - WSO2 Identity Server, un approccio OAUTH2
byProfesia Srl, Lynx Group
 
PPTX
API Security : Patterns and Practices
byPrabath Siriwardena
 
PPTX
Enterprise Access Control Patterns for Rest and Web APIs
byCA API Management
 
PDF
APIsecure 2023 - OAuth, OIDC and protecting third-party credentials, Ed Olson...
byapidays
 
PDF
Microservices Security Landscape
byPrabath Siriwardena
 
PPTX
Best Practices in Building an API Security Ecosystem
byPrabath Siriwardena
 
PDF
APIdays Paris 2019 : Financial-grade API (FAPI) Security Profile
byHitachi, Ltd. OSS Solution Center.
 
PDF
APIdays Paris 2019 - What are protected and secured by security requirements ...
byapidays
 
PPTX
What API Specifications and Tools Help Engineers to Construct a High-Security...
byHitachi, Ltd. OSS Solution Center.
 
PDF
[Workshop] API-driven Integration
byWSO2
 
PPTX
Implementing security and availability requirements for banking API system us...
byHitachi, Ltd. OSS Solution Center.
 
PDF
Understanding Identity in the World of Web APIs – Ronnie Mitra, API Architec...
byCA API Management
 
PDF
WSO2Con EU 2015: API Management Strategies and Best Practices
byWSO2
 
PDF
MuleSoft Meetup Dubai Anypoint security with api-led Connectivity
bysatyasekhar123
 
PPTX
Microservices Security Landscape
byPrabath Siriwardena
 
PPTX
Security Considerations for API Gateway Aggregation
byHitachi, Ltd. OSS Solution Center.
 
How Does a Workload Authenticate an API Request?: Implementing Transaction To...
byHitachi, Ltd. OSS Solution Center.
 
API Security In Cloud Native Era
byWSO2
 
OAuth Well Played – Mods and Combos for the Cloud Native API Security Game - ...
byNordic APIs
 
apidays Paris 2022 - Securing APIs in Open Banking, Takashi Norimatsu, Hitachi
byapidays
 
#5 WSO2 Masterclassitalia - WSO2 Identity Server, un approccio OAUTH2
byProfesia Srl, Lynx Group
 
API Security : Patterns and Practices
byPrabath Siriwardena
 
Enterprise Access Control Patterns for Rest and Web APIs
byCA API Management
 
APIsecure 2023 - OAuth, OIDC and protecting third-party credentials, Ed Olson...
byapidays
 
Microservices Security Landscape
byPrabath Siriwardena
 
Best Practices in Building an API Security Ecosystem
byPrabath Siriwardena
 
APIdays Paris 2019 : Financial-grade API (FAPI) Security Profile
byHitachi, Ltd. OSS Solution Center.
 
APIdays Paris 2019 - What are protected and secured by security requirements ...
byapidays
 
What API Specifications and Tools Help Engineers to Construct a High-Security...
byHitachi, Ltd. OSS Solution Center.
 
[Workshop] API-driven Integration
byWSO2
 
Implementing security and availability requirements for banking API system us...
byHitachi, Ltd. OSS Solution Center.
 
Understanding Identity in the World of Web APIs – Ronnie Mitra, API Architec...
byCA API Management
 
WSO2Con EU 2015: API Management Strategies and Best Practices
byWSO2
 
MuleSoft Meetup Dubai Anypoint security with api-led Connectivity
bysatyasekhar123
 
Microservices Security Landscape
byPrabath Siriwardena
 
Security Considerations for API Gateway Aggregation
byHitachi, Ltd. OSS Solution Center.
 

More from Hitachi, Ltd. OSS Solution Center.

PPTX
Securing Model Context Protocol with Keycloak: AuthN/AuthZ for MCP Servers
byHitachi, Ltd. OSS Solution Center.
 
PDF
API認可を支えるKeycloakの基本と設計の考え方 ～ OAuth/OIDCによるAPI保護のベストプラクティス ～
byHitachi, Ltd. OSS Solution Center.
 
PPTX
Hitachi’s Keycloak Journey - Evolution of Business and Community
byHitachi, Ltd. OSS Solution Center.
 
PPTX
Mastering Authorization: Integrating Authentication and Authorization Data in...
byHitachi, Ltd. OSS Solution Center.
 
PDF
KubeCon + CloudNativeCon North America セキュリティ周りrecap
byHitachi, Ltd. OSS Solution Center.
 
PDF
Let’s Join Cloud Native Computing Foundation TAG Security APAC!
byHitachi, Ltd. OSS Solution Center.
 
PDF
Exploring Best Practice for Implementing Authn and Authz in a Cloud-Native En...
byHitachi, Ltd. OSS Solution Center.
 
PPTX
Exploring Best Practices for Implementing Authn and Authz in a Cloud-Native E...
byHitachi, Ltd. OSS Solution Center.
 
PPTX
CloudNativeSecurityCon North America 2024 Overview
byHitachi, Ltd. OSS Solution Center.
 
PDF
Authentication and Authorization of The Latest Keycloak
byHitachi, Ltd. OSS Solution Center.
 
PDF
Guide of authentication and authorization for cloud native applications with ...
byHitachi, Ltd. OSS Solution Center.
 
PDF
KeycloakのCNCF incubating project入りまでのアップストリーム活動の歩み
byHitachi, Ltd. OSS Solution Center.
 
PDF
KubeCon NA 2023 Recap: Challenge to Implementing “Scalable” Authorization wit...
byHitachi, Ltd. OSS Solution Center.
 
PPTX
パスキーでリードする: NGINXとKeycloakによる効率的な認証・認可
byHitachi, Ltd. OSS Solution Center.
 
PPTX
Challenge to Implementing "Scalable" Authorization with Keycloak
byHitachi, Ltd. OSS Solution Center.
 
PDF
KubeConRecap_nakamura.pdf
byHitachi, Ltd. OSS Solution Center.
 
PPTX
NGINXでの認可について考える
byHitachi, Ltd. OSS Solution Center.
 
PDF
IDガバナンス&管理の基礎
byHitachi, Ltd. OSS Solution Center.
 
PPTX
NGINXをBFF (Backend for Frontend)として利用した話
byHitachi, Ltd. OSS Solution Center.
 
PPTX
Why Assertion-based Access Token is preferred to Handle-based one?
byHitachi, Ltd. OSS Solution Center.
 
Securing Model Context Protocol with Keycloak: AuthN/AuthZ for MCP Servers
byHitachi, Ltd. OSS Solution Center.
 
API認可を支えるKeycloakの基本と設計の考え方 ～ OAuth/OIDCによるAPI保護のベストプラクティス ～
byHitachi, Ltd. OSS Solution Center.
 
Hitachi’s Keycloak Journey - Evolution of Business and Community
byHitachi, Ltd. OSS Solution Center.
 
Mastering Authorization: Integrating Authentication and Authorization Data in...
byHitachi, Ltd. OSS Solution Center.
 
KubeCon + CloudNativeCon North America セキュリティ周りrecap
byHitachi, Ltd. OSS Solution Center.
 
Let’s Join Cloud Native Computing Foundation TAG Security APAC!
byHitachi, Ltd. OSS Solution Center.
 
Exploring Best Practice for Implementing Authn and Authz in a Cloud-Native En...
byHitachi, Ltd. OSS Solution Center.
 
Exploring Best Practices for Implementing Authn and Authz in a Cloud-Native E...
byHitachi, Ltd. OSS Solution Center.
 
CloudNativeSecurityCon North America 2024 Overview
byHitachi, Ltd. OSS Solution Center.
 
Authentication and Authorization of The Latest Keycloak
byHitachi, Ltd. OSS Solution Center.
 
Guide of authentication and authorization for cloud native applications with ...
byHitachi, Ltd. OSS Solution Center.
 
KeycloakのCNCF incubating project入りまでのアップストリーム活動の歩み
byHitachi, Ltd. OSS Solution Center.
 
KubeCon NA 2023 Recap: Challenge to Implementing “Scalable” Authorization wit...
byHitachi, Ltd. OSS Solution Center.
 
パスキーでリードする: NGINXとKeycloakによる効率的な認証・認可
byHitachi, Ltd. OSS Solution Center.
 
Challenge to Implementing "Scalable" Authorization with Keycloak
byHitachi, Ltd. OSS Solution Center.
 
KubeConRecap_nakamura.pdf
byHitachi, Ltd. OSS Solution Center.
 
NGINXでの認可について考える
byHitachi, Ltd. OSS Solution Center.
 
IDガバナンス&管理の基礎
byHitachi, Ltd. OSS Solution Center.
 
NGINXをBFF (Backend for Frontend)として利用した話
byHitachi, Ltd. OSS Solution Center.
 
Why Assertion-based Access Token is preferred to Handle-based one?
byHitachi, Ltd. OSS Solution Center.
 

Recently uploaded

PPTX
CLOUD STUDY JAM 2025 GOOGLE DEVELOPER GROUPS ON CAMPUS NSEC
byasutoshkumar560
 
PPTX
UiPath Automation Suite Installation (Hands-On) [2/3]
bysuhanisingh58689
 
PPTX
WUG-DMV: Workfront Wizards: Tips & Tricks Exchange (Sept 2025)
byWUG-DC MARYLAND VIRGINIA
 
PDF
Towards efficient vision representation and coding standards for superior emb...
byTouradj Ebrahimi
 
PPTX
Google Cloud Quest : An introductory training session on how to solve Google ...
byrajashreeborah705
 
PDF
Session 3 - Specialized AI Associate Series: AI Powered Automation through sp...
byDianaGray10
 
PPTX
Momentum Developer Con 2025 - How To Better Developer Estimates
byBrian McKeiver
 
PDF
A SEA of Energy Efficiency Opportunities!
byMemoori
 
PDF
Dream Companion Reviews, Pricing, & Alternatives
byDream Companion
 
PDF
Ask Me Anything About AI Assist: Practical Answers for Real Workflows
bySafe Software
 
PDF
The invisible key: Securing the new attack vector of OAuth tokens
byGianluca Varisco
 
PDF
Session 1 - Agentic Automation Building the Enterprise Agent of Tomorrow
byDianaGray10
 
PDF
A business case for open source: From lock-in to value.pdf
byMindtrek
 
PPTX
sap 2016-09-14_PP_MRPType_VB_Blogged.pptx
byAmira Jemi
 
PPTX
Open Source business is of strategic importance to the EUpptx
byMindtrek
 
PPTX
Cloud Metrics: The Cost-Value Equation (All Things Open 2025)
byEric D. Schabell
 
PDF
Unit 3 DS - Distributed Data Storage and Retrieval - PowerPoint Content.pdf
byayesha butalia
 
PPTX
Behind the Scenes at Netflix: Distributed Systems & NoSQL Architecture.
byayesha butalia
 
PDF
Artificial Intelligence and YOU - Thinking Thoughtfully about AI
byMicah Melling
 
PDF
Optimizing a Global Training Strategy: An LKQ Corporation Case Study
byRustici Software
 
CLOUD STUDY JAM 2025 GOOGLE DEVELOPER GROUPS ON CAMPUS NSEC
byasutoshkumar560
 
UiPath Automation Suite Installation (Hands-On) [2/3]
bysuhanisingh58689
 
WUG-DMV: Workfront Wizards: Tips & Tricks Exchange (Sept 2025)
byWUG-DC MARYLAND VIRGINIA
 
Towards efficient vision representation and coding standards for superior emb...
byTouradj Ebrahimi
 
Google Cloud Quest : An introductory training session on how to solve Google ...
byrajashreeborah705
 
Session 3 - Specialized AI Associate Series: AI Powered Automation through sp...
byDianaGray10
 
Momentum Developer Con 2025 - How To Better Developer Estimates
byBrian McKeiver
 
A SEA of Energy Efficiency Opportunities!
byMemoori
 
Dream Companion Reviews, Pricing, & Alternatives
byDream Companion
 
Ask Me Anything About AI Assist: Practical Answers for Real Workflows
bySafe Software
 
The invisible key: Securing the new attack vector of OAuth tokens
byGianluca Varisco
 
Session 1 - Agentic Automation Building the Enterprise Agent of Tomorrow
byDianaGray10
 
A business case for open source: From lock-in to value.pdf
byMindtrek
 
sap 2016-09-14_PP_MRPType_VB_Blogged.pptx
byAmira Jemi
 
Open Source business is of strategic importance to the EUpptx
byMindtrek
 
Cloud Metrics: The Cost-Value Equation (All Things Open 2025)
byEric D. Schabell
 
Unit 3 DS - Distributed Data Storage and Retrieval - PowerPoint Content.pdf
byayesha butalia
 
Behind the Scenes at Netflix: Distributed Systems & NoSQL Architecture.
byayesha butalia
 
Artificial Intelligence and YOU - Thinking Thoughtfully about AI
byMicah Melling
 
Optimizing a Global Training Strategy: An LKQ Corporation Case Study
byRustici Software
 
In this document
Powered by AI

Introduction to a zero-trust network model for securing APIs in microservices, highlighting challenges in traditional networks and proposing a lightweight implementation.Overview of zero-trust network principles, including JWT validation, mutual TLS, and OAuth MTLS technology for securing API calls.

Overview of zero-trust network principles, including JWT validation, mutual TLS, and OAuth MTLS technology for securing API calls.

Utilization of Keycloak as an authorization server and NGINX as an API gateway for implementing zero-trust security, ensuring robust API security processes.

Steps to transition security boundaries from traditional definitions to service and pod levels within a microservice architecture.

Steps to transition security boundaries from traditional definitions to service and pod levels within a microservice architecture.

Techniques for alleviating pressure on Keycloak by leveraging Open Policy Agent (OPA) for efficient policy management while ensuring security compliance.

Lightweight Zero-trust Network Implementation and Transition with Keycloak and NGINX

  • 1.
    © Hitachi, Ltd.2021. All rights reserved. Lightweight Zero-trust Network Implementation and Transition with Keycloak and NGINX Open Source Summit Japan 2021 Hitachi, Ltd. OSS Solution Center Yoshiyuki Tabata
  • 2.
    1 © Hitachi, Ltd.2021. All rights reserved. About the speaker • Consultant of API system  For example, building a high-security banking API system. • Contributor of 3scale (OSS of API Management)  Developed features around security and access control.  “Edge Limiting”, “RBAC”, “OAuth MTLS”, … • Contributor of Keycloak (OSS of Identity Management)  Developed features required for API use cases based on OAuth/OIDC.  “Token Revocation”, “Refresh token setting per client”, … Yoshiyuki Tabata  Software Engineer  OSS Solution Center, Hitachi, Ltd.  GitHub: @y-tabata
  • 3.
    2 © Hitachi, Ltd.2021. All rights reserved. Session Overview (1/3) API Gateway Authorization Server Client App Resource Server Resource Server - In the traditional API system, the security boundary between the public network and the private network is clear, so we only needed to focus on it. Security Boundary Expose API! Call API Delegate Authentication and Authorization Build API system by following OAuth 2.0 the de facto standard of API security private network public network
  • 4.
    3 © Hitachi, Ltd.2021. All rights reserved. - In the world of microservice, various services expose their APIs, it's much difficult to define a security boundary between the public network and the private network. Session Overview (2/3) Authorization Server Client App Call API Delegate Authentication and Authorization Expose API! Expose API! Expose API! Expose API! Expose API! Expose API! Expose API! Call API Call API Call API Call API Call API Call API Call API Build API system by following OAuth 2.0 the de facto standard of API security
  • 5.
    4 © Hitachi, Ltd.2021. All rights reserved. zero-trust network - So we need to consider introducing "zero-trust network" to secure each service independently (per service/pod). Session Overview (3/3) Client App Call API Call API Call API Call API Call API Call API security boundary security boundary security boundary security boundary security boundary security boundary security boundary security boundary We propose Lightweight zero-trust network implementation typical way to achieve zero-trust network is with service mesh, but  it needs rich resources for its rich features  it affects the architecture a lot
  • 6.
    © Hitachi, Ltd.2021. All rights reserved. Contents 5 1. What is zero-trust network? 2. How to achieve the underlying technology behind zero-trust network 3. Transition from traditional security boundary definition to per service/pod definition 4. Additional topic 1: How to achieve east-west traffic 5. Additional topic 2: How to resolve chokepoint issue of Policy Decision Point
  • 7.
    © Hitachi, Ltd.2021. All rights reserved. Contents 6 1. What is zero-trust network? 2. How to achieve the underlying technology behind zero-trust network 3. Transition from traditional security boundary definition to per service/pod definition 4. Additional topic 1: How to achieve east-west traffic 5. Additional topic 2: How to resolve chokepoint issue of Policy Decision Point
  • 8.
    7 © Hitachi, Ltd.2021. All rights reserved. - To treat the system internal network the same as the public network. - The underlying technology behind zero-trust network is  JWT validation  mutual TLS What is zero-trust network? - Underlying technology Source: Istio (https://istio.io/latest/docs/concepts/security/) Istio only requires mTLS in the system internal network, but JWT validation is said to be also needed among API security professionals. Require mTLS and JWT validation in the public network.
  • 9.
    8 © Hitachi, Ltd.2021. All rights reserved. - In the context of OAuth 2.0, what the JWT (presented during an API call) means is OAuth 2.0 Access Token. - Access token is issued by an authorization server as representing an authorization. Underlying technology 1 - JWT validation API Gateway Authorization Server Client App 3. Call API w/ Access Token (JWT) 2. Issue Access Token after Authentication and Authorization Typical OAuth 2.0 authorization code flow 1. Delegate Authentication and Authorization - Generally, validate JWT with authorization server, i.e. following Token Introspection: RFC 7662. - What validate:  Signature: check the JWT is not tampered  Expiry: check the JWT is not expired  Scope: check the client was authorized to call the API  Audience: check the resource server (API GW) is intended to return the response Token Introspection
  • 10.
    9 © Hitachi, Ltd.2021. All rights reserved. during TLS handshake - As the same as authenticating the server using a server certificate, authenticate the client using a client certificate. Underlying technology 2 - mutual TLS API Gateway Client App presenting the client certificate presenting the server certificate verify client certificate using trusted CA certificates
  • 11.
    10 © Hitachi, Ltd.2021. All rights reserved. - In the context of OAuth 2.0, OAuth 2.0 Mutual-TLS Client Certificate-Bound Access Tokens (hereinafter OAuth MTLS) is defined in RFC 8705. - OAuth MTLS prevents access token theft. Underlying technology 2’ - OAuth MTLS (RFC 8705) API Gateway Client App - verify client certificate using trusted CA certificates - verify the hash of client certificate equals one in the Access Token Authorization Server 3. Call API w/ Access Token (JWT) (present client certificate during TLS handshake) 2. Issue Access Token (Access Token includes hash of client certificate) 1. Delegate AuthN/AuthZ (present client certificate during TLS handshake)
  • 12.
    11 © Hitachi, Ltd.2021. All rights reserved. - Extending token introspection, resource server can delegate client certificate check to authorization server. Underlying technology 2’ - OAuth MTLS (RFC 8705) API Gateway Client App delegate client certificate check to authorization server Authorization Server 3. Call API w/ Access Token (JWT) (present client certificate during TLS handshake) 2. Issue Access Token (Access Token includes hash of client certificate) 1. Delegate AuthN/AuthZ (present client certificate during TLS handshake) mTLS OAuth MTLS manage trusted CA certificates Both authorization server and resource server (API GW) Authorization server only prevents access token theft No Yes If you publish your API to a large number of unspecified clients on the public network, OAuth MTLS may suitable.
  • 13.
    © Hitachi, Ltd.2021. All rights reserved. Contents 12 1. What is zero-trust network? 2. How to achieve the underlying technology behind zero-trust network 3. Transition from traditional security boundary definition to per service/pod definition 4. Additional topic 1: How to achieve east-west traffic 5. Additional topic 2: How to resolve chokepoint issue of Policy Decision Point
  • 14.
    13 © Hitachi, Ltd.2021. All rights reserved. - We use Keycloak as Authorization Server, NGINX as API Gateway. What OSS do we use? NGINX (API Gateway) Keycloak (Authorization Server) Client App 3. Call API w/ Access Token (JWT) 2. Issue Access Token after Authentication and Authorization 1. Delegate Authentication and Authorization Token Introspection
  • 15.
    14 © Hitachi, Ltd.2021. All rights reserved. - Keycloak is an identity management OSS. - Keycloak provides OAuth 2.0 authorization server features. What is Keycloak? Major features  Supports OAuth 2.0 / OpenID Connect and SAML  Can be linked with LDAP and Active Directory  Also supports social login with such as GitHub ID management and authentication social login (Identity Brokering) ID federation corresponding to major standards (Including OAuth 2.0 authorization server) Keycloak LDAP Active Directory RDB OpenID Connect SAML GitHub Twitter Facebook
  • 16.
    15 © Hitachi, Ltd.2021. All rights reserved. - Keycloak supports Token Introspection as a standard feature. - NGINX supports ngx_http_auth_request_module module which implements client authorization based on the result of a subrequest. If the subrequest returns a 2xx response code, access is allowed. If it returns 401 or 403, access is denied with the corresponding error code. How to achieve JWT validation NGINX Keycloak Client App 3. Call API w/ Access Token (JWT) 2. Issue Access Token after Authentication and Authorization 1. Delegate Authentication and Authorization NGINX delegates JWT validation to Keycloak  send introspection request to Keycloak's token introspection endpoint  proxy to resource server if access token is active  deny access if access token is not active Token Introspection
  • 17.
    16 © Hitachi, Ltd.2021. All rights reserved. - NGINX supports ssl_verify_client syntax which enables verification of client certificates. Trusted CA certificates are specified in ssl_client_certificate syntax. How to achieve mTLS during TLS handshake NGINX Client App presenting the client certificate presenting the server certificate verify client certificate using trusted CA certificates
  • 18.
    17 © Hitachi, Ltd.2021. All rights reserved. - NGINX supports optional_no_ca parameter in ssl_verify_client syntax, which requests client certificate but does not require it to be signed by a trusted CA certificate. This is intended for use in cases when a service that is external to NGINX performs the actual certificate verification. - $ssl_client_escaped_cert variable returns client certificate in the PEM format for an established SSL connection. How to achieve OAuth MTLS NGINX Client App send access token and client certificate to token introspection endpoint Keycloak 3. Call API w/ Access Token (JWT) (present client certificate during TLS handshake) 2. Issue Access Token (Access Token includes hash of client certificate) 1. Delegate AuthN/AuthZ (present client certificate during TLS handshake) Token Introspection by using SPI, we can extend token introspection to check client certificate at Keycloak
  • 19.
    © Hitachi, Ltd.2021. All rights reserved. Contents 18 1. What is zero-trust network? 2. How to achieve the underlying technology behind zero-trust network 3. Transition from traditional security boundary definition to per service/pod definition 4. Additional topic 1: How to achieve east-west traffic 5. Additional topic 2: How to resolve chokepoint issue of Policy Decision Point
  • 20.
    19 © Hitachi, Ltd.2021. All rights reserved. - So far, we explained how to use Keycloak and NGINX to achieve the underlying technology behind zero-trust network. - From here, we make the grain size of security boundary finer. Security boundary transition scenario NGINX Keycloak Client App Resource Server Resource Server Security Boundary Expose API! Call API Delegate Authentication and Authorization private network public network
  • 21.
    20 © Hitachi, Ltd.2021. All rights reserved. - First of all, lifting the existing system to the world of containers. - Compared to cloud services, in NGINX, this API Gateway lifting is very easy because we can reuse the NGINX conf file, for example, using server-snippet and location-snippet annotations, or using custom resources named VirtualServer. Step 1: Change API Gateway to NGINX Ingress Controller NGINX Ingress Controller Keycloak Client App Resource Server Resource Server Security Boundary Call API Delegate Authentication and Authorization private network public network
  • 22.
    21 © Hitachi, Ltd.2021. All rights reserved. Security Boundary Security Boundary - This step is useful if the resource server's service takes a little time to be modified. - Again we can reuse the NGINX conf file. - To pass through client certificates at NGINX Ingress Controller, we use custom resources named TransportServer to configure stream context. Step 2: Shift security boundary to per service NGINX Ingress Controller Keycloak Client App Proxy Service Proxy Service Call API Delegate Authentication and Authorization Resource Server Resource Server
  • 23.
    22 © Hitachi, Ltd.2021. All rights reserved. Security Boundary Security Boundary - Achieve so-called sidecar. - Again we can reuse the NGINX conf file and we can reuse TransportServer setting too. - API call is first sent to proxy container, and if all checks are passed, proxy to resource server container. Step 3: Shift security boundary to per pod NGINX Ingress Controller Keycloak Client App Call API Delegate Authentication and Authorization Resource Server Resource Server container Proxy container
  • 24.
    © Hitachi, Ltd.2021. All rights reserved. Contents 23 1. What is zero-trust network? 2. How to achieve the underlying technology behind zero-trust network 3. Transition from traditional security boundary definition to per service/pod definition 4. Additional topic 1: How to achieve east-west traffic 5. Additional topic 2: How to resolve chokepoint issue of Policy Decision Point
  • 25.
    24 © Hitachi, Ltd.2021. All rights reserved. - So far, we targeted north-south traffic, i.e. traffic from client to resource server, from external to internal. How to achieve east-west traffic NGINX Ingress Controller Keycloak Client App Call API Delegate Authentication and Authorization Resource Server Resource Server container Proxy container
  • 26.
    25 © Hitachi, Ltd.2021. All rights reserved. - So far, we targeted north-south traffic, i.e. traffic from client to resource server, from external to internal. - How to achieve east-west traffic, i.e. traffic from internal to internal? - For example, when the resource server wants to get resources from other services. How to achieve east-west traffic NGINX Ingress Controller Keycloak Client App Call API Delegate Authentication and Authorization Another Service Resource Server container Proxy container ? Resource Server
  • 27.
    26 © Hitachi, Ltd.2021. All rights reserved. - So far, we targeted north-south traffic, i.e. traffic from client to resource server, from external to internal. - How to achieve east-west traffic, i.e. traffic from internal to internal? - For example, when the resource server wants to get resources from other services. - In this case, resource server container should send a request using again the proxy container. How to achieve east-west traffic NGINX Ingress Controller Keycloak Client App Call API Delegate Authentication and Authorization Another Service Resource Server container Proxy container Resource Server
  • 28.
    27 © Hitachi, Ltd.2021. All rights reserved. - To validate JWT, the proxy container must send JWT.  Option A: send the same access token which client sent  Option B: send the different access token getting from authorization server by following OAuth 2.0 Token Exchange: RFC 8693 - Both options, need to get user's consent. How to achieve JWT validation (east-west traffic) Proxy container Another Service Resource Server container Keycloak Option A: same Access Token Option B: different Access Token Token Exchange AT AT AT AT AT’ AT’
  • 29.
    28 © Hitachi, Ltd.2021. All rights reserved. - Audience check is very important for this case. - Without Audience check, user's resources may be provided to malicious service. How to achieve JWT validation (east-west traffic) Another Service Malicious Service Client App may redirect access token to other services without user's consent AT AT must validate Audience to check this service is intended to return the response
  • 30.
    29 © Hitachi, Ltd.2021. All rights reserved. - As same in the case of north-south traffic, there are 2 methods, mTLS and OAuth MTLS. - Different in the case of north-south traffic, the requesting parties are limited, so mTLS may be enough. (OAuth MTLS may be over-engineered.) - We can add client certificate and key with proxy_ssl_certificate syntax and proxy_ssl_certificate_key syntax. How to achieve mTLS (east-west traffic) during TLS handshake presenting the client certificate presenting the server certificate verify client certificate using trusted CA certificates Proxy container Another Service
  • 31.
    © Hitachi, Ltd.2021. All rights reserved. Contents 30 1. What is zero-trust network? 2. How to achieve the underlying technology behind zero-trust network 3. Transition from traditional security boundary definition to per service/pod definition 4. Additional topic 1: How to achieve east-west traffic 5. Additional topic 2: How to resolve chokepoint issue of Policy Decision Point
  • 32.
    31 © Hitachi, Ltd.2021. All rights reserved. - As the number of API calls increases, Keycloak may become a chokepoint of this architecture, because Keycloak is accessed every time API calls. - In Zero Trust Architecture, NIST SP 800-207, Keycloak is PE (Policy Engine), and NGINX is PEP (Policy Enforcement Point) + PA (Policy Administrator). - From here, we consider how to reduce the load of PE. Where is the chokepoint? Client App PEP + PA Keycloak 3. Call API w/ Access Token (JWT) (present client certificate during TLS handshake) 2. Issue Access Token (Access Token includes hash of client certificate) 1. Delegate AuthN/AuthZ (present client certificate during TLS handshake) Token Introspection PE NGINX
  • 33.
    32 © Hitachi, Ltd.2021. All rights reserved. - Considering using Open Policy Agent (OPA), the defacto standard OSS of PE (Policy Engine).  Option A: cache token introspection responses  Option B: make OPA act as PE and Keycloak act as PIP (Policy Information Point) How to reduce the load of PE (Keycloak) Client App Keycloak 3. Call API w/ Access Token (JWT) (present client certificate during TLS handshake) 2. Issue Access Token (Access Token includes hash of client certificate) 1. Delegate AuthN/AuthZ (present client certificate during TLS handshake) Token Introspection NGINX OPA +
  • 34.
    33 © Hitachi, Ltd.2021. All rights reserved. - Caching token introspection responses, we can reduce the access frequency to Keycloak. - Even if the access token is revoked at Keycloak, it's not revoked at resource server immediately, so the access token lifespan should be proper short value. Option A: Cache token introspection responses Client App Keycloak 3. Call API w/ Access Token (JWT) (present client certificate during TLS handshake) 2. Issue Access Token (Access Token includes hash of client certificate) 1. Delegate AuthN/AuthZ (present client certificate during TLS handshake) NGINX OPA 4. Delegate JWT validation MongoDB 5. Check cache 7. Save result 6. Token Introspection (if cache miss)
  • 35.
    34 © Hitachi, Ltd.2021. All rights reserved. - OPA container becomes PE completely, and Keycloak becomes PIP, only provides information for decisions to grant access. Option B: Make OPA act as PE and Keycloak act as PIP Client App Keycloak 3. Call API w/ Access Token (JWT) (present client certificate during TLS handshake) 2. Issue Access Token (Access Token includes hash of client certificate) 1. Delegate AuthN/AuthZ (present client certificate during TLS handshake) I. Notify resource (User, Client, Key, …) and operation (Create, Update, Delete, …) NGINX OPA 4. Delegate JWT validation MongoDB 5. Check data II. Save data Converter OPA by using SPI, we can extend event listener feature to notify operation to converter
  • 36.
    35 © Hitachi, Ltd.2021. All rights reserved. - Option B is an ideal implementation, but it is expensive to implement. - Option A, on the other hand, has the security concern that access token revocation cannot be synchronized immediately, although the implementation cost is minimal. - A hybrid proposal may be the most acceptable implementation.  caches the results of token introspection  synchronizes only token revocation notifications How to reduce the load of PE (Keycloak) Option A: cache token introspection responses Option B: make OPA act as PE and Keycloak act as PIP need to prepare Converter No Yes implement SPI No Yes synchronize access token revocation immediately No Yes
  • 37.
    36 © Hitachi, Ltd.2021. All rights reserved. Summary • The underlying technology behind zero-trust network is JWT validation and mTLS.  OAuth MTLS (RFC 8705) is forwards-compatible with mTLS. • By using Keycloak and NGINX, we can achieve the underlying technology, and transit from traditional security boundary definition to per service/pod definition smoothly.  Not only north-south traffic but also east-west traffic can be covered. • By using OPA, we can reduce the load of Keycloak (PE).
  • 38.
    37 © Hitachi, Ltd.2021. All rights reserved. Trademarks • OpenID is a trademark or registered trademark of OpenID Foundation in the United States and other countries. • GitHub is a trademark or registered trademark of GitHub, Inc. in the United States and other countries. • Facebook is a registered trademark of Facebook, Inc. • Twitter is a registered trademark of Twitter, Inc. • The Kubernetes logo is a registered trademark of The Linux Foundation. • Red Hat, and 3scale are registered trademarks of Red Hat, Inc. in the United States and other countries. • NGINX is a trademark of F5 Networks, Inc. in the U.S. and in certain other countries. • Istio is a trademark or registered trademark of Google LLC. • Other brand names and product names used in this material are trademarks, registered trademarks, or trade names of their respective holders.