Jay Boyd jboyd01

Session ID vs Display Name: Protocol Identity Confusion

Status: Architecture Issue Date: 2026-03-06 Impact: Medium - Causes developer confusion, complicates monitoring, blocks clean protocol evolution

Executive Summary

As of Feb 24 Service Catalog is now installed by two new Cluster Operators. Initially Service Catalog is not enabled/installed. To enable it, the cluster admin must create two custom resources as follows:

cat <<EOF | oc create -f -
apiVersion: operator.openshift.io/v1
kind: ServiceCatalogAPIServer
metadata:
  name: cluster
spec:
 logLevel: "Normal"

	<?xml version="1.0" encoding="UTF-8"?>
	<xccdf:Tailoring xmlns:xccdf="http://checklists.nist.gov/xccdf/1.2" id="xccdf_scap-workbench_tailoring_default">
	<xccdf:benchmark href="/usr/share/xml/scap/ssg/content/ssg-centos7-ds.xml"/>
	<xccdf:version time="2020-04-22T02:09:15">1</xccdf:version>
	<xccdf:Profile id="xccdf_com.hcl_profile_ssbe_passwords">
	<xccdf:title xmlns:xhtml="http://www.w3.org/1999/xhtml" xml:lang="en-US" override="true">PCI-DSS v3.2.1 Control Baseline for Red Hat Enterprise Linux 7 [CUSTOMIZED]</xccdf:title>
	<xccdf:description xmlns:xhtml="http://www.w3.org/1999/xhtml" xml:lang="en-US" override="true">Not applicable to CentOS Linux, included for reference only

	Ensures PCI-DSS v3.2.1 related security configuration settings are applied.</xccdf:description>
	<xccdf:select idref="xccdf_org.ssgproject.content_group_intro" selected="false"/>

	# Red Hat Subscription Manager Configuration File:

	# Unified Entitlement Platform Configuration
	[server]
	# Server hostname:
	hostname = subscription.rhsm.redhat.com

	# Server prefix:
	prefix = /subscription

	apiVersion: rbac.authorization.k8s.io/v1
	kind: ClusterRole
	metadata:
	name: system:service-catalog:aggregate-to-admin
	labels:
	rbac.authorization.k8s.io/aggregate-to-admin: "true"
	rules:
	- apiGroups:
	- "servicecatalog.k8s.io"
	attributeRestrictions: null

	#!/bin/bash

	for p in $(oc get pods -n kube-service-catalog -o name -l app=apiserver); do
	pod=$(sed -e 's/pod\///g'<<<$p)
	oc logs $pod -c apiserver -n kube-service-catalog > /tmp/artifacts/$pod.log
	done
	for p in $(oc get pods -n kube-service-catalog -o name -l app=controller-manager); do
	pod=$(sed -e 's/pod\///g'<<<$p)
	oc logs $pod -n kube-service-catalog > /tmp/artifacts/$pod.log
	done

	cat <<'EOF' \| oc create -f -
	apiVersion: rbac.authorization.k8s.io/v1
	kind: ClusterRole
	metadata:
	name: add-servicebindingfinalizers
	rules:
	- apiGroups:
	- servicecatalog.k8s.io
	resources:
	- servicebindings/finalizers

	I've got a BZ issue that indicates events are sometimes missing on service
	instances. I've been able to replicate it. Generally you see all events, but
	sometimes, it seems like the most recent events are not displayed. For
	instance, in my controller log I pull out all occurrences of "event.go" which
	shows the events that were set on (in this case) the instance. The instance was
	in an error condition for a bit (set to an invalid plan), but then the last
	action I did updated the plan to a valid plan:


	21:41:58.603293 1 event.go:221] Event(v1.ObjectReference{Kind:"ServiceInstance", Namespace:"default", Name:"myservice2",...... ResourceVersion:"126", FieldPath:""}): type: 'Warning' reason: 'ReferencesNonexistentServicePlan' References a non-existent ClusterServicePlan {ClusterServicePlanExternalName:"defaultXXX"} on ClusterServiceClass 4f6e6cf6-ffdd-425f-a2c7-3c9258ad246a {ClusterServiceClassExternalName:"example-starter-pack-service"} or there is more than one (found: 0)



	Spec:
	Cluster Service Class External Name: example-starter-pack-service
	Cluster Service Class Ref:
	Name: 4f6e6cf6-ffdd-425f-a2c7-3c9258ad246a
	Cluster Service Plan External Name: default
	Cluster Service Plan Ref:
	Name: 86064792-7ea2-467b-af93-ac9694d96d5b
	External ID: 20da0666-a570-11e8-97f3-0242ac110003

	Purpose
	Allow brokers to register callbacks (webhooks) that can be used for validation prior to the platform attempting to Create, Update or Delete (CUD) a Service Instance or Binding.

	There will likely be a lot of discussion on the actual implementation details, initially this proposal will just focus on surfacing the issue and proposing the use of pre-action validation so Brokers have an opportunity to indicate to the platform that an action will or will not be accepted for processing. Once the SIG has discussed and given general agreement, we'll drill into a detailed design.

	This feature allows a broker to register webhooks for precheck validation for Instances and Bindings. That is, if indicated by the broker, the Platform will invoke a validating webhook just prior to invoking the actual call to create, update or delete an Instance or Binding. The webhook will be invoked with the same parameters and payload as the actual create/update/delete operation, but this operation is a dry-run for Broker vali