Uploaded image for project: 'Machine Config Operator'
  1. Machine Config Operator
  2. MCO-240

Set or change 'core' user password via MachineConfig

XMLWordPrintable

    • Core user password via MC
    • False
    • False
    • Yellow
    • To Do
    • OCPSTRAT-51 - Set or change 'core' user password via MachineConfig
    • OCPSTRAT-51Set or change 'core' user password via MachineConfig
    • 100
    • 100% 100%
    • Hide

      The MCO team currently does not have capacity to complete this work in 4.12 given our other priorities. A Spike has been created for Sprint 223 to explore the viability of completing this work or handing it off to other folks.

      Show
      The MCO team currently does not have capacity to complete this work in 4.12 given our other priorities. A Spike has been created for Sprint 223 to explore the viability of completing this work or handing it off to other folks.
    • 0
    • 0

      Epic Goal

      • Users who disable ssh access in favor of `oc debug` are reliant on the OpenShift API being up between the supervisors and worker nodes. In order to troubleshoot or RCA a node problem, these users would like to be able to use password auth on /dev/console, which they can access via BMC or local keyboard.

      Why is this important?

      • While setting passwords hasn't been cool in some time, it can make sense if password auth is disabled in sshd (which it is by default).
      • There is a workaround: push an /etc/shadow.

      Scenarios

      1. A new node is failing to join the cluster and ssh/api access is not possible but a local console (via cloud provider or bare metal BMC). The administrator would like to pull logs to triage the joining problem.
      2. sshd is not enabled and the API connection to the kubelet is down (so no `oc debug node`) and the administrator needs to triage the problem and/or collect logs.

      Acceptance Criteria

      • Users can set and change a password on "core" via ignition (machineconfig).
      • Changing the core user password should not cause workload disruption
      • CI - MUST be running successfully with tests automated
      • Release Technical Enablement - Provide necessary release enablement details and documents.

      Done Checklist

      • CI - CI is running, tests are automated and merged.
      • Release Enablement <link to Feature Enablement Presentation>
      • DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
      • DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
      • DEV - Downstream build attached to advisory: <link to errata>
      • QE - Test plans in Polarion: <link or reference to Polarion>
      • QE - Automated tests merged: <link or reference to automated tests>
      • DOC - Downstream documentation merged: <link to meaningful PR>

            dkhater@redhat.com Dalia Khater
            rhn-support-mrussell Mark Russell
            John Kyros
            Votes:
            1 Vote for this issue
            Watchers:
            17 Start watching this issue

              Created:
              Updated:
              Resolved: