Security
Seldon can be run with secure control plane and data plane operations. There are three areas of concern:
The various communication points between services are shown in the diagram below:

Control Plane
TLS control plane activation is switched on and off via the environment variable: CONTROL_PLANE_SECURITY_PROTOCOL
whose values can be PLAINTEXT
or SSL
.
Certificates will be loaded and used for the control plane gRPC services. The secrets or folders will be watched for updates (on certificate renewal) and automatically loaded again.
Helm Control Plane Install
When installing seldon-core-v2-setup
you can set the secret names for your certificates. If using cert-manager example discussed below this would be as follows:
helm install seldon-v2 k8s/helm-charts/seldon-core-v2-setup/ -n seldon-mesh \
--set security.controlplane.protocol=SSL
Kafka
Kafka secure activation is switched on and off via the environment variable: KAFKA_SECURITY_PROTOCOL
whose values can be PLAINTEXT
, SSL
or SASL_SSL
.
Examples are shown below:
mTLS Strimzi example
mTLS AWS MSK example
SASL PLAIN with Confluent Cloud example
SASL PLAIN with Azure Event Hub example
SASL SCRAM with Strimzi example
SASL SCRAM with AWS MSK example
SASL OAUTH with Confluent Cloud example
Data Plane
TLS Data plane activation is switched on and off via the environment variable: ENVOY_SECURITY_PROTOCOL
whose values can be PLAINTEXT
or SSL
.
When activated this ensures TLS is used to communicate to Envoy via the xDS server as well as using the SDS service to send cretificates to envoy to use for upstream and downstream networking. Downstream is the external access to Seldon and upstream is the path from Envoy to the model servers or pipeline gateway.
Helm Data Plane Install
When installing seldon-core-v2-setup
you can set data plane operations to TLS as below. This assumes the secrets installed by the helm chart at the end of this section.
helm install seldon-v2 k8s/helm-charts/seldon-core-v2-setup/ -n seldon-mesh --set security.envoy.protocol=SSL
The above uses default secret names defined for the certificates installed. You can change the names of the required certificate secrets as shown in a longer configuration below (again using the default names for illustration).
For this we use the following updated Helm values (k8s/samples/values-tls-dataplane-example.yaml
):
security:
controlplane:
protocol: PLAINTEXT
ssl:
server:
secret: seldon-controlplane-server
clientValidationSecret: seldon-controlplane-client
client:
secret: seldon-controlplane-client
serverValidationSecret: seldon-controlplane-server
envoy:
protocol: SSL
ssl:
upstream:
server:
secret: seldon-upstream-server
clientValidationSecret: seldon-upstream-client
client:
secret: seldon-upstream-client
serverValidationSecret: seldon-upstream-server
downstream:
client:
serverValidationSecret: seldon-downstream-server
server:
secret: seldon-downstream-server
We use Envoy internally to direct traffic and in Envoy's terminology upstream
is for internal model servers called from Envoy while the downstream server is the entrypoint server running in Envoy to receive grpc and REST calls. The above settings ensure mTLS for internal "upstream" traffic while provides a standard SSL non-mTLS entrpoint.
To use the above with the seldon CLI you would need a custom config file as follow:
{
"dataplane": {
"tls": true,
"skipSSLVerify": true
}
}
We skip SSL Verify as these are internal self-signed certificates. For production use you would change this to the correct DNS name you are exposing the Seldon entrypoint.
Cetificate Providers
The installer/cluster controller for Seldon needs to provide the certificates. As part of Seldon we provide an example set of certificate issuers and certificates using cert-manager.
Helm
You can install Certificates into the desired namespace, here we use seldon-mesh
as an example.
helm install seldon-v2-certs k8s/helm-charts/seldon-core-v2-certs/ -n seldon-mesh
Last updated
Was this helpful?