Configuration
Last updated
Was this helpful?
Last updated
Was this helpful?
The setup process for Vault begins with the initialization of the operator, which emits unsealing key shares and a root access token. Once the operator is unsealed and logged in, the SGX authentication plugin is registered and loaded. This step needs to be performed only once.
To ensure compatibility with our premain, we apply the example configuration to the vault during setup. This includes the following one-time steps:
Enabling the SGX authentication plugin at sgx-auth.
Configuring the PKI engine at sgx-pki.
Registering the KVv2 secrets at sgx-app.
Creating client certificates for external access.
To register an enclave based on its measurement, the following steps are performed for each enclave:
Creating a user with a name and measurement at sgx-auth.
Allowing certificate issuance for the specified name at sgx-pki.
Storing secrets for the specified name at sgx-app.
Creating access policies for a role specific to the name.
The provided name is used to issue a token for the role, granting access to the PKI and secrets through the defined policy.
All of these steps are performed using only the vault client.
The PKI configuration at sgx-pki consists of an intermediate CA that is signed by another PKI at sgx-pki-root. Both PKIs are configured with CRL (Certificate Revocation List) distribution endpoints within the cluster domain. This setup allows easy rotation of the PKI infrastructure if critical security issues are discovered that could potentially expose issued certificates within the vault or a service.
Unlike the temporary certificate used solely for interacting with the Vault API, this PKI is persisted using integrated data sealing and remains intact even after a reboot.
Our premain currently supports three types of secrets to ensure compatibility with various applications:
These secrets can be uploaded in a JSON string format.
The premain interacts with the vault using the vault software library for communication. Upon successful authentication, it requests secrets for its configured name and a certificate with a private key for its service domain name. Before provisioning, which involves executing the application with additional arguments, the TLS configuration is stored under /secrets/tmp along with the cluster PKI CA.
All attested applications within the cluster share the same CA, allowing them to securely communicate with each other unless the CA has been rotated. This enables full mutual TLS within the entire cluster at the application level.
The external client certificates generated during setup or after a PKI rotation can be utilized to directly access a service or set up a reverse proxy outside the cluster, facilitating conventional TLS-based access to the service.