Bug 1935909 - New CSV using ServiceAccount named "default" stuck in Pending during upgrade
Summary: New CSV using ServiceAccount named "default" stuck in Pending during upgrade
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: OLM
Version: 4.5
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 4.8.0
Assignee: Ben Luddy
QA Contact: Bruno Andrade
URL:
Whiteboard:
Depends On:
Blocks: 1936707
TreeView+ depends on / blocked
 
Reported: 2021-03-05 19:07 UTC by Ben Luddy
Modified: 2022-10-11 09:19 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: ClusterServiceVersions required associated ServiceAccounts to either have no ownerReferences or to have an ownerReference to the CSV in question. Consequence: The "default" ServiceAccount, which is not created as part of operator installation, could not be satisfied as a CSV requirement if its .metadata.ownerReferences was not empty. Fix: ClusterServiceVersions now require associated ServiceAccounts to either have no ownerReferences to CSVs or to have an ownerReference to the CSV in question. Result: ServiceAccounts with only non-ClusterServiceVersion ownerReferences can satisfy the requirements of any ClusterServiceVersion.
Clone Of:
Environment:
Last Closed: 2021-07-27 22:51:38 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github operator-framework operator-lifecycle-manager pull 2029 0 None closed Bug 1935909: Allow non-CSV-owned ServiceAccounts to satisfy CSV requirements. 2021-03-11 14:37:32 UTC
Red Hat Product Errata RHSA-2021:2438 0 None None None 2021-07-27 22:52:05 UTC

Description Ben Luddy 2021-03-05 19:07:16 UTC
Description of problem:

If an operator's ClusterServiceVersion specifies serviceAccountName "default", and the ServiceAccount "default" has an owner reference to a resource that is not a ClusterServiceVersion, then the CSV's status will indicate that its ServiceAccount requirement is PresentNotSatisfied:

- Kind:     ServiceAccount
  Message:  Service account is not owned by this ClusterServiceVersion
  Name:     default
  Status:   PresentNotSatisfied

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

Regressed as part of a fix for another issue that has since been backported to 4.5.z (https://bugzilla.redhat.com/show_bug.cgi?id=1904584).

How reproducible: Always

Steps to Reproduce:
1. Ensure that a ServiceAccount exists named "default" and with an owner reference to any namespaced resource that is NOT a ClusterServiceVersion.
2. Create a CSV whose deployment strategy permissions use serviceAccountName "default". Small sample CSV here:

apiVersion: operators.coreos.com/v1alpha1
kind: ClusterServiceVersion
metadata:
  name: sad-csv
  namespace: operators
spec:
  apiservicedefinitions: {}
  customresourcedefinitions: {}
  displayName: Sad Operator
  install:
    spec:
      permissions:
      - serviceAccountName: default
        rules: []
      deployments:
      - name: sad-deployment
        spec:
          selector:
            matchLabels:
              app: sad
          template:
            metadata:
              labels:
                app: sad
            spec:
              containers:
              - image: bitnami/nginx
                name: sad
    strategy: deployment
  installModes:
  - supported: true
    type: OwnNamespace
  - supported: true
    type: SingleNamespace
  - supported: true
    type: MultiNamespace
  - supported: true
    type: AllNamespaces

3. Look at the status of the created CSV.

Actual results:

status:
  requirementStatus:
  - group: ""
    kind: ServiceAccount
    message: Service account is not owned by this ClusterServiceVersion
    name: default
    status: PresentNotSatisfied
    version: v1

Expected results:

status:
  requirementStatus:
  - group: ""
    kind: ServiceAccount
    message: ""
    name: default
    status: Present
    version: v1

Comment 2 Bruno Andrade 2021-03-09 19:42:57 UTC
Looks good, steps used to reproduce it:

OCP Version: 4.8.0-0.nightly-2021-03-09-115915
OLM version: 0.17.0
git commit: 8ccfdb9a30b7162e6330fb599a8d837d1e44758b


1) Create the namespace and the default service account is present

oc get sa default -n test-operators -o yaml     
apiVersion: v1
imagePullSecrets:
- name: default-dockercfg-p8xvt
kind: ServiceAccount
metadata:
  creationTimestamp: "2021-03-09T16:00:37Z"
  name: default
  namespace: test-operators
  resourceVersion: "55575"
  uid: a038effe-79f1-4137-b956-fe8347e9b256
secrets:
- name: default-token-mrnk9
- name: default-dockercfg-p8xvt

2) Create the operator group
3) Create the CSV as oriented
4) Check if CSV installation succeeds.
  phase: Succeeded
  reason: InstallSucceeded
  requirementStatus:
  - group: ""
    kind: ServiceAccount
    message: ""
    name: default
    status: Present
    version: v1

Comment 7 errata-xmlrpc 2021-07-27 22:51:38 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: OpenShift Container Platform 4.8.2 bug fix and security update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2021:2438


Note You need to log in before you can comment on or make changes to this bug.