Client App
Architecture Overview
Overview
This page provides a technical overview of the OBLV Deploy architecture, detailing the system's components and their interactions. In addition, the internal enclave architecture is also described.
Architecture Diagram
The following diagram presents an overview of the OBLV Deploy architecture.
The sections below describe the function and interaction of the components displayed in the above diagram.
Client Machine
The client machine is the point of interaction for users with the OBLV Deploy system, consisting of:
OBLV Client
Auth Server
The Auth server is responsible for authenticating requests to the enclave, ensuring secure access and operation. Any authentication server can be used for this, provided there is an appropriate authentication plugin running within the enclave. By default, this is an OAuth server.
Confidential Pod
Confidential Pod run the computing workloads, with each instance containing the following:
Enclave
The secure computational environment to process sensitive data and execute proprietary code.
Bootscript
A script that initialises the enclave environment on pod startup and configures the parent pod to act as a proxy for the enclave.
The Confidential Pod is pre-configured with OBLV Deploy EIF, obtained from the AWS Marketplace, which includes services designed to run within the enclaves and the necessary bootstrapping scripts.
Depending on your settings, the Kubernetes controller can start more than one Confidential Pod to ensure your system will support the demand.
OTel Collector
The OTel collector gathers telemetry data from the enclaves, including metrics, logs, and traces, from the enclaves. This information is transferred to the configured client backend systems for processing, like Prometheus, Loki, and Jaeger for further analysis.
Key Management Service (KMS)
The AWS KMS can optionally handle cryptographic keys, providing services such as secure SSL certificate management including certificate decryption within the enclaves, establishing secure communication with clients and key provisioning based on the enclaves' attestation. KMS Guide page shows the users can leverage AWS KMS within OBLV Deploy.
Kubernetes Controller
The Kubernetes controller monitors resource utilisation, using predefined metrics such as memory usage, to scale the number of pod as needed. Additionally, it orchestrates the deployment of these pods according to the specifications provided in the manifests of the deployment, ensuring they are configured with the necessary dependencies, replicas, and networking components. This orchestration includes:
Provisioning of Confidential Pods
Automated creation and configuration of Confidential Pods as according to the AMI specifications.
Load Balancer and Proxy Configuration:
Setting up networking components to ensure efficient distribution of traffic and service discovery.
Dashboard
Optional dashboard solutions, like Grafana, provide a visualisation solution for monitoring the system's operations, providing insights into the performance, and status of the deployments through an interactive dashboard.
Enclave Close-up
The enclave is part of the OBLV Deploy overall architecture. The enclave is composed of four main components:
Proxy
Any user interface which interacts with the OBLV Deploy system.
OBLV Internal Services (Default plugins)
OBLV Deploy services that ensure the optimal and secure operation of your application.
Client App
The client application. An enclave can have one or more client applications running. All external interactions of these services are managed by the OBLV Internal Services.
External User-Defined Plugins
Optional plugins to customise and extend the functionality of enclave services. These are optional plugins offered by OBLV Deploy or custom plugins built and integrated by users. These can include:
- Logging Service: This is an optional plugin you can integrate into the enclave to improve the logging capabilities. The Fluent-bit plugin is an example of an option you can use.
- Telemetry Service: Another optional plugin that you can use to capture and analyse the telemetry data.
The following image presents an overview of the internal enclave when using the OBLV Deploy.
In addition to the enclave components described above, the diagram also presents the interaction with the KMS. The communication between the enclave and the KMS is a critical aspect of the enclave's operation, ensuring that sensitive data and operations within the enclave remain secure through robust encryption and decryption protocols.
Optional Plugins (External User-Defined Services)
Users have the flexibility to incorporate optional plugins to customise and extend the functionality of enclave services. External plugins, also known as User-Defined Plugins, allow users to develop custom plugins or integrate third-party services to meet specific requirements and enhance the capabilities of enclave deployments.
Optional Plugin Types
The following are the main optional plugin types:
Focused on OAuth protocol support, ensuring secure user authentication following industry standards.
Handles the recording of operational data, with adaptability to interface with various logging systems.
Specialised in collecting and processing telemetry data, enhancing system monitoring and analysis capabilities.