Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

 Design Overview

Knox can be added as an external authorizer by following istio’s External Authorizer guide. The diagram above shows a high level design.   

  • User makes a request to access a k8s service 
  • K8s ingress is configured to intercept requests from outside the cluster 
  • Ingress controller will forward all unauthenticated requests to Knox for authentication/authorization
  • In case of failure, Knox will respond with 401 (Authentication failure)  or 403 (Authorization failure)
  • In case of success, Knox will forward the request to the intended k8s service
    • Optionally, Knox can add custom headers [TODO File JIRA]
    • Knox can forward configured headers to the downstream service (configured at ingress, this is a white list of headers) 

...

Topology example is included in Appendix (UC1 Topology example)

...


UC2: SSO

For interactive browser access to k8s services KnoxSSO can be used. To enable SSO, ingress needs to check for knox-issued cookie (hadoop-jwt) if the cookie is not present then ingress will redirect the request to Knox SSO topology. This topology asserts the user's identity by issuing a redirect to a configured SAML provider. Upon success, Knox adds a signed JWT token and redirects the browser back to the original requested endpoint.


...



UC3: Websocket Applications

Initial POC testing with Tornado - Demo Websockets App suggests that UIs with websocket work with Knox as an external authorizer. This is needed for applications such as Zeppelin. 

...


UC4: gRPC

gRPC protocol is not yet supported.

...


UC5: Intracluster / Intercluster

Apache Knox can also be used for service to service or cluster to communication.

...