This is a clone of issue OCPBUGS-14698. The following is the description of the original issue:
—
Description of problem:
Creating an OperatorGroup resource having "name: cluster" causes major issues and we can't login to the cluster anymore.
After this command all "oc" commands fail including "oc login...". The console/oauth endpoint showed:
{"error":"server_error","error_description":"The authorization server encountered an unexpected condition that prevented it from fulfilling the request.","state":"c72af27d"}
Notes:
- Restarting the cluster doesn't solve the problem, it's a persistent.
- Reproduced with OpenShift 4.12.12 and 4.13.0 in different environments (ROSA, CRC...)
- Using a different name for the OperatorGroup is a simple workaround. The name "cluster" seems to cause the problem.
- It doesn't matter what namespace the OperatorGroup is created in or how the "spec" looks like
Version-Release number of selected component (if applicable):
How reproducible:
Repeatedly
Steps to Reproduce:
Steps to reproduce - by logged in as cluster-admin:
$ oc apply -f - <<EOF
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
name: cluster
spec: {}
EOF
Actual results:
Expected results:
Additional info:
The root cause seems to be that OLM overwrites the "cluster-admin" role
- clones
-
OCPBUGS-14698 Creating an OperatorGroup with "name: cluster" breaks the whole cluster
-
- Closed
-
- is blocked by
-
OCPBUGS-14698 Creating an OperatorGroup with "name: cluster" breaks the whole cluster
-
- Closed
-
- is documented by
-
OCPBUGS-23281 Update 4.14 release notes for 4.14.2 fix of OLM cluster role binding issue
-
- Closed
-
- links to
-
RHBA-2023:6837
OpenShift Container Platform 4.14.z bug fix update