Skip to content

SconeApps: MaxScale

Deploy a confidential MaxScale SCONE to your Kubernetes cluster.

Prerequisites

  • A Kubernetes cluster with some SGX machines.

Install the chart

Add the repo

If you haven't yet, please add the SconeApps repo to Helm.

Create a SCONE CAS policy for MaxScale

By default, attestation is switched off for MaxScale. You can enable attestation by setting parameters (see Parameters):

  • scone.attestation.enabled to true,
  • scone.attestation.cas to a CAS service like 5-0-0.scone-cas.cf, and
  • scone.attestation.config_id to the policy name.

Install the chart

Deploy MaxScale with the default parameters to your Kubernetes cluster by executing:

helm install my-maxscale sconeapps/maxscale

MaxScale will be deployed as a Deployment, meaning that each replica will behave exactly the same way. Optionally, an HAProxy Ingress controller can be deployed to balance the incoming requests across all the MaxScale replicas.

Have a look at the Parameters section for a complete list of parameters this chart supports.

SGX device

By default, this helm chart uses the SCONE SGX Plugin. Hence, it sets the resource limits of CAS as follows:

resources:
  limits:
    sgx.intel.com/enclave: 1

Alternatively, set useSGXDevPlugin to azure (e.g., --useSGXDevPlugin=azure) to support Azure's SGX Device Plugin. Since Azure requires the amount of EPC memory allocated to your application to be specified, the parameter sgxEpcMem (SGX EPC memory in MiB) becomes required too (e.g., --set useSGXDevPlugin=azure --set sgxEpcMem=16).

In case you do not want to use the SGX plugin, you can remove the resource limit and explicitly mount the local SGX device into your container by setting:

extraVolumes:
  - name: dev-isgx
    hostPath:
      path: /dev/isgx

extraVolumeMounts:
  - name: dev-isgx
    path: /dev/isgx

Please note that mounting the local SGX device into your container requires privileged mode, which will grant your container access to ALL host devices. To enable privileged mode, set securityContext:

securityContext:
  privileged: true

Parameters

A complete list of parameters this chart supports.

Parameter Description Default
replicaCount How many MaxScale replicas to be deployed 1
image MaxScale SCONE image registry.scontain.com/sconecuratedimages/apps:maxscale-2.5.6-alpine3.11-scone5
imagePullPolicy MaxScale SCONE pull policy IfNotPresent
imagePullSecrets MaxScale SCONE pull secrets [{"name": "sconeapps"}]
nameOverride String to partially override maxscale.fullname template with a string (will prepend the release name) nil
fullNameOverride String to fully override maxscale.fullname template with a string nil
scone.attestation.enabled Enable SCONE remote attestation false
scone.attestation.lasUseHostIP Use node host IP as LAS address true
scone.attestation.las LAS address, to be exported as SCONE_LAS_ADDR. Defaults to the Docker network interface address. Note that this value is not considered if lasUseHostIP is set to true. nil
scone.attestation.cas CAS address, to be exported as SCONE_CAS_ADDR nil
scone.attestation.config_id MaxScale SCONE session. To be exported as SCONE_CONFIG_ID nil
scone.attestation.env SCONE environment variables to be exported into the container nil
extraEnvVars Environment variables to be injected into MaxScale container nil
podSecurityContext Configure a security context for the pod nil
securityContext Configure a security context for the pod {}
service.port MaxScale listener port 3306
service.type MaxScale service type NodePort
configuration Define the static configuration the MaxScale replicas will use. The content will be rendered as-is into /etc/maxscale.cnf. Refer to Configuration options for more information nil
generateConfig.enabled If enabled, let MaxScale generate its config. from provided templates false
generateConfig.servers List of IP addresses to be added to MaxScale as servers. Leave it undefined or empty and MaxScale will use the DNS entries of the MariaDB instances deployed alongside it nil
generateConfig.serverTemplate Template used to render server and monitor definitions. Now it defaults to sharded setup Sharded setup, where each instance (e.g. IP address) is considered to be a different shard
generateConfig.serviceTemplate Template used to render service and listener definitions Considers one service and one listener exposing all shards at the same port
generateConfig.cliTemplate Template used to render the CLI service for MaxScale admin tools Default one, from MaxScale docs
haproxy.enabled Deploy HAProxy Ingress Controller alongside MaxScale and expose it through a service false
haproxy.controller.service.type Type of service used to expose the HAProxy NodePort
haproxy.controller.tcp Configure TCP services for the Ingress. Please note that MaxScale will be exposed by default (HAProxy's 8000 -> MaxScale's 3306) {}
haproxy.defaultBackend.enabled Deploy a default backend service alongside the ingress controller true
haproxy.defaultBackend.image.repository Image repository for the default backend service gcr.io/google_containers/defaultbackend
haproxy.defaultBackend.image.tag Default backend service tag 1.0
resources CPU/Memory resource requests/limits for node. {}
nodeSelector Node labels for pod assignment (this value is evaluated as a template) {}
tolerations List of node taints to tolerate (this value is evaluated as a template) []
affinity Map of node/pod affinities (The value is evaluated as a template) {}
initDbScripts Specify dictionary of scripts to be run at first boot nil
extraVolumes Extra volume definitions []
extraVolumeMounts Extra volume mounts for MaxScale pod []
serviceAccount.create Create a serviceAccount to be used by the application false
useSGXDevPlugin Use SGX Device Plugin to access SGX resources. "scone"
sgxEpcMem Required to Azure SGX Device Plugin. Protected EPC memory in MiB nil

Configuration options

This chart offers three different ways of configuring MaxScale replicas. They are listed below, and the former takes precedence over the latter:

  1. configuration: define an static configuration to be rendered as-is into the MaxScale containers. If defined, the other alternatives will not be considered.
  2. Put a maxscale.cnf in files/ directory: its contents will be then injected into the MaxScale containers.
  3. Auto-generated configs: If none of the previous alternatives were used and generateConfig=true, MaxScale will try to generate a configuration file for you. Configuration templates must be defined into generateConfig.serverTemplate, generateConfig.serviceTemplate and generateConfig.cliTemplate. The chart will then look at the addresses listed in generateConfig.servers to render these templates. If generateConfig.servers is empty or not defined AND MaxScale is being deployed alongside MariaDB through the umbrella chart, MaxScale will fill the addresses with the DNS entries of the MariaDB instances being deployed in the same Helm release. Of course, this last attempt will panic if MaxScale is being deployed alone.

Configuring the HAProxy Ingress

The optional HAProxy Ingress is, in fact, a subchart with a customized version of the upstream HAProxy Ingress chart. Few changes were made to the templates, as we need MaxScale exposed as a TCP service. If you want to see the complete set of parameters for the HAProxy Ingress controller, please have a look at the original chart.