Tags: kagent-dev/kagent
Tags
Fix/securitycontext runasuser (#1171) ## Fix: Apply Security Context Fields from Agent Spec to Generated Pods Fixes #1083 ### Problem The kagent controller was not applying `runAsUser` and other security context fields from the Agent's `deployment.securityContext` and `deployment.podSecurityContext` to the generated pod specifications. This caused pods to fail with `CreateContainerConfigError` when container images have non-numeric users. **Current Behavior**: Only `runAsNonRoot` and `allowPrivilegeEscalation` were being applied to pods, while `runAsUser`, `runAsGroup`, `fsGroup`, and `capabilities` were ignored. **Expected Behavior**: All security context fields from the Agent spec should be properly propagated to the pod template. ### Solution This PR adds support for both pod-level and container-level security contexts in the Agent API and ensures they are properly propagated to generated pods and containers. ### Changes Made #### 1. API Changes (`go/api/v1alpha2/agent_types.go`) - Added `SecurityContext *corev1.SecurityContext` to `SharedDeploymentSpec` for container-level security context - Added `PodSecurityContext *corev1.PodSecurityContext` to `SharedDeploymentSpec` for pod-level security context #### 2. Internal Struct Updates (`go/internal/controller/translator/agent/adk_api_translator.go`) - Added `SecurityContext` and `PodSecurityContext` fields to the `resolvedDeployment` struct #### 3. Resolver Functions - **`resolveInlineDeployment`**: Now copies `SecurityContext` and `PodSecurityContext` from the Agent spec - **`resolveByoDeployment`**: Now copies `SecurityContext` and `PodSecurityContext` from the Agent spec #### 4. Manifest Building (`buildManifest` function) - **Pod-level security context**: `PodSecurityContext` from the Agent spec is applied to `PodSpec.securityContext`, which includes fields like: - `runAsUser`, `runAsGroup`, `runAsNonRoot` - `fsGroup`, `supplementalGroups` - `seLinuxOptions`, `seccompProfile` - **Container-level security context**: `SecurityContext` from the Agent spec is applied to container `SecurityContext`, which includes fields like: - `runAsUser`, `runAsGroup`, `runAsNonRoot` - `capabilities`, `allowPrivilegeEscalation` - `readOnlyRootFilesystem`, `privileged` - **Sandbox compatibility**: When `needSandbox` is `true` (for skills or code execution), the `Privileged` flag is set appropriately while preserving user-provided security context settings - **Init containers**: Security context is also applied to init containers (e.g., skills-init container) #### 5. Code Generation - Ran `make generate` to update the generated deepcopy methods for the new fields ### How It Works 1. **Pod-level security context**: The `podSecurityContext` field from the Agent spec is directly applied to `PodSpec.securityContext`, affecting all containers in the pod. 2. **Container-level security context**: The `securityContext` field from the Agent spec is applied to each container's `SecurityContext`. When sandbox mode is required (for skills or code execution), the `Privileged` flag is merged with user-provided settings. 3. **Priority**: User-provided security context settings take precedence, with sandbox requirements merged in when necessary. ### Testing **Unit Tests**: - Verified that security context fields are properly copied in resolver functions - Confirmed that security context is correctly applied to pod and container specs in manifest building **Manual Testing**: - Verified that pods are created successfully with `runAsUser` specified (e.g., `runAsUser: 1000`) - Confirmed that security context fields (`runAsUser`, `runAsGroup`, `fsGroup`, `capabilities`) are properly applied to both main containers and init containers - Tested sandbox mode compatibility (skills and code execution) with custom security contexts - Validated that `CreateContainerConfigError` is resolved when container images have non-numeric users - Verified that both `podSecurityContext` and `securityContext` from Agent spec are correctly propagated to pod template **Code Quality**: - Ran `make lint` to ensure code style compliance - All existing tests pass ### Documentation - API changes are self-documenting through the CRD schema - No additional documentation updates required as this fixes existing functionality ### Checklist - [x] Code follows project style guidelines (Go Code Review Comments) - [x] Ran `make lint` and fixed any issues - [x] Ran `make generate` to update generated code - [x] Changes are tested and verified - [x] All commits are signed off (DCO) ### Related Issues - Fixes #1083 - Controller not applying runAsUser from Agent securityContext to pod containers - Resolves `CreateContainerConfigError` when container images have non-numeric users or require specific security context configurations --------- Signed-off-by: Raghavendiran-2002 <raghavendiran46461@gmail.com>
Fixed NPM audit issues (#1166) This fixes CVE-2025-55182, and clears up the other warning logs when running `npm audit` in the `/ui` directory. Before: <img width="1078" height="688" alt="Screenshot 2025-12-08 at 6 10 30 PM" src="https://github.com/user-attachments/assets/ccb5c4cd-15e2-40d6-8aea-233faba5ce52" /> After: <img width="1078" height="67" alt="Screenshot 2025-12-08 at 6 10 04 PM" src="https://github.com/user-attachments/assets/66ae3b47-a93d-47af-8211-0109f46ad6e2" /> --------- Signed-off-by: Nicholas Bucher <behappy54321@gmail.com>
feat: Use Sandbox Runtime for Bash tool and refactor artifact utils t… …ools (#1071) This PR follows #1062: - Wrap bash commands with Anthropic Sandbox Runtime ("srt") to replace manually handling security - Creates working directory for agent based on session id, where `skills/` is symlinked to the `/skills` loaded into the container or any other customised skills base path. This directory is where all commands are run, python imports from skills are handled by modifying the `PYTHONPATH` env variable - Added write, read, edit file tools to help the agent perform better at simple coding tasks when skill requires them - The following enhancement to artifact related utils - Tool to "stage" artifact from the storage to working directory so the agent can perform action on them - Tool to "return" output artifacts from working directory to the storage so the client can download later - Currently, working with artifacts require custom `Runner` loop (run locally) due to frontend limitations ## Testing Features in this PR will work to the full capacity of the examples listed in #1062, this includes everything from accessing skills to writing code, managing dependencies, and creating files / images, **subject to the limitations below**. ## Limitations - This only works locally, to work in BYO or any other environment we need to install srt + setup `.srt-config.json` properly, for local testing just adding `pypi.org` to allowed network --------- Signed-off-by: Jet Chiang <jetjiang.ez@gmail.com>
skip building mcp servers on kagent deploy (#1075) building mcp servers when we run `kagent deploy` is redundant because those images aren't used anyway when deploying. we create the MCPServer/RemoteMCPServer resource instead. Signed-off-by: Peter Jausovec <peter.jausovec@solo.io>
basic local development feature (#996) This PR adds support for local development workflow for agents and MCP servers. **kagent add-mcp Command** Adds a wizard for adding MCP servers to agent projects (also supports non-interactive usage). Remote and command-based (stdio) MCP servers as supported for now. The command automatically generates a folder for each MCP server with config.yaml and Dockerfile - these are used for building and running MCP servers locally. Additionally, an mcp_tools.py file is added to the agent project and it allows users to include all or specific tools from MCP servers to their agents. The docker-compose.yaml also gets updated and includes the entry for running MCP servers locally. <img width="960" height="559" alt="Screenshot 2025-10-20 at 11 52 40 AM" src="https://github.com/user-attachments/assets/55ce8f3d-522e-401f-b8bc-c112b9fe4e2f" /> **kagent run Command** Runs the agent project locally -- it uses docker-compose.yaml and the docker-compose command to launch the agent and MCP servers. It waits for the agent to be healthy and then launches into a TUI where the user can chat with an agent. <img width="821" height="693" alt="Screenshot 2025-10-20 at 12 27 30 PM" src="https://github.com/user-attachments/assets/0e8bc176-db65-4166-8b33-0f585aca0c61" /> **kagent deploy Command** Builds the Docker images and deploys the agent and MCP servers to the cluster. Has a --dry-run mode that outputs the resources without deploying. **Other changes** There's other various changes to support the local dvelopment -- specifically the kagent-adk, where I added the --local flag that's set when running the agent locally and it uses an in-memory session store. **Remaining work** - add support for Docker and kmcp manifest.yaml MCP types - check if we can better organize/name the commands (specifically `add-mcp`) - potentially run a light web server as part of the CLI so we can get session persistence for local development --------- Signed-off-by: Peter Jausovec <peter.jausovec@solo.io> Signed-off-by: Peter Jausovec <peterj@users.noreply.github.com> Signed-off-by: Eitan Yarmush <eitan.yarmush@solo.io> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Co-authored-by: Eitan Yarmush <eitan.yarmush@solo.io>
feat: implement STS client and integration in kagent-adk (#993) Implements an STS client in `kagent-sts` and an integration of the client with `kagent-adk.` --------- Signed-off-by: JM Huibonhoa <jm.huibonhoa@solo.io> Signed-off-by: Eitan Yarmush <eitan.yarmush@solo.io> Co-authored-by: Eitan Yarmush <eitan.yarmush@solo.io>
PreviousNext