Skip to content

Conversation

@omer-vishlitzky
Copy link
Contributor

@omer-vishlitzky omer-vishlitzky commented Dec 7, 2025

https://issues.redhat.com/browse/ACM-27290

Summary

  • Fix of ACM-21309
  • Updates GenerateInsecurePolicyJSON to include the docker transport.
  • Explicitly adds insecureAcceptAnything for registry.redhat.io and registry.access.redhat.com.

Reason

The previous fix (#7807) was insufficient because:

  1. It targeted docker-daemon (local) instead of docker (remote) transport used by podman pull.
  2. OCP 4.19+ systems appear to have specific signature policies (for more info see commit message) that override the global default setting. Explicitly defining the registry scopes is required to bypass these restrictions, as verified by the customer.

@coderabbitai
Copy link

coderabbitai bot commented Dec 7, 2025

Walkthrough

Modifies GenerateInsecurePolicyJSON to add docker transport entries with insecureAcceptAnything policy for the default docker entry and two Red Hat registries (registry.redhat.io and registry.access.redhat.com). Corresponding test assertions expanded to verify these new policy entries.

Changes

Cohort / File(s) Summary
Docker transport policy additions
pkg/mirrorregistries/generator.go
Adds new docker transport entries under "transports" key configuring insecureAcceptAnything for empty-key default entry, registry.redhat.io, and registry.access.redhat.com alongside existing docker-daemon policy.
Test coverage expansion
pkg/mirrorregistries/mirror_registry_test.go
Extends TestGeneratePolicyJSON_ForceInsecure assertions to verify insecureAcceptAnything is applied to docker transport default entry and the two additional registry targets when ForceInsecurePolicy is enabled.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

  • Verify the logic for adding docker transport entries to the policy JSON structure is correct and follows existing patterns
  • Confirm that insecureAcceptAnything policy is appropriately applied to all three transport targets (default, registry.redhat.io, registry.access.redhat.com)
  • Review test assertions adequately validate all new policy entries and edge cases
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Cache: Disabled due to data retention organization setting

Knowledge base: Disabled due to Reviews -> Disable Knowledge Base setting

📥 Commits

Reviewing files that changed from the base of the PR and between 8af184a and efcced9.

📒 Files selected for processing (2)
  • pkg/mirrorregistries/generator.go (1 hunks)
  • pkg/mirrorregistries/mirror_registry_test.go (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
  • pkg/mirrorregistries/mirror_registry_test.go
  • pkg/mirrorregistries/generator.go

Comment @coderabbitai help to get the list of available commands and usage tips.

@openshift-ci openshift-ci bot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Dec 7, 2025
@openshift-ci openshift-ci bot requested review from carbonin and danmanor December 7, 2025 11:09
@openshift-ci
Copy link

openshift-ci bot commented Dec 7, 2025

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: omer-vishlitzky
Once this PR has been reviewed and has the lgtm label, please assign mlorenzofr for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (1)
internal/controller/controllers/agentserviceconfig_controller.go (1)

2316-2413: Upgrade script behavior is robust but auto-wipe on repeated failures is risky

The postgresUpgradeScript implements a solid flow (attempt tracking, fresh-install short‑circuit, version checks, stale postmaster.pid cleanup, upgrade via run-postgresql, and readiness polling). Two aspects are worth double‑checking:

  1. Data wipe after MAX_ATTEMPTS
    After more than MAX_ATTEMPTS the script does rm -rf /var/lib/pgsql/data/* and exits 0, assuming all data is safely reconstructible from Kubernetes CRs. If any user or operator data lives only in Postgres, or if repeated failures are caused by configuration issues (e.g., wrong MIN/TARGET or too‑short TIMEOUT for a legitimately large DB), this becomes destructive. Consider:

    • Restricting auto‑wipe to clearly transient failure modes, or
    • Gating it behind an explicit opt‑in flag/annotation, or
    • Failing hard (non‑zero exit) once attempts are exhausted, leaving recovery to an operator.
  2. Tight coupling between image and hardcoded MIN/TARGET versions
    The script relies on PG_VERSION matching PostgresMinVersion/PostgresTargetVersion constants. If an operator overrides DATABASE_IMAGE to a different major without updating these constants in code, you can get:

    • Unsupported version failures (CURRENT_VERSION != MIN_VERSION) that will still count towards MAX_ATTEMPTS and eventually trigger the wipe.
    • Or a mismatch where the image’s actual major doesn’t align with the TARGET_VERSION encoded into the script.

    If custom DATABASE_IMAGE overrides are expected, consider tying the script’s version expectations to configuration (e.g., env‑based values or the new helpers in images.go) and/or clearly documenting that the DB image and these constants must be kept in lockstep.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Cache: Disabled due to data retention organization setting

Knowledge base: Disabled due to Reviews -> Disable Knowledge Base setting

📥 Commits

Reviewing files that changed from the base of the PR and between 69ea114 and 8af184a.

📒 Files selected for processing (4)
  • internal/controller/controllers/agentserviceconfig_controller.go (3 hunks)
  • internal/controller/controllers/images.go (2 hunks)
  • pkg/mirrorregistries/generator.go (1 hunks)
  • pkg/mirrorregistries/mirror_registry_test.go (1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**

⚙️ CodeRabbit configuration file

-Focus on major issues impacting performance, readability, maintainability and security. Avoid nitpicks and avoid verbosity.

Files:

  • pkg/mirrorregistries/generator.go
  • pkg/mirrorregistries/mirror_registry_test.go
  • internal/controller/controllers/images.go
  • internal/controller/controllers/agentserviceconfig_controller.go
🧬 Code graph analysis (1)
internal/controller/controllers/agentserviceconfig_controller.go (1)
internal/controller/controllers/images.go (3)
  • DatabaseImage (50-52)
  • PostgresTargetVersion (33-33)
  • PostgresMinVersion (34-34)
🔇 Additional comments (4)
pkg/mirrorregistries/generator.go (1)

122-132: Docker transport entries correctly extend insecure policy behavior

Adding the docker transport (default, registry.redhat.io, and registry.access.redhat.com) with insecureAcceptAnything cleanly aligns policy.json with how podman pull resolves transports and overrides per‑registry policies when ForceInsecurePolicy is enabled. The structure matches the existing docker-daemon map and looks sound.

pkg/mirrorregistries/mirror_registry_test.go (1)

351-359: Test coverage accurately reflects new docker transport policy

The additional assertions for the docker transport (default, registry.redhat.io, registry.access.redhat.com) correctly mirror the generator behavior and will catch regressions in the policy layout.

internal/controller/controllers/images.go (1)

30-36: Postgres defaults and accessors are consistent and maintainable

Centralizing the PostgreSQL target/minimum versions and default image, and wiring DatabaseImage() plus the new helper accessors through getEnvVar, keeps configuration consistent with the rest of the image helpers while still allowing overrides via env vars. No issues spotted.

Also applies to: 51-60

internal/controller/controllers/agentserviceconfig_controller.go (1)

2067-2124: Postgres readinessProbe and upgrade initContainer wiring look correct

The postgres container’s pg_isready Exec readinessProbe and the postgres-upgrade initContainer both use the same DatabaseImage() and PVC (postgresdb), and the initContainer is correctly wired via InitContainers = []corev1.Container{postgresUpgradeInitContainer}. This should ensure upgrades run before the main DB comes up and that readiness reflects actual DB availability. No structural issues spotted here.

Also applies to: 2253-2255

@omer-vishlitzky omer-vishlitzky force-pushed the fix/ACM-21309-policy-json branch from 8af184a to 5d84da5 Compare December 7, 2025 11:14
@openshift-ci openshift-ci bot added size/S Denotes a PR that changes 10-29 lines, ignoring generated files. and removed size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Dec 7, 2025
@codecov
Copy link

codecov bot commented Dec 7, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 43.50%. Comparing base (69ea114) to head (efcced9).
⚠️ Report is 4 commits behind head on master.

Additional details and impacted files

Impacted file tree graph

@@           Coverage Diff           @@
##           master    #8493   +/-   ##
=======================================
  Coverage   43.49%   43.50%           
=======================================
  Files         411      411           
  Lines       71076    71087   +11     
=======================================
+ Hits        30916    30924    +8     
- Misses      37406    37408    +2     
- Partials     2754     2755    +1     
Files with missing lines Coverage Δ
pkg/mirrorregistries/generator.go 77.61% <100.00%> (+4.39%) ⬆️

... and 3 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

The previous fix (PR openshift#7807) was insufficient as it only configured the
'docker-daemon' transport. However, 'podman pull' uses the 'docker' transport.

Additionally, RHCOS 4.19 ships with a restrictive /etc/containers/policy.json
(see OCPBUGS-55106) that explicitly enforces signature verification for
'registry.redhat.io' and 'registry.access.redhat.com'. These specific scopes
take precedence over the global 'default' insecure setting.

This commit updates GenerateInsecurePolicyJSON to explicitly set
'insecureAcceptAnything' for the 'docker' transport, specifically overriding
the entries for Red Hat registries to shadow system defaults.
@omer-vishlitzky omer-vishlitzky force-pushed the fix/ACM-21309-policy-json branch from 5d84da5 to efcced9 Compare December 7, 2025 11:37
@omer-vishlitzky omer-vishlitzky changed the title fix(ACM-21309): Explicitly set docker transport in policy.json ACM-27290: Explicitly set docker transport in policy.json Dec 7, 2025
@openshift-ci-robot openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Dec 7, 2025
@openshift-ci-robot
Copy link

openshift-ci-robot commented Dec 7, 2025

@omer-vishlitzky: This pull request references ACM-27290 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the bug to target the "4.21.0" version, but no target version was set.

In response to this:

Summary

  • Updates GenerateInsecurePolicyJSON to include the docker transport.
  • Explicitly adds insecureAcceptAnything for registry.redhat.io and registry.access.redhat.com.

Reason

The previous fix (#7807) was insufficient because:

  1. It targeted docker-daemon (local) instead of docker (remote) transport used by podman pull.
  2. OCP 4.19+ systems appear to have specific signature policies (for more info see commit message) that override the global default setting. Explicitly defining the registry scopes is required to bypass these restrictions, as verified by the customer.

Instructions 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 openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci-robot
Copy link

openshift-ci-robot commented Dec 7, 2025

@omer-vishlitzky: This pull request references ACM-27290 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the bug to target the "4.21.0" version, but no target version was set.

In response to this:

Summary

  • Fix of ACM-21309
  • Updates GenerateInsecurePolicyJSON to include the docker transport.
  • Explicitly adds insecureAcceptAnything for registry.redhat.io and registry.access.redhat.com.

Reason

The previous fix (#7807) was insufficient because:

  1. It targeted docker-daemon (local) instead of docker (remote) transport used by podman pull.
  2. OCP 4.19+ systems appear to have specific signature policies (for more info see commit message) that override the global default setting. Explicitly defining the registry scopes is required to bypass these restrictions, as verified by the customer.

Instructions 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 openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci-robot
Copy link

openshift-ci-robot commented Dec 8, 2025

@omer-vishlitzky: This pull request references ACM-27290 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the bug to target the "4.21.0" version, but no target version was set.

In response to this:

https://issues.redhat.com/browse/ACM-27290

Summary

  • Fix of ACM-21309
  • Updates GenerateInsecurePolicyJSON to include the docker transport.
  • Explicitly adds insecureAcceptAnything for registry.redhat.io and registry.access.redhat.com.

Reason

The previous fix (#7807) was insufficient because:

  1. It targeted docker-daemon (local) instead of docker (remote) transport used by podman pull.
  2. OCP 4.19+ systems appear to have specific signature policies (for more info see commit message) that override the global default setting. Explicitly defining the registry scopes is required to bypass these restrictions, as verified by the customer.

Instructions 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 openshift-eng/jira-lifecycle-plugin repository.

Comment on lines +122 to +132
"docker": map[string]interface{}{
"": []map[string]string{
{"type": "insecureAcceptAnything"},
},
"registry.redhat.io": []map[string]string{
{"type": "insecureAcceptAnything"},
},
"registry.access.redhat.com": []map[string]string{
{"type": "insecureAcceptAnything"},
},
},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be helpful to add some documentation here (or in the GenerateInsecurePolicyJSON docstring) to clarify the reasoning behind this behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. size/S Denotes a PR that changes 10-29 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants