Uploaded image for project: 'OpenShift Request For Enhancement'
  1. OpenShift Request For Enhancement
  2. RFE-5541

Provide the ability to revoke system:admin kubeconfig credentials

XMLWordPrintable

    • Icon: Feature Request Feature Request
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • None
    • Installer, oc
    • None
    • Product / Portfolio Work
    • None
    • False
    • None
    • None
    • None
    • None
    • None
    • None

      1. Proposed title of this feature request

      Provide the ability to revoke system:admin kubeconfig credentials

      2. What is the nature and description of the request?

      The OpenShift installer generates two default forms of administrator credentials laid down in the install directory:

      • ../auth/kubeconfig
      • ../auth/kubeadmin-password

       

      The ../auth/kubeconfig file contains a certificate-based (CN=system:admin) authentication profile of a user named “admin”, with a validity period of 10 years.  (installer code)

      • This credential is sometimes called the admin kubeconfig.  
      • This credential is also sometimes mistaken for the kubeadmin account, which relates to the kubeadmin-password file referenced above.  
      • This credential grants the user cluster-admin root privileges across the platform.  
      • This credential has a correlating CA Issuer that is responsible for issuing no other certificates
      • This CA Issuer key is destroyed and lost after installation.  The CA certificate is trusted through its presence in a configmap.
      • Should this credential be compromised, there should be a way to invalidate it for security purposes of protecting the cluster from misuse.  

      The primary requirement is to be able to ease the process of “revoking” the existing “system:admin” certificate, which by its nature implies the removal of the CA that signed the certificate from the API trust authority.  This KCS, while effective, largely requires manual work that is fragile, error prone, and difficult for customers to implement easily. 

      3. Why does the customer need this? (List the business requirements here)

      For better overall system security.

      4. List any affected packages or components.

      installer, oc

       

      Additional Information:

      See the first 3 comments on this Jira for additional important data.

              mak.redhat.com Marcos Entenza Garcia
              rhn-gps-bward Brian Ward (Inactive)
              None
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                None
                None