AGH2 Component: Exploit Manager
Relevant source files
The following files were used as context for generating this wiki page:- charts/agh2/templates/exploit-manager/exploitmgr-deployment.yml
- charts/agh2/templates/exploit-manager/exploitmgr-service.yml
- charts/agh2/templates/exploit-manager/exploitmgr-db-secret.yml
- charts/agh2/values.yaml
- charts/agh2/templates/db/postgres-init-configmap.yml
- charts/agh2/templates/captain/captain-deployment.yml
The Exploit Manager (exploitmgr) is a backend microservice within the AGH2 application. Its primary role is to handle functionalities related to exploits, as indicated by its name and its interactions with other core components. It is deployed as a standard Kubernetes Deployment and exposes a gRPC service for internal cluster communication.
This component is stateful, requiring a dedicated PostgreSQL database for persistence. It also has optional dependencies on Redis and interacts with the AGH2 Core service. The central captain service acts as a client to the Exploit Manager, delegating exploit-related tasks to it.
Architecture and Kubernetes Resources
The Exploit Manager's architecture is defined by several Kubernetes resources created by the agh2 Helm chart. These resources manage its deployment, networking, and configuration.
This diagram illustrates the Kubernetes objects created for the Exploit Manager.
Deployment (exploitmgr-deployment.yml)
The core of the component is a Kubernetes Deployment named exploitmgr.
- Pod Structure: Each pod contains an init container and a main application container.
- Init Container: An init container named
exploitmgr-init-postgresqlruns before the main container. Its sole purpose is to block startup until the PostgreSQL database is available and ready to accept connections. - Main Container: The
exploitmgrcontainer runs the main application logic from theleukocyte-lab/argushack2/exploitmgrDocker image.
The following diagram shows the structure of a single exploitmgr pod.
Environment Variables
The exploitmgr container is configured using several environment variables.
| Variable | Value Source | Description |
|---|---|---|
NAMESPACE | fieldRef: metadata.namespace | The Kubernetes namespace where the pod is running. |
CORE_URL | core.$(NAMESPACE).svc.cluster.local:50005 | The internal cluster address for the AGH2 Core service. This is only set if core.enabled is true. |
DB_Conn | secretKeyRef: expmgr-db-secret.DB_CONN_STR | The full connection string for the PostgreSQL database. |
Sources: charts/agh2/templates/exploit-manager/exploitmgr-deployment.yml:32-44
Service (exploitmgr-service.yml)
To allow other components within the Kubernetes cluster to communicate with it, a Service named exploitmgr is created.
- Type:
ClusterIP(default) - Selector:
app: exploitmgr - Port: The service exposes port
50005, which targets thegrpcport (50005) on theexploitmgrpods.
This service is consumed by other components, such as the captain service, which uses the address exploitmgr.$(NAMESPACE).svc.cluster.local:50005 to communicate with it.
Sources: charts/agh2/templates/exploit-manager/exploitmgr-service.yml, charts/agh2/templates/captain/captain-deployment.yml:50-53
Database Secret (exploitmgr-db-secret.yml)
A Kubernetes Secret is created to hold the database connection string.
- Name:
expmgr-db-secret(configurable viavalues.yaml). - Key:
DB_CONN_STR - Value: The value is dynamically generated by the Helm chart using the
connection-stringtemplate. It combines the database host, port, user, password, and database name into a single URI.
The password for the database connection is automatically generated if not provided.
Sources: charts/agh2/templates/exploit-manager/exploitmgr-db-secret.yml, charts/agh2/values.yaml:313-315
Configuration
The Exploit Manager is configured via the exploitmgr section in the values.yaml file of the agh2 Helm chart.
| Parameter | Description | Default Value |
|---|---|---|
exploitmgr.enabled | Enables or disables the deployment of the Exploit Manager module. | true |
exploitmgr.image.repository | The Docker image repository for the service. | leukocyte-lab/argushack2/exploitmgr |
exploitmgr.image.tag | The tag for the Docker image. | v0.17.0 (from README, v0.20.0 in values.yaml) |
exploitmgr.image.pullPolicy | The image pull policy. | IfNotPresent |
exploitmgr.secret.enabled | Enables the automatic creation of secrets for this module. | true |
exploitmgr.secret.db.enabled | Enables the automatic creation of the database secret. | true |
exploitmgr.secret.db.name | The name of the PostgreSQL database for this module. | exploitmgr-db |
exploitmgr.secret.db.user | The PostgreSQL user for this module. | agh-exploit |
exploitmgr.secret.db.password | The password for the PostgreSQL user. If empty, it will be generated. | "" |
exploitmgr.service.redis.enabled | A flag to indicate if Redis is enabled for this service. Note: This flag does not appear to be used to configure the deployment. | true |
exploitmgr.extraEnv | A map of additional environment variables to inject into the container. | {} |
Sources: charts/agh2/values.yaml:300-329, charts/agh2/README.md:213-228
Dependencies and Interactions
The Exploit Manager does not operate in isolation and depends on several other services within the AGH2 ecosystem.
Database Initialization
When an internal PostgreSQL database is used (db.internal.enabled: true), the db-init-scripts ConfigMap is populated with SQL scripts to prepare the database for all AGH2 modules. For Exploit Manager, this script performs the following actions:
- Creates the database role specified by
exploitmgr.secret.db.user(e.g.,agh-exploit). - Creates the database specified by
exploitmgr.secret.db.name(e.g.,exploitmgr-db). - Assigns ownership of the new database to the newly created role.
This process ensures that the database and user are ready before the Exploit Manager pod attempts to connect.
The diagram below shows the database initialization flow.
Service Interactions
The Exploit Manager is primarily a gRPC server that is called by other services.
- AGH2 Captain (Client): The
captainservice is a primary consumer of the Exploit Manager. Thecaptaindeployment is configured with theEXPMGR_URLenvironment variable, pointing to theexploitmgrservice. This indicates a client-server relationship where Captain offloads exploit-related logic to the Exploit Manager. - AGH2 Core (Client): The
exploitmgrdeployment is configured with theCORE_URLenvironment variable, pointing to thecoreservice. This indicates that the Exploit Manager is a client of the Core service, likely for fetching or updating shared application data. - PostgreSQL (Backend): The Exploit Manager uses PostgreSQL for data persistence.
- Redis (Backend): The configuration in
values.yamlincludesexploitmgr.service.redis.enabled, suggesting an optional dependency on Redis, likely for caching or queuing. However, the deployment manifest does not show any environment variables to connect to Redis, unlike thecaptaindeployment.
Sources: charts/agh2/templates/captain/captain-deployment.yml:50-53, charts/agh2/templates/exploit-manager/exploitmgr-deployment.yml:35-38, charts/agh2/values.yaml:326-327
Summary
The AGH2 Exploit Manager is a specialized backend service responsible for managing exploit-related data and logic. It is deployed as a containerized application in Kubernetes, exposing a gRPC interface on port 50005. It relies on a dedicated PostgreSQL database for persistence and interacts with other key AGH2 services like Captain and Core, forming a critical part of the application's microservice architecture. Configuration is managed through the agh2 Helm chart, allowing for customization of its image, database credentials, and other operational parameters.