Seldon security architecture
This page contains an outline of the security processes, policies, capabilities and architectural considerations of the Seldon platform.
Core Applications
The Seldon product is self-hosted, which means that it is hosted on the customer’s premises, on a customer provisioned and maintained Kubernetes cluster. This allows for the customer to introduce any relevant policies to their infrastructure as well as the data that goes through the platform.
Data
Data does not leave the premises, and is all hosted on customer premises and customer managed infrastructure. These are the following types of data that Seldon product relies on.
Model artifacts and inference servers
Customers' ML models are usually serialized as binary artifacts that can be stored on popular cloud storage solutions, for example Google Cloud Store (GCS) or Amazon’s S3. These are a great choice especially if customers use one of these cloud providers to host their Kubernetes cluster. Seldon is also compatible with in-cluster MinIO S3 storage.
The inference servers’ runtime environment is defined by their Docker image. Official Seldon images are published on the Docker Hub but customers have the option to mirror these to internal image registries to introduce any internal security policies required.
Metrics, requests and audit logs, and model metadata
The Seldon products provide the ability to integrate to a broad range of data-storage services, below is a summary of the data and function of each:
Prometheus: in-cluster Prometheus instance is used to collect runtime metrics like CPU/memory usage, number of requests, their latency, as well as usage metrics for license validation purposes. An in-cluster instance should be sufficient for most use-cases.
Elasticsearch: an Elasticsearch instance is required to store request logs and enable advance monitoring features. Seldon recommends choosing a managed solution appropriate for customers cloud providers.
PostgreSQL: a Postgres DB instance is required for the Model Catalogue features. Seldon recommends choosing a managed solution appropriate for customers cloud providers.
S3 compatible object store: besides being used to host the customers' model artifacts, a cloud object store enables audit logging and batch processing features. A managed solution is recommended.
Security Policy
Our internal security policy includes processes that allow us to identify and address common vulnerabilities and security exposures. We have internal processes that ensure the following:
All the images from Seldon software (including Seldon Core and Seldon Enterprise Platform) are scanned with security tools.
The scanning tool used leverages Snyk.
Common Vulnerabilities Exploits (CVEs) that have fixes are flagged and addressed.
Architectural diagram
The above diagram represents the architecture of the Seldon product and associated ecosystem. All components are self-hosted on customers’ infrastructure, and any of the ecosystem components are configured by the platform teams according to internal policies and requirements.
Traffic is controlled by a single ingress provider instance, such as Nginx or Istio, which should support TLS. In the case of an Istio IngressGateway, this can also be configured by customer platform teams to include JWT token validation integrated with customers’ OIDC provider.
The Prometheus in-cluster instance is not expected to be exposed externally, as per the default documentation outlined in the production installation guide.
The PostgreSQL and Elasticsearch databases can be encrypted at rest. It is customers’ responsibility to secure these databases and implement appropriate backup strategies. Seldon recommends using a managed solution appropriate for each cloud provider.
Authentication and Authorization to Seldon Enterprise Platform
Seldon integrates with OIDC-compatible providers like Keycloak or Azure AD in order to provide app level authentication of the Seldon Enterprise Platform itself. The app level authentication of Seldon Enterprise Platform UI leverages SSO through auth code flow. For the Seldon Enterprise Platform API, customers can use authorisation code, client credentials, or password grant flow of their OIDC providers to authenticate and authorize the API client. This can be simplified using the Seldon Enterprise Platform Python SDK, which is often used for programmatic interaction with the APIs from CI pipelines or other applications and services.
Audit logging
For auditability purposes it is possible to log every single request and response to the Seldon Enterprise Platform API to a specific location through fluentd. The audit documentation shows how it is possible to log this information into an object store of choice.
Last updated
