cleveragents/cleveragents-core

Fork 3

fix(k8s): [security] Service account token is mounted even when automountServiceAccountToken is false #4148

New issue

Open

opened 2026-04-06 11:29:00 +00:00 by freemo · 4 comments

freemo commented

2026-04-06 11:29:00 +00:00

Owner

Metadata

Branch: fix/k8s-automount-service-account-token
Commit Message: fix(k8s): disable automountServiceAccountToken in deployment manifest
Milestone: (none — backlog)
Parent Epic: #400

Backlog note: This issue was discovered during autonomous operation
on milestone v3.6.0. It does not block milestone completion and has been
placed in the backlog for human review and future milestone assignment.

Background and Context

The k8s/templates/serviceaccount.yaml correctly sets automountServiceAccountToken: false as a security best practice to prevent the Kubernetes API token from being automatically mounted into pods. However, k8s/templates/deployment.yaml (line 26) explicitly sets serviceAccountName, which causes Kubernetes to mount the service account token regardless of the automountServiceAccountToken: false setting on the ServiceAccount resource.

This creates a security risk: any compromised pod could potentially access the Kubernetes API with the permissions of the service account, even though the intent was to disable token mounting.

Current Behavior

The deployment.yaml sets serviceAccountName explicitly:

# k8s/templates/deployment.yaml (line 26)
      serviceAccountName: {{ include "cleveragents.serviceAccountName" . }}

While serviceaccount.yaml sets:

# k8s/templates/serviceaccount.yaml
automountServiceAccountToken: false

Setting serviceAccountName in the pod spec causes Kubernetes to mount the service account token, overriding the automountServiceAccountToken: false on the ServiceAccount object unless automountServiceAccountToken: false is also explicitly set in the pod spec itself.

Expected Behavior

The service account token should not be mounted into the pod unless it is explicitly required. If the pod does not need to communicate with the Kubernetes API, the token should not be present in the container filesystem.

Acceptance Criteria

k8s/templates/deployment.yaml explicitly sets automountServiceAccountToken: false at the pod spec level, OR the serviceAccountName reference is removed if no service account is needed
Pods deployed with the Helm chart do not have a service account token mounted at /var/run/secrets/kubernetes.io/serviceaccount/token unless explicitly required
Helm chart linting passes (helm lint)
The fix is consistent with the principle of least privilege

Subtasks

Audit k8s/templates/deployment.yaml to determine whether a named service account is actually required by the application
If no service account is needed: remove the serviceAccountName field from deployment.yaml
If a service account is needed but token mounting is not: add automountServiceAccountToken: false to the pod spec in deployment.yaml (this takes precedence over the ServiceAccount-level setting)
Verify the fix with helm template and confirm no token volume is projected into the pod spec
Update any related Helm chart documentation or values comments

Definition of Done

k8s/templates/deployment.yaml no longer causes the service account token to be mounted when it is not needed
helm lint passes with no errors or warnings related to this change
All nox stages pass
Coverage >= 97%

Automated by CleverAgents Bot
Supervisor: Bug Hunting | Agent: ca-new-issue-creator

## Metadata - **Branch**: `fix/k8s-automount-service-account-token` - **Commit Message**: `fix(k8s): disable automountServiceAccountToken in deployment manifest` - **Milestone**: *(none — backlog)* - **Parent Epic**: #400 > **Backlog note:** This issue was discovered during autonomous operation > on milestone v3.6.0. It does not block milestone completion and has been > placed in the backlog for human review and future milestone assignment. ## Background and Context The `k8s/templates/serviceaccount.yaml` correctly sets `automountServiceAccountToken: false` as a security best practice to prevent the Kubernetes API token from being automatically mounted into pods. However, `k8s/templates/deployment.yaml` (line 26) explicitly sets `serviceAccountName`, which causes Kubernetes to mount the service account token regardless of the `automountServiceAccountToken: false` setting on the ServiceAccount resource. This creates a security risk: any compromised pod could potentially access the Kubernetes API with the permissions of the service account, even though the intent was to disable token mounting. ## Current Behavior The `deployment.yaml` sets `serviceAccountName` explicitly: ```yaml # k8s/templates/deployment.yaml (line 26) serviceAccountName: {{ include "cleveragents.serviceAccountName" . }} ``` While `serviceaccount.yaml` sets: ```yaml # k8s/templates/serviceaccount.yaml automountServiceAccountToken: false ``` Setting `serviceAccountName` in the pod spec causes Kubernetes to mount the service account token, overriding the `automountServiceAccountToken: false` on the ServiceAccount object unless `automountServiceAccountToken: false` is also explicitly set in the pod spec itself. ## Expected Behavior The service account token should **not** be mounted into the pod unless it is explicitly required. If the pod does not need to communicate with the Kubernetes API, the token should not be present in the container filesystem. ## Acceptance Criteria - [ ] `k8s/templates/deployment.yaml` explicitly sets `automountServiceAccountToken: false` at the pod spec level, OR the `serviceAccountName` reference is removed if no service account is needed - [ ] Pods deployed with the Helm chart do not have a service account token mounted at `/var/run/secrets/kubernetes.io/serviceaccount/token` unless explicitly required - [ ] Helm chart linting passes (`helm lint`) - [ ] The fix is consistent with the principle of least privilege ## Subtasks - [ ] Audit `k8s/templates/deployment.yaml` to determine whether a named service account is actually required by the application - [ ] If no service account is needed: remove the `serviceAccountName` field from `deployment.yaml` - [ ] If a service account is needed but token mounting is not: add `automountServiceAccountToken: false` to the pod spec in `deployment.yaml` (this takes precedence over the ServiceAccount-level setting) - [ ] Verify the fix with `helm template` and confirm no token volume is projected into the pod spec - [ ] Update any related Helm chart documentation or values comments ## Definition of Done - [ ] `k8s/templates/deployment.yaml` no longer causes the service account token to be mounted when it is not needed - [ ] `helm lint` passes with no errors or warnings related to this change - [ ] All nox stages pass - [ ] Coverage >= 97% --- **Automated by CleverAgents Bot** Supervisor: Bug Hunting | Agent: ca-new-issue-creator

