github.com/jlmeeker/kismatic@v1.10.1-0.20180612190640-57f9005a1f1a/docs/design-decisions/kubernetes-rbac.md (about)

     1  # Enable RBAC support in Kubernetes
     2  
     3  Status: Implemented
     4  
     5  # Motivation
     6  As of Kubernetes v1.6.0, the role-based access control authorizer API was promoted
     7  to beta. RBAC is quickly becoming the recommended authorization scheme for
     8  Kubernetes clusters, as it is API driven and more powerful than ABAC. RBAC is also
     9  the preferred authorization mechanism in large enterprises.
    10  
    11  We should enable RBAC support out of the box when installing Kubernetes with Kismatic.
    12  
    13  # Admin user
    14  We will continue enabling both basic-auth and certificate-based authentication.
    15  Ideally, we would only support cert-based auth, but accessing the dashboard would
    16  require running `kubectl proxy` locally, which might not always be an option. 
    17  
    18  Kismatic will bootstrap a single user, `admin`, that will be used by the cluster administrator.
    19  This user will be accessible via the generated admin certificate, and via HTTP basic
    20  auth when accessing the dashboard.
    21  
    22  The generated `admin` user will be part of the `system:masters` group, which is
    23  bound to the `cluster-admin` role by the kubernetes default bindings.
    24  
    25  Kismatic will use the `admin` user to perform all current management operations.
    26  Defining roles and permissions for Kismatic functionality is out of scope for this
    27  proposal, but one can imagine building a set of roles that will be Kismatic specific.
    28  For example, a specific role could be created for Kismatic that will allow it to
    29  create persistent volumes on behalf of the user (when using the storage features).
    30  
    31  # Upgrade considerations
    32  Current clusters deployed with Kismatic are using ABAC for authorization. Removing
    33  ABAC support in the same release that RBAC is enabled would most likely break 
    34  existing clusters and applications, as they are relying on the permissive ABAC policy.
    35  
    36  For this reason, we will continue to enable both ABAC and RBAC authorizers, and 
    37  deprecate ABAC. Users will be responsible for creating the necessary RBAC policy
    38  according to their needs. After doing this, users may manually remove the ABAC 
    39  authorizer (by modifying the flag and restarting API servers), or they may wait
    40  until the next KET release where ABAC will be removed.
    41  
    42