Security

ModelOps is a fully cloud native application, and as such it leverages Kubernetes as much as possible to ensure secure operations.

All ModelOps servers are exposed as a Kubernetes Service. These services execute in a configurable Namespace, which can be optionally isolated using Network Policies.

Authentication and authorization are provided by the ModelOps Server, and optionally, the LiveView Server providing the aggregated view of the real-time metrics (see Metrics).

An Ingress is used to add TLS private key, certificate management, and proxy services to the ModelOps Kubernetes cluster.

TLS private keys and certificate management is managed by an Ingress. TLS connections are terminated at the ingress; all internal cluster communication uses non-TLS communication.

Ingress rules are used to support request routing to either the ModelOps or Real-Time Metrics server based on the REST API path. The request routing provides a single network address for ModelOps UI users, while avoiding cross-origin resource sharing (CORS) issues with the ModelOps UI plugin support for real-time metric visualization.

Single sign-on is supported via an external authorization server conforming to OAuth2. This provides both authorization (eg username and password) and roles (eg administrator).

The implications of this security architecture are that ModelOps does not need to maintain any user passwords, TLS private keys, or certificates; improving overall system security.

Security Architecture

Login Sessions

Login sessions are established to ModelOps servers that provide authorization. These ModelOps servers provide access control specific to the resources they manage:

  • ModelOps Server - projects, scoring pipelines, scoring flows, models, etc.
  • Scheduling Server - scheduled jobs
  • Scoring Server - optional model runner specific authorization
  • Data Channels (sources and sinks) - data resources

The diagram below shows login session establishment and termination.

Login Sessions

OAuth2 Authentication

An external OAuth2 authentication server must be used to both authenticate users and provide user roles. This is supported via a oauth2-proxy reverse proxy.

When the external authentication server authenticates a user, a JWT token is returned.

The diagram below shows Oauth2 based login and logout:

Oauth2