Uploaded image for project: 'OpenShift Bugs'
  1. OpenShift Bugs
  2. OCPBUGS-1428

service account token secret reference

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Critical Critical
    • None
    • 4.11.0
    • OLM
    • None
    • None
    • OLM 227 - Spyro the Dragon
    • 1
    • Rejected
    • False
    • Hide

      None

      Show
      None

      Description of problem:

      When using an OperatorGroup attached to a service account, AND if there is a secret present in the namespace, the operator installation will fail with the message:
      the service account does not have any API secret sa=testx-ns/testx-sa
      This issue seems similar to https://bugzilla.redhat.com/show_bug.cgi?id=2094303 - which was resolved in 4.11.0 - however, the new element now, is that the presence of a secret in the namespace  is causing the issue.
      The name of the secret seems significant - suggesting something somewhere is depending on the order that secrets are listed in. For example, If the secret in the namespace is called "asecret", the problem does not occur. If it is called "zsecret", the problem always occurs.
      "zsecret" is not a "kubernetes.io/service-account-token". The issue I have raised here relates to Opaque secrets - zsecret is an Opaque secret. The issue may apply to other types of secrets, but specifically my issue is that when there is an opaque secret present in the namespace, the operator install fails as described. I aught to be allowed to have an opaque secret present in the namespace where I am installing the operator.

      Version-Release number of selected component (if applicable):

      4.11.0 & 4.11.1

      How reproducible:

      100% reproducible

      Steps to Reproduce:

      1.Create namespace: oc new-project testx-ns
      2. oc apply -f api-secret-issue.yaml
      
      

      Actual results:

       

      Expected results:

       

      Additional info:

      API YAML:

      cat api-secret-issue.yaml 
      apiVersion: v1
      kind: Secret
      metadata:
        name: zsecret
        namespace: testx-ns
        annotations:
         kubernetes.io/service-account.name: testx-sa
      type: Opaque
      stringData:
        mykey: mypass

      apiVersion: v1
      kind: ServiceAccount
      metadata:
        name: testx-sa
        namespace: testx-ns

      kind: OperatorGroup
      apiVersion: operators.coreos.com/v1
      metadata:
        name: testx-og
        namespace: testx-ns
      spec:
        serviceAccountName: "testx-sa"
        targetNamespaces:
        - testx-ns

      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
        name: testx-role
        namespace: testx-ns
      rules:

      • apiGroups: ["*"]
          resources: ["*"]
          verbs: ["*"] 
          

      apiVersion: rbac.authorization.k8s.io/v1
      kind: RoleBinding
      metadata:
        name: testx-rolebinding
        namespace: testx-ns
      roleRef:
        apiGroup: rbac.authorization.k8s.io
        kind: Role
        name: testx-role
      subjects:

      • kind: ServiceAccount
          name: testx-sa
          namespace: testx-ns

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: etcd-operator
        namespace: testx-ns
      spec:
        channel: singlenamespace-alpha
        installPlanApproval: Automatic
        name: etcd
        source: community-operators
        sourceNamespace: openshift-marketplace

              agreene1991 Alexander Greene (Inactive)
              rhn-support-vsolanki Vimal Solanki
              Xia Zhao Xia Zhao
              Votes:
              0 Vote for this issue
              Watchers:
              11 Start watching this issue

                Created:
                Updated:
                Resolved: