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 licence 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:
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.
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 documentation shows how it is possible to log this information into an object store of choice.