docs/doc/source/security/kubernetes/introduction-to-user-management-6c0b13c6d325.rst

Introduction to User Management

User Management is the capability to configure unique users for your system, i.e. both system administrators and general end users. There are multiple user types and user account types in .

User Types

• 'sysadmin' Linux User

  The 'sysadmin' linux user is a special-case user for initial install only.

• System Administrators

  The system administrator user type is for managing the system infrastructure. A user of this type requires:

  • A Keystone user account

    The Keystone user account is used for access to services through the GUI, RESTAPIs, local or remote CLIs.

    • The bulk of the system infrastructure is managed through the GUI, RESTAPIs, local or remote CLIs.

  • A LDAP user account

    • The user account is used for access to physical hosts.
      • access is required to access local Ansible Playbooks or scripts for management of system infrastructure not covered by GUI, RESTAPIs, CLIs.
    • The user account is also used for access to kubernetes services through the kubernetes CLIs.
      • Kubernetes CLIs are required for management of system infrastructure not covered by GUI, RESTAPIs, CLIs, Ansible Playbooks, or scripts.

• End Users

  The end user user type is for managing hosted containerized applications on (for example, a containerized application). A user of this type requires:

  • A LDAP User Account
    • The user account is used for access to kubernetes services through the kubernetes GUI, RESTAPIs, local or remote CLIs.
      • It is for creating / managing end users kubernetes resources of containerized applications hosted by .
    • the user account can also be used for access to physical hosts.
      • access provides access to local Linux services (for example, hardware status,metrics) for the purposes of monitoring Linux resources (for example, interfaces) of end users' containerized applications hosted by .

User Account Types

• 'sysadmin' Linux User Account
  • The 'sysadmin' local Linux user account is created on the initial software install. The default initial password is: sysadmin. The installer is forced to change the password immediately on the first login as part of the install procedure.
  • The 'sysadmin' user has LINUX 'sudo all' capability and is a member of the root group. This user also has Kubernetes cluster-admin role, which allows it to do all operations in kubernetes environment. When executing source /etc/platform/openrc, the user becomes the keystone 'admin' user with 'admin' role, which allows it to do all operations in environment.
  • The 'sysadmin' linux user should only be used by end users for initial installation, i.e. do not use this as a shared user account. Do not use this as a shared account amongst your set of system administrators. Create unique user accounts (both keystone user accounts and user accounts) for each of your system administrators, with only the required privileges.
  • Do not remove the 'sysadmin' linux user. It is used internally by the platform.
• Keystone User Accounts

  • The Keystone users are required for access to services through the GUI, RESTAPIs, local or remote CLIs. The Keystone users are created / managed locally on the system.

  • There is a default 'admin' Keystone user (with 'admin' role) whose password is set to the same password as provided by the initial password change for the 'sysadmin' Linux user. Do not use this as a shared account amongst your set of system administrators. Create unique Keystone user accounts for each of your system administrators, with only the required privileges.

  • There are five static keystone roles for services:

    • admin - can run all commands.
    • configurator - is the same as admin, however it cannot add/remove users/groups (Keystone commands), add/remove system secrets (Barbican commands) nor add/remove trusted (system ca-certificate-install/uninstall commands).
    • operator - has read-only access to everything, however it can execute operational commands on hosts (example: lock/unlock, resets, power off/on) and can execute operational commands on subclouds (example: manage/unmanage, backup management).
    • member - is currently the same as reader role, however it may be used for managing additional capabilities in future.
    • reader - has read-only access to everything.

    For any user role other than admin, access to Keystone, Barbican apis is denied. However, the following commands are allowed where only that user information is shown in the output:

    • openstack project list
    • openstack user show <user>
    • openstack token issue
    • openstack project show
• LDAP User Accounts
  • users are required for access to local ansible playbooks / scripts and/or access to Kubernetes services through the Kubernetes CLIs.
  • There are two types of users/groups supported on :

    • Local - where Local users and groups are created locally on system.

    • Remote (for example, Windows Active Directory) - where users and groups are created remotely on an external system. The system accesses external system, according to configured access parameters, and discovers the remote users and groups. There can be up to 3 remote servers configured.

    • For both, the Local scenario and the remote scenario, a user (or members of a group), can be assigned linux privileges via a group/role-binding to a local linux group, specifically one or more of the following groups:

      • sudo group - provides sudo all capabilities.

      • sys_protected group - provides access to collect tool for collecting system diagnostic info.

        Note

        The collect tool also requires sudo capability.

      • root group - provides read access to log files.

      The Local scenario and the remote scenario, a user can also be assigned to Kubernetes privileges through a Kubernetes ClusterRoleBinding/RoleBinding to either an existing Kubernetes ClusterRole/Role or a new customer configured Kubernetes ClusterRole/Role.