freemo added a new dependency

2026-04-06 11:29:05 +00:00

#400 Epic: Post-MVP Security

freemo referenced this issue

2026-04-06 11:29:42 +00:00

[Automated] CleverAgents Build Session - 2026-04-06 #3775

freemo added the

Points

label

2026-04-06 11:30:30 +00:00

freemo commented

2026-04-06 16:43:01 +00:00

Author

Owner

TRIAGE: v3.3.0 Tool Sources & Security - High Priority

This automated security issue identifies a Kubernetes service account token mounting vulnerability that should be elevated from backlog priority.

Security Risk Assessment:

Service account token mounted despite automountServiceAccountToken: false
Potential attack vector if pod is compromised
K8s deployment security hardening required
Follows principle of least privilege

Rationale for v3.3.0:

Security issues should be addressed before later milestones
K8s deployment security is essential for production readiness
Can be addressed alongside other security hardening work

Recommendation: Upgrade from Priority/Backlog to Priority/High and assign to v3.3.0 security hardening phase.

**TRIAGE: v3.3.0 Tool Sources & Security - High Priority** This automated security issue identifies a Kubernetes service account token mounting vulnerability that should be elevated from backlog priority. **Security Risk Assessment:** - Service account token mounted despite `automountServiceAccountToken: false` - Potential attack vector if pod is compromised - K8s deployment security hardening required - Follows principle of least privilege **Rationale for v3.3.0:** - Security issues should be addressed before later milestones - K8s deployment security is essential for production readiness - Can be addressed alongside other security hardening work **Recommendation:** Upgrade from Priority/Backlog to Priority/High and assign to v3.3.0 security hardening phase.

freemo added this to the v3.3.0 milestone

2026-04-06 17:48:49 +00:00

freemo commented

2026-04-06 18:50:08 +00:00

Author

Owner

Milestone Triage Decision: Moved to Backlog

This security logging issue has been moved out of v3.3.0 during aggressive milestone triage. While important for security, it does not relate to the core focus of Corrections + Subplans + Checkpoints.

Reasoning:

v3.3.0 focus: Essential corrections, subplan management, and checkpoint functionality
This issue: Security logging enhancement - important but not milestone-blocking
Impact: Security observability improvement, not core corrections/subplans/checkpoints functionality

Will be addressed in a future milestone focused on security hardening and observability.

**Milestone Triage Decision: Moved to Backlog** This security logging issue has been moved out of v3.3.0 during aggressive milestone triage. While important for security, it does not relate to the core focus of Corrections + Subplans + Checkpoints. **Reasoning:** - v3.3.0 focus: Essential corrections, subplan management, and checkpoint functionality - This issue: Security logging enhancement - important but not milestone-blocking - Impact: Security observability improvement, not core corrections/subplans/checkpoints functionality Will be addressed in a future milestone focused on security hardening and observability.

freemo removed this from the v3.3.0 milestone

2026-04-06 20:39:56 +00:00

HAL9000 commented

2026-04-08 14:02:34 +00:00

Owner

Label compliance fix applied:

Removed conflicting label: Priority/Backlog
Kept: Priority/High
Reason: Issue had two conflicting Priority/* labels. Per CONTRIBUTING.md, only one Priority/* label is allowed. Keeping the higher-priority label.

Automated by CleverAgents Bot
Supervisor: Backlog Grooming | Agent: backlog-groomer

Label compliance fix applied: - Removed conflicting label: `Priority/Backlog` - Kept: `Priority/High` - Reason: Issue had two conflicting Priority/* labels. Per CONTRIBUTING.md, only one Priority/* label is allowed. Keeping the higher-priority label. --- **Automated by CleverAgents Bot** Supervisor: Backlog Grooming | Agent: backlog-groomer

HAL9000 self-assigned this

2026-04-08 18:51:47 +00:00

HAL9000 added this to the v3.6.0 milestone

2026-04-08 18:51:47 +00:00

HAL9000 commented

2026-04-08 18:52:05 +00:00

Owner

Issue assigned to @HAL9000 and milestone set to v3.6.0.

Milestone Rationale: K8s security fix — service account token mounting is a deployment security concern. v3.6.0 covers deployment and security hardening.

Assignment Rationale: Default assignment to HAL9000 to maintain velocity.

Automated by CleverAgents Bot
Supervisor: Project Owner | Agent: project-owner

Issue assigned to @HAL9000 and milestone set to **v3.6.0**. **Milestone Rationale**: K8s security fix — service account token mounting is a deployment security concern. v3.6.0 covers deployment and security hardening. **Assignment Rationale**: Default assignment to HAL9000 to maintain velocity. --- **Automated by CleverAgents Bot** Supervisor: Project Owner | Agent: project-owner

HAL9000 added the

labels

2026-04-09 01:49:57 +00:00