[KeyManager] Introduce Key Management Agent#749
Open
NilanjanDaw wants to merge 6 commits intogoogle:mainfrom
Open
[KeyManager] Introduce Key Management Agent#749NilanjanDaw wants to merge 6 commits intogoogle:mainfrom
NilanjanDaw wants to merge 6 commits intogoogle:mainfrom
Conversation
NilanjanDaw
changed the title
…ECTION_VM support
This commit introduces the foundational infrastructure for the Key
Management Agent (KMA), enabling the KeyManager to run as a standalone
service independent of the main launcher. It establishes the
architectural groundwork for the KEY_PROTECTION_VM security milestone by
supporting distinct service roles (WSD and KPS) and multiple key
protection mechanisms within a unified entrypoint.
Key Changes
- Unified Agent Launcher: Introduced keymanager/cmd/agent, a
standalone entrypoint that replaces the previous WSD-only command.
It supports both WSD (Workload Service Daemon) and KPS
(Key Protection Service) roles via the SERVICE_ROLE environment
variable.
- Multi-Mode Support: Implemented logic to switch between
KEY_PROTECTION_VM_EMULATED and KEY_PROTECTION_VM modes, ensuring
full backward compatibility while preparing for isolated VM
deployments.
- Containerization: Introduces the KMA Dockerfile to build and deploy
the unified /kma binary
- Testing Infrastructure:
- Added unit and integration tests for the agent lifecycle,
including graceful shutdown and socket management.
- Introduced a Cloud Build configuration to automatically
validate the containerized agent and its REST APIs via the UDS
interface.
NilanjanDaw
force-pushed
the
add-kma-launcher
branch
from
bba6d55 to
ffb9583
Compare
meetrajvala
reviewed
Apr 24, 2026
|
|
||
| errChan := make(chan error, 1) | ||
| go func() { | ||
| errChan <- runWSD(ctx, socketPath) |
Contributor
There was a problem hiding this comment.
we will also have to pass KPS mechanism here and in the following tests where we call runWSD.
|
|
||
| errChan := make(chan error, 1) | ||
| go func() { | ||
| errChan <- runWSD(ctx, socketPath) |
Collaborator
There was a problem hiding this comment.
the number of expected args here is 3. need to pass mode
Comment on lines
+29
to
+35
| modeStr := os.Getenv("KEY_PROTECTION_MECHANISM") | ||
| mode := keymanager.KeyProtectionMechanism_KEY_PROTECTION_VM_EMULATED | ||
| if modeStr != "" { | ||
| if v, ok := keymanager.KeyProtectionMechanism_value[modeStr]; ok { | ||
| mode = keymanager.KeyProtectionMechanism(v) | ||
| } | ||
| } |
Collaborator
There was a problem hiding this comment.
even though we control the pipeline, what if someone sets an incorrect env like "RANDOM_MODE", our code won't fail in such case right?
Collaborator
Author
There was a problem hiding this comment.
Makes sense, add a separate environment variable parser to handle these.
Comment on lines
+37
to
+43
| roleStr := os.Getenv("SERVICE_ROLE") | ||
| role := keymanager.ServiceRole_WSD | ||
| if roleStr != "" { | ||
| if v, ok := keymanager.ServiceRole_value[roleStr]; ok { | ||
| role = keymanager.ServiceRole(v) | ||
| } | ||
| } |
Collaborator
There was a problem hiding this comment.
same here. our code won't fail if value of env SERVICE_ROLE isn't recognized.
Collaborator
Author
There was a problem hiding this comment.
Makes sense, add a separate environment variable parser to handle these.
| RUN cargo install bindgen-cli | ||
|
|
||
| WORKDIR /app | ||
| COPY . . |
Collaborator
There was a problem hiding this comment.
should we add .dockerignore to avoid copying all the files like .git?
Collaborator
Author
There was a problem hiding this comment.
Ack added a .gitignore file
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This commit introduces the foundational infrastructure for the Key Management Agent (KMA), enabling the KeyManager to run as a standalone service independent of the main launcher. It establishes the architectural groundwork for the
KEY_PROTECTION_VMsecurity milestone by supporting distinct service roles (WSD and KPS) and multiple key protection mechanisms within a unified entrypoint.Key Changes
- Unified Agent Launcher: Introduced
keymanager/cmd/agent, a standalone entrypoint that replaces the previous WSD-only command. It supports both WSD (Workload Service Daemon) and KPS (Key Protection Service) roles via theSERVICE_ROLEenvironment variable.- Multi-Mode Support: Implemented logic to switch between
KEY_PROTECTION_VM_EMULATEDandKEY_PROTECTION_VMmodes, ensuring full backward compatibility while preparing for isolated VM deployments.- Containerization: Introduces the KMA Dockerfile to build and deploy the unified
/kmabinary- Testing Infrastructure:
- Added unit and integration tests for the agent lifecycle, including graceful shutdown and socket management.
- Introduced a Cloud Build configuration to automatically validate the containerized agent and its REST APIs via the UDS interface.
This PR is dependent on #743