Rebase rebase 5.0 5.0.0 0.nightly 2026 07 05 172708 amd64 2026 07 05 arm64 2026 07 06#6992
Conversation
openshift-ci
Bot
added
the
do-not-merge/work-in-progress
|
Skipping CI for Draft Pull Request. |
|
/test ? |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: pacevedom The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci
Bot
added
the
approved
WalkthroughThis PR advances nightly version pins, regenerates auto-rebase metadata, and updates the OpenShift router deployment plus manifest patches for HAProxy, mTLS, and access logging. ChangesNightly rebase and release pins
Router deployment and manifest patches
Estimated code review effort: 3 (Moderate) | ~25 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5 | ❌ 10❌ Failed checks (10 inconclusive)
✅ Passed checks (5 passed)
✨ 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. Comment |
|
/test e2e-aws-tests-cache |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
scripts/auto-rebase/manifests_patches/011-ingress-deployment-access-logging.patch (2)
97-118: 🔒 Security & Privacy | 🟠 Major | ⚡ Quick winHarden the new
logssidecar before enabling it.This sidecar is long-lived but has no
securityContext, limits, liveness probe, or readiness probe. Add those to the patch so regenerated manifests stay compliant.As per path instructions, Kubernetes manifests require hardened securityContext fields, resource limits on every container, and liveness + readiness probes.
🤖 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 `@scripts/auto-rebase/manifests_patches/011-ingress-deployment-access-logging.patch` around lines 97 - 118, The new `logs` sidecar in the ingress deployment patch needs hardening before it can be enabled. Update the sidecar definition added under the `AccessLoggingEnabled`/`AccessLoggingSyslogAddress` condition to include a `securityContext`, resource limits in addition to requests, and both liveness and readiness probes so the generated manifest stays compliant. Use the existing `logs` container block as the place to add these required fields.Source: Path instructions
97-102: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winRemove the duplicate
imagePullPolicykey.The
logscontainer declaresimagePullPolicytwice, which can break strict YAML tooling or make the manifest ambiguous.Proposed fix
- name: logs imagePullPolicy: IfNotPresent terminationMessagePolicy: FallbackToLogsOnError image: '{{ .ReleaseImage.haproxy_router }}' - imagePullPolicy: IfNotPresent command:🤖 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 `@scripts/auto-rebase/manifests_patches/011-ingress-deployment-access-logging.patch` around lines 97 - 102, The logs container in the ingress deployment patch declares imagePullPolicy twice, which can make the manifest ambiguous and break strict YAML validation. Update the logs container block under the AccessLoggingEnabled condition to keep only one imagePullPolicy entry, and verify the container spec in the ingress deployment patch remains valid after removing the duplicate.
🤖 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 `@assets/components/openshift-router/deployment.yaml`:
- Around line 23-30: The changed container specs are missing required hardening
and resource limits, especially the init-router initContainer and the
HAProxy/router blocks. Update the rebase source for the init-router and related
container definitions to include full securityContext settings (runAsNonRoot,
readOnlyRootFilesystem, allowPrivilegeEscalation: false, and dropping ALL
capabilities) plus CPU/memory limits for each container, then regenerate the
asset so the manifest reflects the hardened configuration.
- Around line 34-37: The container securityContext in the router deployment is
enabling privilege escalation, which conflicts with the restricted router pod
requirements. Update the securityContext for the HAProxy/router container to set
allowPrivilegeEscalation to false, and keep the existing readOnlyRootFilesystem
hardening in place. Use the securityContext block in the deployment manifest to
locate the change and ensure any exception would require an explicit SCC
justification elsewhere, not in this manifest.
In `@scripts/auto-rebase/last_rebase.sh`:
- Around line 1-2: The rebase launcher script is passing an extra literal
argument to rebase.sh and uses the wrong shell boilerplate. Update
last_rebase.sh so the invocation matches the intended argv shape by removing the
stray to token, and change the script header and safety settings to the required
bash form with set -euo pipefail. Keep the fix localized to the script
entrypoint so the rebase.sh call and shell setup are both corrected.
---
Outside diff comments:
In
`@scripts/auto-rebase/manifests_patches/011-ingress-deployment-access-logging.patch`:
- Around line 97-118: The new `logs` sidecar in the ingress deployment patch
needs hardening before it can be enabled. Update the sidecar definition added
under the `AccessLoggingEnabled`/`AccessLoggingSyslogAddress` condition to
include a `securityContext`, resource limits in addition to requests, and both
liveness and readiness probes so the generated manifest stays compliant. Use the
existing `logs` container block as the place to add these required fields.
- Around line 97-102: The logs container in the ingress deployment patch
declares imagePullPolicy twice, which can make the manifest ambiguous and break
strict YAML validation. Update the logs container block under the
AccessLoggingEnabled condition to keep only one imagePullPolicy entry, and
verify the container spec in the ingress deployment patch remains valid after
removing the duplicate.
🪄 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: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: 8a44bad4-50bb-45a8-8e41-f7058828c852
⛔ Files ignored due to path filters (2)
etcd/vendor/github.com/openshift/microshift/pkg/config/config.gois excluded by!**/vendor/**etcd/vendor/github.com/openshift/microshift/pkg/config/ingress.gois excluded by!**/vendor/**
📒 Files selected for processing (16)
Makefile.version.aarch64.varMakefile.version.x86_64.varassets/components/multus/release-multus-aarch64.jsonassets/components/multus/release-multus-x86_64.jsonassets/components/openshift-router/deployment.yamlassets/optional/operator-lifecycle-manager/kustomization.x86_64.yamlassets/optional/operator-lifecycle-manager/release-olm-aarch64.jsonassets/optional/operator-lifecycle-manager/release-olm-x86_64.jsonassets/release/release-aarch64.jsonassets/release/release-x86_64.jsonscripts/auto-rebase/changelog.txtscripts/auto-rebase/commits.txtscripts/auto-rebase/last_rebase.shscripts/auto-rebase/manifests_patches/010-ingress-deployment-clientCA.patchscripts/auto-rebase/manifests_patches/011-ingress-deployment-access-logging.patchscripts/auto-rebase/rebase.sh
| - name: init-router | ||
| imagePullPolicy: IfNotPresent | ||
| terminationMessagePolicy: FallbackToLogsOnError | ||
| command: ["/bin/bash", "-c", "cp -R -p /var/lib/haproxy/* /mnt/config/"] | ||
| volumeMounts: | ||
| - mountPath: /mnt/config | ||
| name: haproxy-config | ||
| image: '{{ .ReleaseImage.haproxy_router }}' |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Complete securityContext and resource limits for changed containers.
init-router has no securityContext/resources, and the changed HAProxy/router blocks only set partial hardening and requests. Add the required non-root/no-escalation/drop-capabilities settings and CPU/memory limits in the rebase source, then regenerate the asset.
As per path instructions, Kubernetes manifests require runAsNonRoot, readOnlyRootFilesystem, allowPrivilegeEscalation: false, dropping ALL capabilities, and resource limits on every container.
Also applies to: 65-68, 92-93, 253-256
🤖 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 `@assets/components/openshift-router/deployment.yaml` around lines 23 - 30, The
changed container specs are missing required hardening and resource limits,
especially the init-router initContainer and the HAProxy/router blocks. Update
the rebase source for the init-router and related container definitions to
include full securityContext settings (runAsNonRoot, readOnlyRootFilesystem,
allowPrivilegeEscalation: false, and dropping ALL capabilities) plus CPU/memory
limits for each container, then regenerate the asset so the manifest reflects
the hardened configuration.
Source: Path instructions
| securityContext: | ||
| # See https://bugzilla.redhat.com/2007246 | ||
| allowPrivilegeEscalation: true | ||
| readOnlyRootFilesystem: false | ||
| readOnlyRootFilesystem: true |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Do not enable privilege escalation in the restricted router pod.
allowPrivilegeEscalation: true conflicts with the restricted SCC annotation and the manifest hardening rules. If HAProxy truly requires this, use a narrowly scoped justification/SCC change; otherwise set it to false.
Proposed fix
- allowPrivilegeEscalation: true
+ allowPrivilegeEscalation: falseAs per coding guidelines, container manifests must flag allowPrivilegeEscalation: true; as per path instructions, Kubernetes manifests should use allowPrivilegeEscalation: false.
📝 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.
| securityContext: | |
| # See https://bugzilla.redhat.com/2007246 | |
| allowPrivilegeEscalation: true | |
| readOnlyRootFilesystem: false | |
| readOnlyRootFilesystem: true | |
| securityContext: | |
| # See https://bugzilla.redhat.com/2007246 | |
| allowPrivilegeEscalation: false | |
| readOnlyRootFilesystem: true |
🤖 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 `@assets/components/openshift-router/deployment.yaml` around lines 34 - 37, The
container securityContext in the router deployment is enabling privilege
escalation, which conflicts with the restricted router pod requirements. Update
the securityContext for the HAProxy/router container to set
allowPrivilegeEscalation to false, and keep the existing readOnlyRootFilesystem
hardening in place. Use the securityContext block in the deployment manifest to
locate the change and ensure any exception would require an explicit SCC
justification elsewhere, not in this manifest.
Sources: Coding guidelines, Path instructions
| #!/bin/bash -x | ||
| ./scripts/auto-rebase/rebase.sh to "registry.ci.openshift.org/ocp/release-5:5.0.0-0.nightly-2026-07-01-125918" "registry.ci.openshift.org/ocp-arm64/release-5-arm64:5.0.0-0.nightly-arm64-2026-07-02-035219" | ||
| ./scripts/auto-rebase/rebase.sh to "registry.ci.openshift.org/ocp/release-5:5.0.0-0.nightly-2026-07-05-172708" "registry.ci.openshift.org/ocp-arm64/release-5-arm64:5.0.0-0.nightly-arm64-2026-07-06-035219" |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Fix the rebase invocation and shell boilerplate.
to is being passed as a literal argument, so rebase.sh gets the wrong argv shape. This file also violates the shell-script rule: use #!/usr/bin/bash and set -euo pipefail.
🔧 Proposed fix
-#!/bin/bash -x
-./scripts/auto-rebase/rebase.sh to "registry.ci.openshift.org/ocp/release-5:5.0.0-0.nightly-2026-07-05-172708" "registry.ci.openshift.org/ocp-arm64/release-5-arm64:5.0.0-0.nightly-arm64-2026-07-06-035219"
+#!/usr/bin/bash
+set -euo pipefail
+./scripts/auto-rebase/rebase.sh \
+ "registry.ci.openshift.org/ocp/release-5:5.0.0-0.nightly-2026-07-05-172708" \
+ "registry.ci.openshift.org/ocp-arm64/release-5-arm64:5.0.0-0.nightly-arm64-2026-07-06-035219"📝 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.
| #!/bin/bash -x | |
| ./scripts/auto-rebase/rebase.sh to "registry.ci.openshift.org/ocp/release-5:5.0.0-0.nightly-2026-07-01-125918" "registry.ci.openshift.org/ocp-arm64/release-5-arm64:5.0.0-0.nightly-arm64-2026-07-02-035219" | |
| ./scripts/auto-rebase/rebase.sh to "registry.ci.openshift.org/ocp/release-5:5.0.0-0.nightly-2026-07-05-172708" "registry.ci.openshift.org/ocp-arm64/release-5-arm64:5.0.0-0.nightly-arm64-2026-07-06-035219" | |
| #!/usr/bin/bash | |
| set -euo pipefail | |
| ./scripts/auto-rebase/rebase.sh \ | |
| "registry.ci.openshift.org/ocp/release-5:5.0.0-0.nightly-2026-07-05-172708" \ | |
| "registry.ci.openshift.org/ocp-arm64/release-5-arm64:5.0.0-0.nightly-arm64-2026-07-06-035219" |
🤖 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 `@scripts/auto-rebase/last_rebase.sh` around lines 1 - 2, The rebase launcher
script is passing an extra literal argument to rebase.sh and uses the wrong
shell boilerplate. Update last_rebase.sh so the invocation matches the intended
argv shape by removing the stray to token, and change the script header and
safety settings to the required bash form with set -euo pipefail. Keep the fix
localized to the script entrypoint so the rebase.sh call and shell setup are
both corrected.
Source: Coding guidelines
|
/test e2e-aws-tests |
pacevedom
force-pushed
the
rebase-rebase-5.0-5.0.0-0.nightly-2026-07-05-172708_amd64-2026-07-05_arm64-2026-07-06
branch
from
8c653c5 to
bbf433c
Compare
|
/test ocp-full-conformance-rhel-eus /test e2e-aws-tests |
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
scripts/auto-rebase/manifests_patches/011-ingress-deployment-access-logging.patch (2)
97-119: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winDuplicate
imagePullPolicykey inlogscontainer.Line 99 and line 102 both set
imagePullPolicy: IfNotPresentin the same container spec.🐛 Proposed fix
- name: logs imagePullPolicy: IfNotPresent terminationMessagePolicy: FallbackToLogsOnError image: '{{ .ReleaseImage.haproxy_router }}' - imagePullPolicy: IfNotPresent command:🤖 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 `@scripts/auto-rebase/manifests_patches/011-ingress-deployment-access-logging.patch` around lines 97 - 119, The logs container spec in the ingress deployment patch has a duplicated imagePullPolicy entry, which should be removed so the container definition is valid. Update the logs container block in the rsyslog sidecar section to keep only one imagePullPolicy field, and verify the rest of the container fields in the same template remain unchanged.
97-119: 🔒 Security & Privacy | 🟠 Major | ⚡ Quick winAdd resource limits and securityContext to the new
logssidecar.The
logscontainer only definesrequests(cpu/memory), nolimits, and has nosecurityContext— unlike theroutercontainer in the same file, which setsreadOnlyRootFilesystem: true. As per path instructions, containers should define resource limits and a hardenedsecurityContext(runAsNonRoot,readOnlyRootFilesystem,allowPrivilegeEscalation: false, dropped capabilities).🔒 Proposed fix
- name: logs imagePullPolicy: IfNotPresent terminationMessagePolicy: FallbackToLogsOnError image: '{{ .ReleaseImage.haproxy_router }}' + securityContext: + readOnlyRootFilesystem: true + allowPrivilegeEscalation: false + capabilities: + drop: + - ALL command: - /sbin/rsyslogd - -n - -i - /tmp/rsyslogd.pid - -f - /etc/rsyslog/rsyslog.conf resources: requests: cpu: 50m memory: 128Mi + limits: + cpu: 100m + memory: 256MiAs per path instructions,
**/*.{yaml,yml}manifests needsecurityContext: runAsNonRoot, readOnlyRootFilesystem, allowPrivilegeEscalation: false, dropped capabilities, and resource limits on every container.🤖 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 `@scripts/auto-rebase/manifests_patches/011-ingress-deployment-access-logging.patch` around lines 97 - 119, The new logs sidecar added under the AccessLoggingEnabled block is missing required hardening and resource limits. Update the logs container in the ingress deployment patch to add CPU/memory limits alongside the existing requests, and add a securityContext with runAsNonRoot, readOnlyRootFilesystem, allowPrivilegeEscalation set to false, and dropped capabilities, matching the hardened pattern used for the router container in the same manifest.Source: Path instructions
🤖 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 `@assets/components/openshift-router/deployment.yaml`:
- Around line 345-357: The kube-api-access projected volume is using an
owner-read-only default mode that blocks the restricted SCC non-root UID from
reading the projected token and CA cert. Update the projected volume in the
deployment manifest for kube-api-access to use the standard service-account
token permission mode of 420 instead of the current value so token and ca.crt
remain readable without runAsUser or fsGroup.
---
Outside diff comments:
In
`@scripts/auto-rebase/manifests_patches/011-ingress-deployment-access-logging.patch`:
- Around line 97-119: The logs container spec in the ingress deployment patch
has a duplicated imagePullPolicy entry, which should be removed so the container
definition is valid. Update the logs container block in the rsyslog sidecar
section to keep only one imagePullPolicy field, and verify the rest of the
container fields in the same template remain unchanged.
- Around line 97-119: The new logs sidecar added under the AccessLoggingEnabled
block is missing required hardening and resource limits. Update the logs
container in the ingress deployment patch to add CPU/memory limits alongside the
existing requests, and add a securityContext with runAsNonRoot,
readOnlyRootFilesystem, allowPrivilegeEscalation set to false, and dropped
capabilities, matching the hardened pattern used for the router container in the
same manifest.
🪄 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: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: 21d7a7c6-3978-42f8-aa1b-30b9701eb162
⛔ Files ignored due to path filters (2)
etcd/vendor/github.com/openshift/microshift/pkg/config/config.gois excluded by!**/vendor/**etcd/vendor/github.com/openshift/microshift/pkg/config/ingress.gois excluded by!**/vendor/**
📒 Files selected for processing (16)
Makefile.version.aarch64.varMakefile.version.x86_64.varassets/components/multus/release-multus-aarch64.jsonassets/components/multus/release-multus-x86_64.jsonassets/components/openshift-router/deployment.yamlassets/optional/operator-lifecycle-manager/kustomization.x86_64.yamlassets/optional/operator-lifecycle-manager/release-olm-aarch64.jsonassets/optional/operator-lifecycle-manager/release-olm-x86_64.jsonassets/release/release-aarch64.jsonassets/release/release-x86_64.jsonscripts/auto-rebase/changelog.txtscripts/auto-rebase/commits.txtscripts/auto-rebase/last_rebase.shscripts/auto-rebase/manifests_patches/010-ingress-deployment-clientCA.patchscripts/auto-rebase/manifests_patches/011-ingress-deployment-access-logging.patchscripts/auto-rebase/rebase.sh
✅ Files skipped from review due to trivial changes (10)
- Makefile.version.x86_64.var
- scripts/auto-rebase/last_rebase.sh
- assets/components/multus/release-multus-aarch64.json
- Makefile.version.aarch64.var
- assets/components/multus/release-multus-x86_64.json
- assets/optional/operator-lifecycle-manager/release-olm-aarch64.json
- assets/release/release-aarch64.json
- assets/optional/operator-lifecycle-manager/release-olm-x86_64.json
- assets/release/release-x86_64.json
- scripts/auto-rebase/changelog.txt
🚧 Files skipped from review as they are similar to previous changes (4)
- scripts/auto-rebase/manifests_patches/010-ingress-deployment-clientCA.patch
- scripts/auto-rebase/rebase.sh
- scripts/auto-rebase/commits.txt
- assets/optional/operator-lifecycle-manager/kustomization.x86_64.yaml
| - name: kube-api-access | ||
| projected: | ||
| defaultMode: 0400 | ||
| sources: | ||
| - serviceAccountToken: | ||
| expirationSeconds: 3600 | ||
| path: token | ||
| - configMap: | ||
| name: kube-root-ca.crt | ||
| items: | ||
| - key: ca.crt | ||
| path: ca.crt | ||
| - downwardAPI: |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect the relevant manifest section with line numbers.
FILE="assets/components/openshift-router/deployment.yaml"
sed -n '300,410p' "$FILE" | cat -n
# Look for pod/container security context and any user/group settings.
rg -n "securityContext|runAsUser|runAsGroup|fsGroup|supplementalGroups|defaultMode|serviceAccountToken|kube-api-access" "$FILE"
# Find the router container image/user hints elsewhere in the repo.
rg -n "openshift-router|router.*user|runAsNonRoot|runAsUser|fsGroup" assets components pkg docs . -g '!vendor' -g '!deps' -g '!assets/optional/**'Repository: openshift/microshift
Length of output: 37313
🏁 Script executed:
#!/bin/bash
set -euo pipefail
FILE="assets/components/openshift-router/deployment.yaml"
# Show the pod spec and the router container security context.
sed -n '1,120p' "$FILE" | cat -n
# Show the full volume block around kube-api-access.
sed -n '336,360p' "$FILE" | cat -n
# Show any explicit runAsUser/runAsGroup/fsGroup values in this manifest.
rg -n "runAsUser|runAsGroup|fsGroup|runAsNonRoot|securityContext" "$FILE"Repository: openshift/microshift
Length of output: 6938
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect the restricted SCC used by the router service account.
rg -n "name: restricted|fsGroup:|runAsUser:|supplementalGroups:|required-scc|router" assets/controllers/openshift-default-scc-manager assets/components/openshift-router -g '*.yaml'
# Show the router deployment section around the security context and mounts again.
sed -n '1,130p' assets/components/openshift-router/deployment.yaml | cat -n
# Show the restricted SCC snippet if present.
sed -n '1,120p' assets/controllers/openshift-default-scc-manager/0000_20_kube-apiserver-operator_00_scc-restricted.yaml | cat -nRepository: openshift/microshift
Length of output: 1963
Use 420 for the kube-api-access projection
This pod has no runAsUser/fsGroup, so the restricted SCC’s non-root UID can’t read token/ca.crt with owner-read-only permissions. 420 matches the usual projected service-account token mode.
🤖 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 `@assets/components/openshift-router/deployment.yaml` around lines 345 - 357,
The kube-api-access projected volume is using an owner-read-only default mode
that blocks the restricted SCC non-root UID from reading the projected token and
CA cert. Update the projected volume in the deployment manifest for
kube-api-access to use the standard service-account token permission mode of 420
instead of the current value so token and ca.crt remain readable without
runAsUser or fsGroup.
|
@pacevedom: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
1 participant
Summary by CodeRabbit