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

cert-syncer is forcibly changing secret type without retaining content

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done-Errata
    • Icon: Undefined Undefined
    • 4.16.0
    • 4.15, 4.16.0
    • kube-apiserver
    • None
    • No
    • False
    • Hide

      None

      Show
      None
    • Hide
      Linked to a public facing bug so doesn't need it's own RN.

      Cause: clusters born before 4.7 version have several secrets with SecretTypeTLS
      Consequence: on upgrade to 4.16 this cluster will have this secret deleted and re-created with `kubernetes.io/tls` type. The removal may race and contents of this secret may be lost
      Fix: secret type change now happens atomically
      Result: clusters created before 4.7 now can safely upgrade to 4.16
      Show
      Linked to a public facing bug so doesn't need it's own RN. Cause: clusters born before 4.7 version have several secrets with SecretTypeTLS Consequence: on upgrade to 4.16 this cluster will have this secret deleted and re-created with `kubernetes.io/tls` type. The removal may race and contents of this secret may be lost Fix: secret type change now happens atomically Result: clusters created before 4.7 now can safely upgrade to 4.16
    • Release Note Not Required
    • In Progress

      Description of problem:

      `ensureSigningCertKeyPair` and `ensureTargetCertKeyPair` are always updating secret type. if the secret requires metadata update, its previous content will not be retained    

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

          

      How reproducible:

          

      Steps to Reproduce:

          1. Install 4.6 cluster (or make sure installer-generated secrets have `type: SecretTypeTLS` instead of `type: kubernetes.io/tls`
          2. Run secret sync
          3. Check secret contents
          

      Actual results:

          Secret was regenerated with new content

      Expected results:

      Existing content should be preserved, content is not modified

      Additional info:

          This causes api-int CA update for clusters born in 4.6 or earlier.

              vrutkovs@redhat.com Vadim Rutkovsky
              vrutkovs@redhat.com Vadim Rutkovsky
              Rahul Gangwar Rahul Gangwar
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

                Created:
                Updated:
                Resolved: