{"id":"operators-and-updates-share-security-constraint-hierarchy","text":"Operators and cluster updates are constrained by the same security hierarchy: install-time locks (FIPS, CPU partitioning) permanently bound both the operator runtime environment and the update path, runtime TLS/IPsec enforcement governs both operator and update traffic, and API governance controls both operator CRD stability and update version ordering","truth_value":"IN","source":"","source_url":"","source_hash":"","justifications":[{"type":"SL","antecedents":["operator-lifecycle-bounded-by-platform-constraints","security-constrains-entire-update-path"],"outlist":[],"label":"depth-6 — operators and updates are independently constrained by security (d5 each), revealing that security is the shared constraint root for all platform lifecycle activities"}],"dependents":[],"metadata":{},"explanation":{"steps":[{"node":"operators-and-updates-share-security-constraint-hierarchy","truth_value":"IN","reason":"SL justification valid","antecedents":["operator-lifecycle-bounded-by-platform-constraints","security-constrains-entire-update-path"],"label":"depth-6 — operators and updates are independently constrained by security (d5 each), revealing that security is the shared constraint root for all platform lifecycle activities"},{"node":"operator-lifecycle-bounded-by-platform-constraints","truth_value":"IN","reason":"SL justification valid","antecedents":["operator-driven-immutable-platform-model","lifecycle-constrained-across-heterogeneous-fleet"],"label":"depth-5 synthesis — operators are powerful but not omnipotent; lifecycle constraints bound their scope"},{"node":"operator-driven-immutable-platform-model","truth_value":"IN","reason":"SL justification valid","antecedents":["immutable-nodes-with-singleton-operator-control","operator-delivery-through-console-integration"],"label":"depth-3 — both platform delivery and node management converge on operators as the universal control plane"},{"node":"immutable-nodes-with-singleton-operator-control","truth_value":"IN","reason":"SL justification valid","antecedents":["node-config-immutable-delivery-pipeline","singleton-resource-naming-convention","mco-rollout-process"],"label":"The MCO pipeline delivers changes to immutable nodes, and the singleton pattern ensures exactly one configuration authority — together they prevent configuration drift and split-brain"},{"node":"node-config-immutable-delivery-pipeline","truth_value":"IN","reason":"SL justification valid","antecedents":["rhcos-immutable-update-model","image-mirror-configuration-pipeline"],"label":"Both OS updates and registry configuration use the same MCO-mediated immutable delivery pattern"},{"node":"rhcos-immutable-update-model","truth_value":"IN","reason":"SL justification valid","antecedents":["rhcos-nodes-immutable","rhcos-rpm-ostree-updates","image-layering-verify-rpm-ostree-status"],"label":"Three facets of the same immutable-OS operational model"},{"node":"rhcos-nodes-immutable","truth_value":"IN","reason":"premise"},{"node":"rhcos-rpm-ostree-updates","truth_value":"IN","reason":"premise"},{"node":"image-layering-verify-rpm-ostree-status","truth_value":"IN","reason":"premise"},{"node":"image-mirror-configuration-pipeline","truth_value":"IN","reason":"SL justification valid","antecedents":["oc-mirror-generates-idms","mirror-config-applied-via-mco-registries-conf","icsp-deprecated-in-favor-of-idms"],"label":"End-to-end mirror configuration from generation to node application"},{"node":"oc-mirror-generates-idms","truth_value":"IN","reason":"premise"},{"node":"mirror-config-applied-via-mco-registries-conf","truth_value":"IN","reason":"premise"},{"node":"icsp-deprecated-in-favor-of-idms","truth_value":"IN","reason":"premise"},{"node":"singleton-resource-naming-convention","truth_value":"IN","reason":"SL justification valid","antecedents":["oauth-config-singleton-named-cluster","flowcollector-must-be-named-cluster","clusterautoscaler-singleton-named-default","storage-operator-singleton-named-cluster","powermonitor-must-be-named-power-monitor"],"label":"A recurring platform pattern worth capturing as a cross-cutting architectural constraint"},{"node":"oauth-config-singleton-named-cluster","truth_value":"IN","reason":"premise"},{"node":"flowcollector-must-be-named-cluster","truth_value":"IN","reason":"premise"},{"node":"clusterautoscaler-singleton-named-default","truth_value":"IN","reason":"premise"},{"node":"storage-operator-singleton-named-cluster","truth_value":"IN","reason":"premise"},{"node":"powermonitor-must-be-named-power-monitor","truth_value":"IN","reason":"premise"},{"node":"mco-rollout-process","truth_value":"IN","reason":"premise"},{"node":"operator-delivery-through-console-integration","truth_value":"IN","reason":"SL justification valid","antecedents":["operator-catalog-to-deployment-pipeline","console-plugin-integration-model"],"label":"OLM is the shared dependency — it drives both operator deployment and console plugin registration, revealing OLM as the universal operator delivery bus"},{"node":"operator-catalog-to-deployment-pipeline","truth_value":"IN","reason":"SL justification valid","antecedents":["fbc-modernizes-operator-catalog-format","olm-full-lifecycle-chain"],"label":"FBC defines the catalog format; OLM defines the installation chain — together they form the complete operator delivery pipeline"},{"node":"fbc-modernizes-operator-catalog-format","truth_value":"IN","reason":"SL justification valid","antecedents":["fbc-default-since-ocp-411-sqlite-deprecated","opm-validate-checks-catalog","fbc-skiprange-prunes-update-graph"],"label":"FBC as the complete modern catalog toolchain"},{"node":"fbc-default-since-ocp-411-sqlite-deprecated","truth_value":"IN","reason":"premise"},{"node":"opm-validate-checks-catalog","truth_value":"IN","reason":"premise"},{"node":"fbc-skiprange-prunes-update-graph","truth_value":"IN","reason":"premise"},{"node":"olm-full-lifecycle-chain","truth_value":"IN","reason":"SL justification valid","antecedents":["olm-resource-chain","olm-subscription-tracks-channel","subscription-triggers-installplan-then-csv","installplan-required-spec-fields"],"label":"End-to-end OLM lifecycle with each resource's role clarified"},{"node":"olm-resource-chain","truth_value":"IN","reason":"premise"},{"node":"olm-subscription-tracks-channel","truth_value":"IN","reason":"premise"},{"node":"subscription-triggers-installplan-then-csv","truth_value":"IN","reason":"premise"},{"node":"installplan-required-spec-fields","truth_value":"IN","reason":"premise"},{"node":"console-plugin-integration-model","truth_value":"IN","reason":"SL justification valid","antecedents":["consoleplugin-backend-must-use-https","console-plugins-registered-via-olm","console-config-singleton-named-cluster","consoleplugin-compat-level-1"],"label":"Console plugin architecture with security, registration, and stability guarantees"},{"node":"consoleplugin-backend-must-use-https","truth_value":"IN","reason":"premise"},{"node":"console-plugins-registered-via-olm","truth_value":"IN","reason":"premise"},{"node":"console-config-singleton-named-cluster","truth_value":"IN","reason":"premise"},{"node":"consoleplugin-compat-level-1","truth_value":"IN","reason":"premise"},{"node":"lifecycle-constrained-across-heterogeneous-fleet","truth_value":"IN","reason":"SL justification valid","antecedents":["platform-lifecycle-bounded-at-install-and-update","node-fleet-heterogeneous-runtime-model"],"label":"depth-2 lifecycle boundaries + depth-2 heterogeneous node model combine into a constrained lifecycle management problem"},{"node":"platform-lifecycle-bounded-at-install-and-update","truth_value":"IN","reason":"SL justification valid","antecedents":["install-time-irreversible-constraints","version-coupling-and-update-governance"],"label":"depth-2 — lifecycle rigidity at both install and update boundaries constrains all platform evolution"},{"node":"install-time-irreversible-constraints","truth_value":"IN","reason":"SL justification valid","antecedents":["ocp-security-fips-install-time-only","cpu-partitioning-install-time-only","network-plugin-selected-at-install-time"],"label":"Three independent install-time-only constraints form a coherent class of irreversible cluster decisions"},{"node":"ocp-security-fips-install-time-only","truth_value":"IN","reason":"premise"},{"node":"cpu-partitioning-install-time-only","truth_value":"IN","reason":"premise"},{"node":"network-plugin-selected-at-install-time","truth_value":"IN","reason":"premise"},{"node":"version-coupling-and-update-governance","truth_value":"IN","reason":"SL justification valid","antecedents":["cnv-version-must-match-ocp-version","cnv-update-ocp-first-then-cnv","hcp-update-order-management-mce-hosted","ocp-rollback-not-supported"],"label":"Version coupling rules and forward-only updates form a strict upgrade governance model"},{"node":"cnv-version-must-match-ocp-version","truth_value":"IN","reason":"premise"},{"node":"cnv-update-ocp-first-then-cnv","truth_value":"IN","reason":"premise"},{"node":"hcp-update-order-management-mce-hosted","truth_value":"IN","reason":"premise"},{"node":"ocp-rollback-not-supported","truth_value":"IN","reason":"premise"},{"node":"node-fleet-heterogeneous-runtime-model","truth_value":"IN","reason":"SL justification valid","antecedents":["rhcos-immutable-update-model","windows-node-architectural-divergence"],"label":"depth-2 — RHCOS and Windows nodes have incompatible runtime models coexisting in one cluster"},{"node":"rhcos-immutable-update-model","truth_value":"IN","reason":"SL justification valid","antecedents":["rhcos-nodes-immutable","rhcos-rpm-ostree-updates","image-layering-verify-rpm-ostree-status"],"label":"Three facets of the same immutable-OS operational model"},{"node":"rhcos-nodes-immutable","truth_value":"IN","reason":"premise"},{"node":"rhcos-rpm-ostree-updates","truth_value":"IN","reason":"premise"},{"node":"image-layering-verify-rpm-ostree-status","truth_value":"IN","reason":"premise"},{"node":"windows-node-architectural-divergence","truth_value":"IN","reason":"SL justification valid","antecedents":["windows-nodes-not-crio","windows-containers-ovn-hybrid-networking"],"label":"Windows nodes require distinct runtime and networking from Linux nodes"},{"node":"windows-nodes-not-crio","truth_value":"IN","reason":"premise"},{"node":"windows-containers-ovn-hybrid-networking","truth_value":"IN","reason":"premise"},{"node":"security-constrains-entire-update-path","truth_value":"IN","reason":"SL justification valid","antecedents":["unified-security-from-install-through-api-governance","progressive-update-across-heterogeneous-fleet"],"label":"Connects security enforcement (depth-4) with update strategy (depth-4) — updates cannot weaken security invariants"},{"node":"unified-security-from-install-through-api-governance","truth_value":"IN","reason":"SL justification valid","antecedents":["api-governance-enforces-stability-and-immutability","security-enforced-at-install-runtime-and-api-boundary"],"label":"depth-3 API governance (stability+immutability) and depth-2 security enforcement (install+runtime+API) together show that security is not layered independently but forms a single enforcement chain where install-time decisions constrain what runtime and API governance must enforce"},{"node":"api-governance-enforces-stability-and-immutability","truth_value":"IN","reason":"SL justification valid","antecedents":["api-governance-spans-stability-and-admission","immutability-enforced-at-resource-and-platform-levels"],"label":"depth-2 API stability/admission + depth-2 immutability enforcement combine into a comprehensive API governance model"},{"node":"api-governance-spans-stability-and-admission","truth_value":"IN","reason":"SL justification valid","antecedents":["api-stability-tiered-guarantee-model","webhook-admission-enforcement-model"],"label":"depth-2 — API governance has both a temporal dimension (stability tiers) and a runtime dimension (admission enforcement)"},{"node":"api-stability-tiered-guarantee-model","truth_value":"IN","reason":"SL justification valid","antecedents":["compatibility-level-1-stable-12-months","compatibility-level-definitions","consoleplugin-compat-level-1","image-content-source-policy-v1alpha1-level4","api-tier3-default-for-unassigned-groups"],"label":"API consumers can assess migration risk by checking compatibility level"},{"node":"compatibility-level-1-stable-12-months","truth_value":"IN","reason":"premise"},{"node":"compatibility-level-definitions","truth_value":"IN","reason":"premise"},{"node":"consoleplugin-compat-level-1","truth_value":"IN","reason":"premise"},{"node":"image-content-source-policy-v1alpha1-level4","truth_value":"IN","reason":"premise"},{"node":"api-tier3-default-for-unassigned-groups","truth_value":"IN","reason":"premise"},{"node":"webhook-admission-enforcement-model","truth_value":"IN","reason":"SL justification valid","antecedents":["webhook-communication-requires-tls","webhook-max-timeout-13-seconds","webhook-never-invoked-on-own-kind","webhook-required-fields"],"label":"These four constraints collectively define the safety envelope for admission webhooks — TLS for integrity, timeout cap for availability, self-exclusion for stability, required fields for correctness"},{"node":"webhook-communication-requires-tls","truth_value":"IN","reason":"premise"},{"node":"webhook-max-timeout-13-seconds","truth_value":"IN","reason":"premise"},{"node":"webhook-never-invoked-on-own-kind","truth_value":"IN","reason":"premise"},{"node":"webhook-required-fields","truth_value":"IN","reason":"premise"},{"node":"immutability-enforced-at-resource-and-platform-levels","truth_value":"IN","reason":"SL justification valid","antecedents":["resource-field-immutability-pattern","install-time-irreversible-constraints"],"label":"depth-2 — immutability operates at both the resource field level and the cluster-wide level"},{"node":"resource-field-immutability-pattern","truth_value":"IN","reason":"SL justification valid","antecedents":["route-host-immutable","ingress-domain-field-immutable-unique","ingressclass-controller-immutable"],"label":"Three independent immutable-field constraints form a write-once identity pattern"},{"node":"route-host-immutable","truth_value":"IN","reason":"premise"},{"node":"ingress-domain-field-immutable-unique","truth_value":"IN","reason":"premise"},{"node":"ingressclass-controller-immutable","truth_value":"IN","reason":"premise"},{"node":"install-time-irreversible-constraints","truth_value":"IN","reason":"SL justification valid","antecedents":["ocp-security-fips-install-time-only","cpu-partitioning-install-time-only","network-plugin-selected-at-install-time"],"label":"Three independent install-time-only constraints form a coherent class of irreversible cluster decisions"},{"node":"ocp-security-fips-install-time-only","truth_value":"IN","reason":"premise"},{"node":"cpu-partitioning-install-time-only","truth_value":"IN","reason":"premise"},{"node":"network-plugin-selected-at-install-time","truth_value":"IN","reason":"premise"},{"node":"security-enforced-at-install-runtime-and-api-boundary","truth_value":"IN","reason":"SL justification valid","antecedents":["encryption-and-tls-infrastructure-model","webhook-admission-enforcement-model","install-time-irreversible-constraints"],"label":"depth-2 synthesis — three distinct enforcement points (install, runtime, API) form a unified security posture"},{"node":"encryption-and-tls-infrastructure-model","truth_value":"IN","reason":"SL justification valid","antecedents":["ocp-tls-four-profile-types","ipsec-cipher-aes-gcm-16-256","ipsec-pod-to-pod-transport-mode","ocp-410-san-certificate-requirement"],"label":"Four base beliefs about TLS/IPsec/certificates combine into a layered encryption model"},{"node":"ocp-tls-four-profile-types","truth_value":"IN","reason":"premise"},{"node":"ipsec-cipher-aes-gcm-16-256","truth_value":"IN","reason":"premise"},{"node":"ipsec-pod-to-pod-transport-mode","truth_value":"IN","reason":"premise"},{"node":"ocp-410-san-certificate-requirement","truth_value":"IN","reason":"premise"},{"node":"webhook-admission-enforcement-model","truth_value":"IN","reason":"SL justification valid","antecedents":["webhook-communication-requires-tls","webhook-max-timeout-13-seconds","webhook-never-invoked-on-own-kind","webhook-required-fields"],"label":"These four constraints collectively define the safety envelope for admission webhooks — TLS for integrity, timeout cap for availability, self-exclusion for stability, required fields for correctness"},{"node":"webhook-communication-requires-tls","truth_value":"IN","reason":"premise"},{"node":"webhook-max-timeout-13-seconds","truth_value":"IN","reason":"premise"},{"node":"webhook-never-invoked-on-own-kind","truth_value":"IN","reason":"premise"},{"node":"webhook-required-fields","truth_value":"IN","reason":"premise"},{"node":"install-time-irreversible-constraints","truth_value":"IN","reason":"SL justification valid","antecedents":["ocp-security-fips-install-time-only","cpu-partitioning-install-time-only","network-plugin-selected-at-install-time"],"label":"Three independent install-time-only constraints form a coherent class of irreversible cluster decisions"},{"node":"ocp-security-fips-install-time-only","truth_value":"IN","reason":"premise"},{"node":"cpu-partitioning-install-time-only","truth_value":"IN","reason":"premise"},{"node":"network-plugin-selected-at-install-time","truth_value":"IN","reason":"premise"},{"node":"progressive-update-across-heterogeneous-fleet","truth_value":"IN","reason":"SL justification valid","antecedents":["progressive-update-within-lifecycle-bounds","lifecycle-constrained-across-heterogeneous-fleet"],"label":"Update strategies assume orderly rollout but the fleet is fundamentally heterogeneous — combining reveals the tension between progressive updates and fleet diversity."},{"node":"progressive-update-within-lifecycle-bounds","truth_value":"IN","reason":"SL justification valid","antecedents":["platform-lifecycle-bounded-at-install-and-update","update-strategy-canary-and-control-plane-model"],"label":"depth-2 lifecycle boundaries define what is mutable; depth-1 update strategies define how mutations are applied — combining shows that update risk mitigation is bounded by irreversible install-time choices"},{"node":"platform-lifecycle-bounded-at-install-and-update","truth_value":"IN","reason":"SL justification valid","antecedents":["install-time-irreversible-constraints","version-coupling-and-update-governance"],"label":"depth-2 — lifecycle rigidity at both install and update boundaries constrains all platform evolution"},{"node":"install-time-irreversible-constraints","truth_value":"IN","reason":"SL justification valid","antecedents":["ocp-security-fips-install-time-only","cpu-partitioning-install-time-only","network-plugin-selected-at-install-time"],"label":"Three independent install-time-only constraints form a coherent class of irreversible cluster decisions"},{"node":"ocp-security-fips-install-time-only","truth_value":"IN","reason":"premise"},{"node":"cpu-partitioning-install-time-only","truth_value":"IN","reason":"premise"},{"node":"network-plugin-selected-at-install-time","truth_value":"IN","reason":"premise"},{"node":"version-coupling-and-update-governance","truth_value":"IN","reason":"SL justification valid","antecedents":["cnv-version-must-match-ocp-version","cnv-update-ocp-first-then-cnv","hcp-update-order-management-mce-hosted","ocp-rollback-not-supported"],"label":"Version coupling rules and forward-only updates form a strict upgrade governance model"},{"node":"cnv-version-must-match-ocp-version","truth_value":"IN","reason":"premise"},{"node":"cnv-update-ocp-first-then-cnv","truth_value":"IN","reason":"premise"},{"node":"hcp-update-order-management-mce-hosted","truth_value":"IN","reason":"premise"},{"node":"ocp-rollback-not-supported","truth_value":"IN","reason":"premise"},{"node":"update-strategy-canary-and-control-plane-model","truth_value":"IN","reason":"SL justification valid","antecedents":["ocp-canary-updates-custom-machineconfigpools","ocp-control-plane-only-update-even-minor-versions"],"label":"Two base beliefs about update strategies combine into a dual-scope risk mitigation model"},{"node":"ocp-canary-updates-custom-machineconfigpools","truth_value":"IN","reason":"premise"},{"node":"ocp-control-plane-only-update-even-minor-versions","truth_value":"IN","reason":"premise"},{"node":"lifecycle-constrained-across-heterogeneous-fleet","truth_value":"IN","reason":"SL justification valid","antecedents":["platform-lifecycle-bounded-at-install-and-update","node-fleet-heterogeneous-runtime-model"],"label":"depth-2 lifecycle boundaries + depth-2 heterogeneous node model combine into a constrained lifecycle management problem"},{"node":"platform-lifecycle-bounded-at-install-and-update","truth_value":"IN","reason":"SL justification valid","antecedents":["install-time-irreversible-constraints","version-coupling-and-update-governance"],"label":"depth-2 — lifecycle rigidity at both install and update boundaries constrains all platform evolution"},{"node":"install-time-irreversible-constraints","truth_value":"IN","reason":"SL justification valid","antecedents":["ocp-security-fips-install-time-only","cpu-partitioning-install-time-only","network-plugin-selected-at-install-time"],"label":"Three independent install-time-only constraints form a coherent class of irreversible cluster decisions"},{"node":"ocp-security-fips-install-time-only","truth_value":"IN","reason":"premise"},{"node":"cpu-partitioning-install-time-only","truth_value":"IN","reason":"premise"},{"node":"network-plugin-selected-at-install-time","truth_value":"IN","reason":"premise"},{"node":"version-coupling-and-update-governance","truth_value":"IN","reason":"SL justification valid","antecedents":["cnv-version-must-match-ocp-version","cnv-update-ocp-first-then-cnv","hcp-update-order-management-mce-hosted","ocp-rollback-not-supported"],"label":"Version coupling rules and forward-only updates form a strict upgrade governance model"},{"node":"cnv-version-must-match-ocp-version","truth_value":"IN","reason":"premise"},{"node":"cnv-update-ocp-first-then-cnv","truth_value":"IN","reason":"premise"},{"node":"hcp-update-order-management-mce-hosted","truth_value":"IN","reason":"premise"},{"node":"ocp-rollback-not-supported","truth_value":"IN","reason":"premise"},{"node":"node-fleet-heterogeneous-runtime-model","truth_value":"IN","reason":"SL justification valid","antecedents":["rhcos-immutable-update-model","windows-node-architectural-divergence"],"label":"depth-2 — RHCOS and Windows nodes have incompatible runtime models coexisting in one cluster"},{"node":"rhcos-immutable-update-model","truth_value":"IN","reason":"SL justification valid","antecedents":["rhcos-nodes-immutable","rhcos-rpm-ostree-updates","image-layering-verify-rpm-ostree-status"],"label":"Three facets of the same immutable-OS operational model"},{"node":"rhcos-nodes-immutable","truth_value":"IN","reason":"premise"},{"node":"rhcos-rpm-ostree-updates","truth_value":"IN","reason":"premise"},{"node":"image-layering-verify-rpm-ostree-status","truth_value":"IN","reason":"premise"},{"node":"windows-node-architectural-divergence","truth_value":"IN","reason":"SL justification valid","antecedents":["windows-nodes-not-crio","windows-containers-ovn-hybrid-networking"],"label":"Windows nodes require distinct runtime and networking from Linux nodes"},{"node":"windows-nodes-not-crio","truth_value":"IN","reason":"premise"},{"node":"windows-containers-ovn-hybrid-networking","truth_value":"IN","reason":"premise"}]}}