feat: GOMEMLIMIT at 80% of memory limit for node-agent + kubevuln#827
feat: GOMEMLIMIT at 80% of memory limit for node-agent + kubevuln#827
Conversation
|
Warning Rate limit exceeded
To keep reviews running without waiting, you can enable usage-based add-on for your organization. This allows additional reviews beyond the hourly cap. Account admins can enable it under billing. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (9)
📝 WalkthroughWalkthroughHelm templates add helpers to compute GOMEMLIMIT from container memory settings, replace downward API usage with template-driven calculations, add configurable gomemlimitPercentage for kubevuln and node-agent, and make SBOM-scanner inclusion/behavior configurable across node-agent templates and configmap. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Review rate limit: 0/1 reviews remaining, refill in 51 minutes and 51 seconds.Comment |
|
@matthyx — these three PRs implement the syft memory-reduction work we discussed (NAUT-1283). The combined effect is -498 MB peak RSS on gitlab-ee (1,621 → 1,123 MB), fitting the 1.5 GB cgroup with margin. The syft side is a clean two-commit branch on
Whenever you have a moment. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
docs/node-agent-autoscaler.md (1)
187-189: Add language specifier to fenced code block.The fenced code block should have a language specifier for consistent rendering and to satisfy linting. Since this is a formula/pseudocode,
textis appropriate.📝 Proposed fix
-``` +```text GOMEMLIMIT = floor(memoryLimit × gomemlimitPercentage)</details> <details> <summary>🤖 Prompt for AI Agents</summary>Verify each finding against the current code and only fix it if needed.
In
@docs/node-agent-autoscaler.mdaround lines 187 - 189, The fenced code block
containing the formula "GOMEMLIMIT = floor(memoryLimit × gomemlimitPercentage)"
lacks a language specifier; update that block to use a language tag (use "text")
so the block becomestext ...to satisfy linting and ensure consistent
rendering—find the block with the symbols GOMEMLIMIT, memoryLimit, and
gomemlimitPercentage and add the "text" specifier.</details> </blockquote></details> </blockquote></details> <details> <summary>🤖 Prompt for all review comments with AI agents</summary>Verify each finding against the current code and only fix it if needed.
Inline comments:
In@charts/kubescape-operator/templates/_helpers.tpl:
- Around line 115-117: The convertMemToBytes helper misses an else branch to
handle bare numeric memory strings (raw byte counts); add an else after the
existing hasSuffix checks (the block that checks "Gi", "Mi", "m") that trims the
value and converts it to a float64 directly (no division) so $mem becomes a
numeric byte count for downstream float operations; update the code around the
hasSuffix "Gi"/"Mi"/"m" conditions (the $mem variable assignment logic) to
include this fallback.
Nitpick comments:
In@docs/node-agent-autoscaler.md:
- Around line 187-189: The fenced code block containing the formula "GOMEMLIMIT
= floor(memoryLimit × gomemlimitPercentage)" lacks a language specifier; update
that block to use a language tag (use "text") so the block becomes ```text ...symbols GOMEMLIMIT, memoryLimit, and gomemlimitPercentage and add the "text" specifier.🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID:
c41c6c75-de49-4015-9fc2-ee7b4d904cb9⛔ Files ignored due to path filters (1)
charts/kubescape-operator/tests/__snapshot__/snapshot_test.yaml.snapis excluded by!**/*.snap📒 Files selected for processing (8)
charts/kubescape-operator/templates/_helpers.tplcharts/kubescape-operator/templates/kubevuln/deployment.yamlcharts/kubescape-operator/templates/node-agent/_node-agent.tplcharts/kubescape-operator/templates/node-agent/template-configmap.yamlcharts/kubescape-operator/templates/operator/configmap.yamlcharts/kubescape-operator/tests/snapshot_test.yamlcharts/kubescape-operator/values.yamldocs/node-agent-autoscaler.md
| {{- else if hasSuffix "m" $mem -}} | ||
| {{- $mem = divf (trimSuffix "m" $mem | float64) 1e3 -}} | ||
| {{- end }} |
There was a problem hiding this comment.
Missing fallback for bare numeric memory values.
The convertMemToBytes helper is missing the else clause to handle bare numeric values (e.g., "1073741824"), which are valid Kubernetes memory quantities. If a user specifies memory as a raw byte count, the string won't be converted and subsequent float operations may fail or produce incorrect results.
🐛 Proposed fix to handle bare numbers
{{- else if hasSuffix "m" $mem -}}
{{- $mem = divf (trimSuffix "m" $mem | float64) 1e3 -}}
+ {{- else -}}
+ {{- $mem = ($mem | float64) -}}
{{- end }}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| {{- else if hasSuffix "m" $mem -}} | |
| {{- $mem = divf (trimSuffix "m" $mem | float64) 1e3 -}} | |
| {{- end }} | |
| {{- else if hasSuffix "m" $mem -}} | |
| {{- $mem = divf (trimSuffix "m" $mem | float64) 1e3 -}} | |
| {{- else -}} | |
| {{- $mem = ($mem | float64) -}} | |
| {{- end }} |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@charts/kubescape-operator/templates/_helpers.tpl` around lines 115 - 117, The
convertMemToBytes helper misses an else branch to handle bare numeric memory
strings (raw byte counts); add an else after the existing hasSuffix checks (the
block that checks "Gi", "Mi", "m") that trims the value and converts it to a
float64 directly (no division) so $mem becomes a numeric byte count for
downstream float operations; update the code around the hasSuffix "Gi"/"Mi"/"m"
conditions (the $mem variable assignment logic) to include this fallback.
Two helpers for computing GOMEMLIMIT as a percentage of a memory limit: - convertMemToBytes: parse a Kubernetes memory string into a byte count - gomemlimit: format "<N>MiB" from memory + percentage Adapted from the Traefik helm chart's traefik.gomemlimit pattern. Refs: NAUT-1283 Signed-off-by: Ben <ben@armosec.io>
Defaults to 0.8 (80%). Used by the kubescape-operator.gomemlimit helper to compute GOMEMLIMIT from resources.limits.memory. Refs: NAUT-1283 Signed-off-by: Ben <ben@armosec.io>
Replaces resourceFieldRef-based GOMEMLIMIT (= 100% of limit) with the kubescape-operator.gomemlimit helper, gated on nodeAgent.gomemlimitPercentage. Refs: NAUT-1283 Signed-off-by: Ben <ben@armosec.io>
Replaces resourceFieldRef-based GOMEMLIMIT (= 100% of limit) with the kubescape-operator.gomemlimit helper, gated on kubevuln.gomemlimitPercentage. Refs: NAUT-1283 Signed-off-by: Ben <ben@armosec.io>
Snapshot now records value-based GOMEMLIMIT entries computed by kubescape-operator.gomemlimit (= 0.8 of limits.memory) instead of resourceFieldRef. Refs: NAUT-1283 Signed-off-by: Ben <ben@armosec.io>
…o node-agent.env - convertMemToBytes: remove lower() call which confused M (mega, 1e6) with m (milli, 1e-3); use proper Kubernetes SI/BinarySI case (Gi/Mi/Ki for binary, G/M/k for decimal) — binary two-char checked before decimal one-char - node-agent.env: accept optional resources parameter and prefer it over the default .Values.nodeAgent.resources.limits.memory, so multipleDaemonSets configurations each get a GOMEMLIMIT that matches their own container limit - Update snapshot after template change Signed-off-by: Ben <ben@armosec.io>
…telUrl null fields Six test cases were generated from a cached docker image that didn't render configurations.excludeJsonPaths and configurations.otelUrl null values; re-run with fresh pull to match CI output exactly Signed-off-by: Ben <ben@armosec.io>
…om env in autoscaler Signed-off-by: Ben <ben@armosec.io>
When sbomScanner is enabled, include it in the autoscaler-managed DaemonSet template so that SBOM_SCANNER_SOCKET env var and the sidecar container are consistent with each other. Signed-off-by: Ben <ben@armosec.io>
…0Mi bump Add goMemLimitPercentage to nodeAgentAutoscaler config so the operator knows what percentage to use when computing GOMEMLIMIT per node group. Fix the 600Mi memory minimum bump: it was unconditionally applied when nodeSbomGeneration was enabled, but when the sbom-scanner sidecar is present the main node-agent container does not do SBOM generation, so the extra headroom is unnecessary. Now only bumps to 600Mi when nodeSbomGeneration=enabled AND sbomScanner sidecar is NOT enabled. Signed-off-by: Ben <ben@armosec.io>
… check Non-empty strings like "disable" are truthy in Go templates, so bare .Values.capabilities.nodeSbomGeneration would incorrectly trigger the 600Mi bump even when explicitly disabled. Match the pattern used throughout the chart (eq ... "enable"). Signed-off-by: Ben <ben@armosec.io>
Update 18 failing snapshot assertions caused by operator configmap content changes (goMemLimitPercentage field + 600Mi bump fix). Add two autoscaler snapshot test cases: - without sbom sidecar: verifies 600Mi bump and no sidecar container - with sbom sidecar: verifies 180Mi (no bump) and sidecar included Signed-off-by: Ben <ben@armosec.io> # Conflicts: # charts/kubescape-operator/tests/snapshot_test.yaml
Signed-off-by: Ben <ben@armosec.io>
Signed-off-by: Ben <ben@armosec.io>
Document the new goMemLimitPercentage parameter, how GOMEMLIMIT is computed per node group at reconcile time, the sbom sidecar in autoscaler mode, and the corrected 600Mi bump condition (only when sbomScanner sidecar is disabled). Signed-off-by: Ben <ben@armosec.io>
Signed-off-by: Ben <ben@armosec.io>
Signed-off-by: Ben <ben@armosec.io>
Signed-off-by: Matthias Bertschy <matthias.bertschy@gmail.com>
…ove scan results handling Signed-off-by: Matthias Bertschy <matthias.bertschy@gmail.com>
…days Signed-off-by: Matthias Bertschy <matthias.bertschy@gmail.com>
Signed-off-by: Matthias Bertschy <matthias.bertschy@gmail.com>
Signed-off-by: Matthias Bertschy <matthias.bertschy@gmail.com>
…108 respectively Signed-off-by: Matthias Bertschy <matthias.bertschy@gmail.com>
matthyx
force-pushed
the
feature/gomemlimit-80pct
branch
from
7e38dc5 to
df2152a
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
charts/kubescape-operator/tests/snapshot_test.yaml (1)
569-620:⚠️ Potential issue | 🟡 MinorNote that the new test cases follow the existing
accessKeydummy value pattern used throughout the snapshot test fileThe
accessKey: f304d73b-d43c-412b-82ea-e4c859493ce6value appears in all 23 test cases in this file (not newly introduced by this PR). While security scanners may flag it, this is a pre-existing test hygiene pattern. If replacing it is desired, apply the change uniformly across all test cases and regenerate snapshots accordingly.The new autoscaler test cases can optionally be made more explicit by adding
nodeAgent.gomemlimitPercentage: 0.8(the chart default), though this is not required since chart defaults will apply during snapshot generation.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@charts/kubescape-operator/tests/snapshot_test.yaml` around lines 569 - 620, The snapshot tests currently reuse the existing dummy accessKey value (accessKey: f304d73b-d43c-412b-82ea-e4c859493ce6) across many cases which may trigger scanners; either leave it as-is to match the project's existing pattern or replace it uniformly in all 23 test cases and regenerate snapshots; additionally, if you want the new autoscaler scenarios to explicitly reflect chart defaults, add nodeAgent.gomemlimitPercentage: 0.8 under the nodeAgent block in the two new cases (nodeAgent.autoscaler and nodeAgent.sbomScanner remain as shown) and then run the snapshot regeneration so tests remain consistent.
🧹 Nitpick comments (1)
charts/kubescape-operator/tests/snapshot_test.yaml (1)
575-594: MakenodeAgent.gomemlimitPercentageexplicit in the autoscaler snapshot scenariosThis PR’s objective includes setting GOMEMLIMIT at 80%. These two new autoscaler snapshots don’t explicitly set
nodeAgent.gomemlimitPercentage, so they may rely on chart defaults (which can change and silently weaken the coverage).I recommend adding
nodeAgent.gomemlimitPercentage: 80to both scenarios so the snapshot asserts the intended behavior directly.🛠️ Proposed change
- it: autoscaler mode without sbom sidecar ... set: unittest: true account: 9e6c0c2c-6bd0-4919-815b-55030de7c9a0 accessKey: ... server: api.armosec.io clusterName: kind-kind + nodeAgent.gomemlimitPercentage: 80 kubescapeScheduler.scanSchedule: "1 2 3 4 5" kubevulnScheduler.scanSchedule: "1 2 3 4 5" capabilities: ... - it: autoscaler mode with sbom sidecar ... set: unittest: true account: 9e6c0c2c-6bd0-4919-815b-55030de7c9a0 accessKey: ... server: api.armosec.io clusterName: kind-kind + nodeAgent.gomemlimitPercentage: 80 kubescapeScheduler.scanSchedule: "1 2 3 4 5" kubevulnScheduler.scanSchedule: "1 2 3 4 5" capabilities: ...Confirm the exact values key expected by the chart templates (and whether kubevuln needs an explicit
kubevuln.gomemlimitPercentagetoo) so this remains stable and doesn’t become a no-op.Also applies to: 601-620
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@charts/kubescape-operator/tests/snapshot_test.yaml` around lines 575 - 594, Add an explicit gomemlimitPercentage key set to 80 in the autoscaler snapshot scenarios so the chart assertions don't rely on defaults: update the YAML under the existing nodeAgent block (near the autoscaler and sbomScanner entries) to include nodeAgent.gomemlimitPercentage: 80 for both snapshots; also verify whether kubevuln expects an explicit kubevuln.gomemlimitPercentage and, if required, add kubevuln.gomemlimitPercentage: 80 alongside the existing kubevulnScheduler keys to ensure the snapshots assert the intended GOMEMLIMIT value.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/kubescape.yaml:
- Around line 39-44: Download and verify the Kubescape release checksum before
executing the binary: after constructing binary and before chmod/exec, fetch the
corresponding checksum (or signature) for KUBESCAPE_VERSION/version_no_prefix
and arch from the release assets, validate the downloaded "$binary" by checking
its SHA256 (or verifying the signature) using a checksum verification step
(e.g., sha256sum -c or gpg verification), and fail the workflow if verification
does not pass; reference the variables binary, KUBESCAPE_VERSION,
version_no_prefix, arch, RUNNER_TEMP and ensure the verification step runs prior
to "$binary" version.
- Around line 15-23: The workflow currently resolves Kubescape via the
releases/latest API in the step named "Resolve Kubescape version" (id:
kubescape-version), which makes CI non-deterministic; replace the runtime
curl/jq logic with a pinned, explicit version string (e.g., set an output or
environment variable like KUBESCAPE_VERSION with the fixed tag) and update any
later steps that consume steps.kubescape-version.outputs.version to use that
pinned value instead; remove the curl/jq commands and ensure the step emits the
fixed version as the same output name so downstream usage (by id
kubescape-version) continues to work.
---
Outside diff comments:
In `@charts/kubescape-operator/tests/snapshot_test.yaml`:
- Around line 569-620: The snapshot tests currently reuse the existing dummy
accessKey value (accessKey: f304d73b-d43c-412b-82ea-e4c859493ce6) across many
cases which may trigger scanners; either leave it as-is to match the project's
existing pattern or replace it uniformly in all 23 test cases and regenerate
snapshots; additionally, if you want the new autoscaler scenarios to explicitly
reflect chart defaults, add nodeAgent.gomemlimitPercentage: 0.8 under the
nodeAgent block in the two new cases (nodeAgent.autoscaler and
nodeAgent.sbomScanner remain as shown) and then run the snapshot regeneration so
tests remain consistent.
---
Nitpick comments:
In `@charts/kubescape-operator/tests/snapshot_test.yaml`:
- Around line 575-594: Add an explicit gomemlimitPercentage key set to 80 in the
autoscaler snapshot scenarios so the chart assertions don't rely on defaults:
update the YAML under the existing nodeAgent block (near the autoscaler and
sbomScanner entries) to include nodeAgent.gomemlimitPercentage: 80 for both
snapshots; also verify whether kubevuln expects an explicit
kubevuln.gomemlimitPercentage and, if required, add
kubevuln.gomemlimitPercentage: 80 alongside the existing kubevulnScheduler keys
to ensure the snapshots assert the intended GOMEMLIMIT value.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 545b5c92-dc59-417c-a495-1462a85e5d8f
⛔ Files ignored due to path filters (1)
charts/kubescape-operator/tests/__snapshot__/snapshot_test.yaml.snapis excluded by!**/*.snap
📒 Files selected for processing (3)
.github/workflows/kubescape.yamlcharts/kubescape-operator/tests/snapshot_test.yamlcharts/kubescape-operator/values.yaml
🚧 Files skipped from review as they are similar to previous changes (1)
- charts/kubescape-operator/values.yaml
| - name: Resolve Kubescape version | ||
| id: kubescape-version | ||
| env: | ||
| GITHUB_TOKEN: ${{ github.token }} | ||
| run: | | ||
| version="$(curl -fsSL -H "Authorization: Bearer $GITHUB_TOKEN" https://api.github.com/repos/kubescape/kubescape/releases/latest | jq -r .tag_name)" | ||
| test -n "$version" | ||
| test "$version" != "null" | ||
| echo "version=$version" >> "$GITHUB_OUTPUT" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify where dynamic "latest" resolution is used in workflows.
rg -n 'repos/kubescape/kubescape/releases/latest' .github/workflows -C2Repository: kubescape/helm-charts
Length of output: 527
Pin Kubescape version instead of resolving releases/latest at runtime.
This makes scan behavior non-deterministic and can break CI unexpectedly when upstream releases change.
♻️ Suggested change
- - name: Resolve Kubescape version
+ - name: Resolve Kubescape version (pinned)
id: kubescape-version
- env:
- GITHUB_TOKEN: ${{ github.token }}
run: |
- version="$(curl -fsSL -H "Authorization: Bearer $GITHUB_TOKEN" https://api.github.com/repos/kubescape/kubescape/releases/latest | jq -r .tag_name)"
+ version="${KUBESCAPE_VERSION:?Set repository variable KUBESCAPE_VERSION (e.g. vX.Y.Z)}"
test -n "$version"
test "$version" != "null"
echo "version=$version" >> "$GITHUB_OUTPUT"
+ env:
+ KUBESCAPE_VERSION: ${{ vars.KUBESCAPE_VERSION }}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - name: Resolve Kubescape version | |
| id: kubescape-version | |
| env: | |
| GITHUB_TOKEN: ${{ github.token }} | |
| run: | | |
| version="$(curl -fsSL -H "Authorization: Bearer $GITHUB_TOKEN" https://api.github.com/repos/kubescape/kubescape/releases/latest | jq -r .tag_name)" | |
| test -n "$version" | |
| test "$version" != "null" | |
| echo "version=$version" >> "$GITHUB_OUTPUT" | |
| - name: Resolve Kubescape version (pinned) | |
| id: kubescape-version | |
| run: | | |
| version="${KUBESCAPE_VERSION:?Set repository variable KUBESCAPE_VERSION (e.g. vX.Y.Z)}" | |
| test -n "$version" | |
| test "$version" != "null" | |
| echo "version=$version" >> "$GITHUB_OUTPUT" | |
| env: | |
| KUBESCAPE_VERSION: ${{ vars.KUBESCAPE_VERSION }} |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/kubescape.yaml around lines 15 - 23, The workflow
currently resolves Kubescape via the releases/latest API in the step named
"Resolve Kubescape version" (id: kubescape-version), which makes CI
non-deterministic; replace the runtime curl/jq logic with a pinned, explicit
version string (e.g., set an output or environment variable like
KUBESCAPE_VERSION with the fixed tag) and update any later steps that consume
steps.kubescape-version.outputs.version to use that pinned value instead; remove
the curl/jq commands and ensure the step emits the fixed version as the same
output name so downstream usage (by id kubescape-version) continues to work.
| binary="$RUNNER_TEMP/bin/kubescape" | ||
| mkdir -p "$(dirname "$binary")" | ||
| curl -fsSL "https://github.com/kubescape/kubescape/releases/download/${KUBESCAPE_VERSION}/kubescape_${version_no_prefix}_linux_${arch}" -o "$binary" | ||
| chmod +x "$binary" | ||
| echo "$(dirname "$binary")" >> "$GITHUB_PATH" | ||
| "$binary" version |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
In kubescape/kubescape GitHub releases, what checksum or signature asset should be used to verify Linux CLI binaries, and what is the recommended verification command?
💡 Result:
Use the “checksums.sha256” asset (SHA-256 checksum list published in each kubescape/kubescape GitHub release) to verify the Linux CLI binaries. Kubescape does not indicate GPG/PGP signature assets for the Linux CLI binaries in the release assets; instead it provides the SHA-256 checksums file. Recommended verification command (after downloading both the Linux binary and the corresponding checksums.sha256): sha256sum --check checksums.sha256 (You can run it from the directory containing the downloaded kubescape Linux binary and the checksums.sha256 file.)
Citations:
- 1: https://github.com/kubescape/kubescape/releases/tag/v4.0.3
- 2: https://github.com/kubescape/kubescape/releases/tag/v4.0.1
- 3: https://github.com/kubescape/kubescape/releases/tag/v4.0.5
- 4: https://github.com/kubescape/kubescape/wiki/Publishing
Verify binary integrity before executing the downloaded Kubescape CLI.
The workflow executes a downloaded binary without checksum validation, which weakens supply-chain security posture.
🔐 Suggested change
version_no_prefix="${KUBESCAPE_VERSION#v}"
binary="$RUNNER_TEMP/bin/kubescape"
+ asset="kubescape_${version_no_prefix}_linux_${arch}"
+ checksums="$RUNNER_TEMP/kubescape_checksums.sha256"
mkdir -p "$(dirname "$binary")"
- curl -fsSL "https://github.com/kubescape/kubescape/releases/download/${KUBESCAPE_VERSION}/kubescape_${version_no_prefix}_linux_${arch}" -o "$binary"
+ curl -fsSL "https://github.com/kubescape/kubescape/releases/download/${KUBESCAPE_VERSION}/${asset}" -o "$binary"
+ curl -fsSL "https://github.com/kubescape/kubescape/releases/download/${KUBESCAPE_VERSION}/checksums.sha256" -o "$checksums"
+ grep " ${asset}$" "$checksums" | sha256sum -c -
chmod +x "$binary"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/kubescape.yaml around lines 39 - 44, Download and verify
the Kubescape release checksum before executing the binary: after constructing
binary and before chmod/exec, fetch the corresponding checksum (or signature)
for KUBESCAPE_VERSION/version_no_prefix and arch from the release assets,
validate the downloaded "$binary" by checking its SHA256 (or verifying the
signature) using a checksum verification step (e.g., sha256sum -c or gpg
verification), and fail the workflow if verification does not pass; reference
the variables binary, KUBESCAPE_VERSION, version_no_prefix, arch, RUNNER_TEMP
and ensure the verification step runs prior to "$binary" version.
2 participants
Memory-reduction rollout (NAUT-1283)
Reduces node-agent + kubevuln scan peak RSS by 30.7% on gitlab-ee
(1,621 MB → 1,123 MB), fitting a 1.5 GB cgroup with 377 MB margin.
Measured deltas (gitlab-ee, 113,836 files; kernel peak RSS via /usr/bin/time -v)
Initiative status
workerpool.New(1); kubevulnscanConcurrencydefaults to 1)Cross-repo PRs
Audit
Pre-merge audit confirmed no production-path consumer reads
sbom.Files[*].Digestsorsbom.Files[*].Metadatain node-agent,kubevuln, or kubescape/storage. The two storage consumers
(
containerprofile_processor.go:172,applicationprofile_processor.go:67)only read
f.Location.RealPath, which the directory walker stillpopulates regardless of file-cataloger disable. Selective indexing also
keeps 99.9% of the file-path coverage on gitlab-ee
(113,265 of 113,382 paths).
Reference:
shared-designs-and-docs/syft-memory-improvement/2026-04-28-rollout-design.mdSummary by CodeRabbit
New Features
Documentation
Tests
Chores