Deploying and Attesting a Confidential MariaDB

We explain how to deploy a confidential MariaDB running inside of an SGX enclave with the help of SCONE and helm. We support two deployment architectures for Confidential MariaDB:

a scalable deployment supporting horizontal scaling with the help of MaxScale and HaProxy, and
a simple, single-master deployment.

Background

Privacy regulations define the scope of Personally Identifiable Information (PII), i.e., what is and what is not PII. For example, the date of birth is always considered PII but unique online identifiers might not included in all privacy regulations yet. Each legislation might decide independently on what is considered PII and surely, the definition of PII will change over time.

For companies with customers from various geographic regions, conformance with all privacy regulations is a challenge. Non-compliance comes with a variety of risks. Hence, missing to protect some PII and data in general can imply high costs.

One approach is to encrypt only those fields or parts of a field of a database that contain PII. One popular way to do so is to use tokenization of these fields. As we explained above, it is not always clear which fields need to be tokenized and this might change over time. Moreover, some fields like customer support notes might contain PII - even if there is a policy against storing such information in the notes.

Our approach is as follows. We recommend to encrypt everything all the time, i.e., at rest, on the wire and during runtime. In many cases, this is the best answer for safeguarding against all possible risks. We show how to limit access to the database to authorized clients only and can even prevent operators to log into the database. In this way, one cannot only reduce the scope of security assessments but one can use it as a safety net for other mechanisms like masking and tokenization. Our scalable setup already supports maxscale's data masking out of the box.

Architecture

In this section, we describe the single-master MariaDB deployment. This setup provides the following security properties:

runtime encryption: MariaDB runs inside inside of an enclave and hence, the integrity and confidentiality of the data and the code is protected during processing.
encryption at rest: All files - including all databases - are encrypted using MariaDB's built-in encryption mechanism, i.e., all data written to disk is encrypted before leaving the enclave and all data read from disk is decrypted after entering the enclave.
encryption in transit: All data in transit is encrypted with the help of TLS. Data transmitted via the network is encrypted before leaving MariaDB's enclave and data received is decrypted after entering the enclave.
secrets management: MariaDB's encryption keys and the TLS certificate are provided to MariaDB using a security policy. SCONE CAS enforces this policy, i.e., it ensures that only MariaDB running inside of an enclave will be able to access these keys.
protection against insider attacks: MariaDB's are generated inside of an enclave by SCONE CAS, i.e., the keys cannot be seen or retrieved by any human.
authorized platforms only: You can limit the execution of MariaDB to the nodes of your Kubernetes cluster. As such, an adversary cannot, for example, start MariaDB on another computer using a stolen copy of your encrypted databases and try to attack MariaDB after it retrieved the secrets: SCONE CAS will not provide the secrets to this MariaDB instance.
authorized clients only: We can limit access to MariaDB to certain clients, e.g., a tokenizer only. This access limitation is based on TLS client certificates. We can enforce that, for example, a tokenizer has to run inside of an enclave to get access to MariaDB. Note that while the tokenizer protects individual data items inside the database, it limits the expressiveness of queries. The combination of a tokenizer with a confidential MariaDB permits better trade-offs to ensure excellent security and expressiveness.
data masking: One can use maxscale's data masking to limit the visibility of Personally Identifiable Information.

Prerequisites

A Kubernetes cluster
helm is deployed
Kubernetes SGX plugin is installed
We granted you access to sconeapps and SCONE CLI container images
We granted you access to a MariaDB image and the MariaDB policy templates
SCONE CAS and SCONE LAS are deployed

Creating a MariaDB Security Policy

To run a confidential MariaDB, one needs to create a security policy, a.k.a. session in a SCONE CAS instance. You can deploy CAS with helm. Before we can create a policy, we need to attest CAS, i.e., we determine that SCONE CAS runs inside an enclave and it was not modified.

To attest SCONE CAS, we define two environment variables (see details): $SCONE_CAS_ADDRand $CAS_MRENCLAVE. We can then attest CAS with the SCONE CLI running on a trusted computer. Alternatively, you can attest with the CLI running inside of an enclave.

scone cas attest $SCONE_CAS_ADDR $CAS_MRENCLAVE

If the attestation is successful, the SCONE CLI stores the certificate of the attested SCONE CAS in a sealed file on your local computer. Whenever the CLI connects to this SCONE CAS again, it will ensure with TLS that it talks to the same CAS.

Next, we need to create a session, for MariaDB and a second policy for the MariaDB clients. We provide some default session templates that can be customized to your needs.

Each session has a unique name. We generate unique session names for the database which we store in environment variable $DBSESSION. For the MariaDB client, we store a unique session name in environment variable DBCLIENT.

export DBSESSION="MariaDBSession-$RANDOM"
export DBCLIENT="MariaDBClientSession-$RANDOM"

We limit the execution of our database to the nodes of our Kubernetes cluster (see platforms ):

export PLATFORMS=$(get_platform_ids)

We can now create two sessions - with templates that we provide:

one for the database, and
one for the clients that are permitted to connect to this MariaDB instance:

scone session create --name=$DBCLIENT  --use-env scone-templates/mariadb/dbclient.yml
scone session create --name=$DBSESSION --use-env scone-templates/mariadb/dbsession.yml

The MariaDB session template will give session $DBCLIENT access to the MariaDB CA certificate - which is created as part of $DBSESSION- to ensure that the MariDB clients can authenticate this MariaDB instance.

Deploying MariaDB

The sconeapps/mariadb chart will deploy MariaDB in an enclave. We set the session in which we want to run this MariaDB as follows:

helm install mariadb sconeapps/mariadb --set scone.attestation.config_id=$DBSESSION

This starts MariaDB inside of an enclave in the default Kubernetes namespace. Its security policy $DBSESSION creates client certificates, exports these to the client policy $DBCLIENT and the client policy $DBCLIENT imports these client certificates. This gives the clients the right to connect to this MariaDB instance.

Attestation

The attestation of MariaDB is performed implicitly whenever an authorized MariaDB client connects to MariaDB (i.e, a client that has a valid client certificate issued by $DBSESSION):

MariaDB instance only receives its certificate and secrets from SCONE CAS if it satisfies the conditions in its policy $DBSESSIONS
a MariaDB client gets authorized, i.e., receives a MariaDB client certificate, if it satisfies the condition stated in its policy $DBCLIENT. It also receives the CA certificate of MaraDB's certificate: This CA certificate only signs certificates if the service - in this case MariaDB - satisfies all its security properties.
when an authorized MariaDB client connects to MariaDB, TLS will ensure that both the client as well as the MariaDB instance satisfy their respective security policies.