redis-last-fixes: engine-specific functional fixes, dragonfly binding, R0011 internal egress - #185
Conversation
…nding functional/keydb.yaml: keydb 6.x is Redis-6-based and does not implement FUNCTION (Redis 7.0 server-side functions) — drop function-list/function-stats (they errored). functional/dragonfly.yaml: dragonfly v1.39 implements a Redis subset — drop the six tests for commands it does not support (MEMORY DOCTOR, FUNCTION LIST/STATS, OBJECT ENCODING, CONFIG SET appendonly). redis-oss/valkey keep them (genuinely supported). deploy-distros.sh bind_dragonfly: the operator only stamps podMetadata onto newly created pods, so the live patch never relabelled the running instance and node-agent never enforced the profile (attack contrast dropped to 5 rules, no R0001). Recreate the instance pod after patching so it is born with the label.
R0011 (Unexpected Egress Network Traffic) gated on !net.is_private_ip(event.dstAddr), so in-cluster connections were never evaluated against the profile egress allowlist. Cluster-internal peers (a client reaching a service) could not trip the rule, which makes the allowlist contrast undemonstrable for internal traffic. Drop the filter so any egress destination not in the allowlist alerts, private IPs included.
📝 WalkthroughWalkthroughThe deployment script now recreates and verifies the Dragonfly pod after profile changes. Dragonfly and KeyDB suites remove unsupported command tests. Kubescape rule R0011 now evaluates private destinations against the configured egress profile. ChangesRedis distro compatibility
Kubescape egress evaluation
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@example/redis/distros/deploy-distros.sh`:
- Around line 86-87: Update the pod replacement flow in the deployment script
after deleting dragonfly-0 to explicitly wait or poll until the StatefulSet
recreates the pod, then run the existing kubectl wait for its ready condition.
Preserve the current namespace, pod name, ignore-not-found deletion, and timeout
behavior.
In `@example/redis/distros/functional/dragonfly.yaml`:
- Around line 106-108: Update the Dragonfly suite metadata description near the
top of the YAML to remove claims of BGREWRITEAOF and CONFIG SET appendonly
coverage, and describe the persistence coverage as only BGSAVE and LASTSAVE.
Keep the description aligned with the omitted tests documented in the suite.
🪄 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: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 3c1adcc1-fccd-48b8-95d8-ff4509e274ac
📒 Files selected for processing (4)
example/redis/distros/deploy-distros.shexample/redis/distros/functional/dragonfly.yamlexample/redis/distros/functional/keydb.yamlkubescape/default-rules.yaml
| kubectl -n dragonfly delete pod dragonfly-0 --ignore-not-found | ||
| kubectl -n dragonfly wait --for=condition=ready pod/dragonfly-0 --timeout=120s |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== file excerpt =="
sed -n '1,170p' example/redis/distros/deploy-distros.sh
echo
echo "== nearby occurrences of kubectl wait/delete =="
rg -n "kubectl .*delete|kubectl .*wait|dragonfly-0" example/redis/distros/deploy-distros.sh || true
echo
echo "== changed diff around file if available =="
git diff -- example/redis/distros/deploy-distros.sh | sed -n '1,180p'Repository: k8sstormcenter/bob
Length of output: 5095
🌐 Web query:
kubectl wait --for=create Pod documentation
💡 Result:
The kubectl wait command supports waiting for a resource to be created using the --for=create flag [1][2]. When you execute kubectl wait --for=create [resource_type]/[resource_name], the command will pause and poll the Kubernetes API until the specified resource exists [1][3]. If the resource is already present, the command proceeds immediately to check any other conditions specified [1][3]. Key points regarding this functionality: - Combined Conditions: You can combine creation and status checks in a single command. For example, to wait for a pod to be created and then reach a Ready state, you can use: kubectl wait --for=create pod/my-pod --for=condition=Ready pod/my-pod [1][3] - Sequential Evaluation: If --for=create is included alongside other conditions, the creation check is performed first [1][4][5]. - Behavior: This is an efficient way to handle scenarios where a resource is created asynchronously (e.g., by a deployment, job, or external process) and you need your script or process to pause until the resource is available to be acted upon [1][3]. Please note that in modern versions of Kubernetes (as of 2026), kubectl wait generally attempts to handle resource existence gracefully, but explicitly using --for=create is the documented method for ensuring the tool waits for the resource to be registered in the API server before evaluating further conditions [1][6].
Citations:
- 1: https://kubernetes.io/docs/reference/kubectl/generated/kubectl_wait/
- 2: https://kubernetes.co.id/en/docs/reference/kubectl/generated/kubectl_wait/
- 3: https://github.com/kubernetes/kubectl/blob/master/pkg/cmd/wait/wait.go
- 4: https://man.archlinux.org/man/extra/kubectl/kubectl-wait.1.en
- 5: https://manpages.opensuse.org/Tumbleweed/kubernetes1.36-client-common/kubectl-wait.1.en.html
- 6: https://v1-32.docs.kubernetes.io/docs/reference/kubectl/generated/kubectl_wait/
🌐 Web query:
kubectl kubectl wait condition Ready when object does not exist NotFound
💡 Result:
When using the kubectl wait command, if the target resource does not exist, the command will exit immediately with a non-zero exit status and an error, typically "Error from server (NotFound)" or "no matching resources found" [1][2][3]. It does not natively block or poll until the resource is created [1][3]. To address this behavior, you can use the following approaches: 1. Recommended: Use a wrapper script or a loop. Before calling kubectl wait, implement a loop to poll for the existence of the resource (e.g., using kubectl get). Once the resource is confirmed to exist, run kubectl wait to poll for the desired condition [1][3]. 2. Use --for=create (When supported). In some contexts, you may be able to use the --for=create flag in conjunction with other conditions to explicitly wait for the resource to be created before checking for readiness [4]. Example command: kubectl wait --for=create pod/my-pod --timeout=30s kubectl wait --for=condition=Ready pod/my-pod --timeout=120s 3. Alternative: Use kubectl rollout status. If you are waiting for a Deployment, StatefulSet, or DaemonSet, kubectl rollout status is often more robust than kubectl wait for handling resources that may not yet exist or are in the process of rolling out [3]. Example command: kubectl rollout status deployment/my-deployment --timeout=120s Historically, this behavior has been a known limitation in kubectl wait, where it was intentionally designed to fail if the resource was missing rather than block indefinitely [2][5]. While there have been ongoing community discussions and proposals to add native support for waiting for resource creation (e.g., --wait-for-creation flags), the most reliable, production-tested method remains explicit polling or using resource-specific rollout commands [6][7][8].
Citations:
- 1: https://latchkey.dev/learn/command-reference/kubectl-wait-for-condition
- 2: kubectl wait with selectors does not output anything if resource is not found kubernetes/kubernetes#66456
- 3: https://stackoverflow.com/questions/68226288/kubectl-wait-not-working-for-creation-of-resources
- 4: https://kubernetes.io/docs/reference/kubectl/generated/kubectl_wait/
- 5: Makes kubectl wait exit with status 1 and print an error message, if there is no resources matching selectors kubernetes/kubernetes#66692
- 6:
kubectl waitfor un-existed resource. kubernetes/kubectl#1516 - 7: kubectl wait: Introduce --wait-for-creation flag kubernetes/kubernetes#122994
- 8: kubectl wait should not return if resource not yet exist kubernetes/kubernetes#75227
Wait for the replacement pod before checking readiness.
kubectl wait --for=condition=ready does not block until the pod is created; if dragonfly-0 is deleted before the StatefulSet recreates it, the wait can fail with NotFound. Add an explicit creation wait or poll the pod for existence before checking the ready condition.
Suggested ordering
kubectl -n dragonfly delete pod dragonfly-0 --ignore-not-found
+ kubectl -n dragonfly wait --for=create pod/dragonfly-0 --timeout=120s
kubectl -n dragonfly wait --for=condition=ready pod/dragonfly-0 --timeout=120s📝 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.
| kubectl -n dragonfly delete pod dragonfly-0 --ignore-not-found | |
| kubectl -n dragonfly wait --for=condition=ready pod/dragonfly-0 --timeout=120s | |
| kubectl -n dragonfly delete pod dragonfly-0 --ignore-not-found | |
| kubectl -n dragonfly wait --for=create pod/dragonfly-0 --timeout=120s | |
| kubectl -n dragonfly wait --for=condition=ready pod/dragonfly-0 --timeout=120s |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@example/redis/distros/deploy-distros.sh` around lines 86 - 87, Update the pod
replacement flow in the deployment script after deleting dragonfly-0 to
explicitly wait or poll until the StatefulSet recreates the pod, then run the
existing kubectl wait for its ready condition. Preserve the current namespace,
pod name, ignore-not-found deletion, and timeout behavior.
| # dragonfly (v1.39) implements a Redis SUBSET: FUNCTION (Redis 7 server-side | ||
| # functions), OBJECT, MEMORY DOCTOR and CONFIG SET appendonly are unsupported, | ||
| # so those tests are omitted here (they remain in the redis-oss/valkey suites). |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Update the Dragonfly suite description to match the tests.
The metadata description at Lines 5-12 still claims full behavior coverage, including BGREWRITEAOF and CONFIG SET appendonly yes. The Dragonfly suite now omits those paths and retains only BGSAVE and LASTSAVE in the persistence section. This text can mislead users about the learned profile coverage.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@example/redis/distros/functional/dragonfly.yaml` around lines 106 - 108,
Update the Dragonfly suite metadata description near the top of the YAML to
remove claims of BGREWRITEAOF and CONFIG SET appendonly coverage, and describe
the persistence coverage as only BGSAVE and LASTSAVE. Keep the description
aligned with the omitted tests documented in the suite.
Signed-off-by: Duck <70207455+entlein@users.noreply.github.com>
2 participants
Redis distro retest — last fixes
Retest of the redis packaging distros surfaced three regressions/bugs, fixed here.
1. Engine-specific functional failures
The per-distro functional suites ran commands not implemented by every engine:
FUNCTION(Redis 7.0 server-side functions) →function-list/function-statserrored. Dropped fromfunctional/keydb.yaml.MEMORY DOCTOR,FUNCTION LIST/STATS,OBJECT ENCODING,CONFIG SET appendonlyerrored. Dropped fromfunctional/dragonfly.yaml.redis-oss (8.x) and valkey (9.x) genuinely support these, so they keep them. After the fix all four suites run clean: redis-oss 86, valkey 86, keydb 84, dragonfly 80 — 0 errors.
2. Dragonfly SBoB binding broken
The dragonfly operator only stamps
podMetadataonto newly created pods, sobind_dragonfly's live patch never relabelled the running instance — node-agent never enforced the profile (attack contrast collapsed to 5 rules, no R0001).deploy-distros.shnow recreates the instance pod after patching, so it is born with the label. Verified: 0 functional FP + 10-rule attack contrast (incl. R0001).3. R0011 skipped internal traffic
R0011(Unexpected Egress Network Traffic) gated on!net.is_private_ip(event.dstAddr), so cluster-internal connections were never checked against the profile's egress allowlist — the allowlist contrast was undemonstrable for internal peers. Dropped the filter so any egress destination not in the allowlist alerts, private IPs included.