docs/doc/source/security/kubernetes/local-ldap-linux-user-accounts.rst

.. eof1552681926485
.. _local-ldap-linux-user-accounts:

==============================
Local LDAP Linux User Accounts
==============================

You can create regular Linux user accounts using the |prod| |LDAP| service.

Local |LDAP| accounts are centrally managed on the active controller;  all
hosts in the cloud/cluster use the Local |LDAP| server on the active controller
for |SSH| and Console authentication.

The intended use of these accounts is to provide additional admin level user
accounts \(in addition to sysadmin\) that can |SSH| to the nodes of the |prod|.

.. note::
    For security reasons, it is recommended that ONLY admin level users be
    allowed to |SSH| to the nodes of the |prod|. Non-admin level users should
    strictly use remote |CLIs| or remote web GUIs.

Apart from being centrally managed, Local |LDAP| user accounts behave as any
local user account. They can be added to the sudoers list, and can acquire
Keystone administration credentials, Kubernetes kubectl, and helm
administrative commands as the Kubernetes admin user, when executing on the
active controller.

Local |LDAP| user accounts share the following set of attributes:


.. _local-ldap-linux-user-accounts-ul-d4q-g5c-5p:

-   The initial password is the name of the account.

-   The initial password must be changed immediately upon first login.

-   For complete details on password rules, see :ref:`System Account Password Rules <starlingx-system-accounts-system-account-password-rules>`.

-   Login sessions are logged out automatically after about 15 minutes of
    inactivity.

-   After each unsuccessful login attemt, a 15 second delay is imposed before
    making another attempt. If you attempt to login before 15 seconds the
    system will display a message such as:

    ``Account temporary locked (10 seconds left)``

    .. note:: On Debian-based |prod| systems, this delay is 3 seconds.

    -   After five consecutive unsuccessful login attempts, further attempts are
        blocked for about five minutes. On further attemps within 5 minutes, the
        system will display a message such as:

        ``Account locked due to 6 failed logins``

        .. note::

            On Debian-based |prod| systems, you are alerted on the 6th and
            subsequent attempts:

            ``Account locked due to 6 failed logins``

            and an error message is displayed on subsequent attempts:

            ``Maximum number of tries exceeded (5)``

        To clarify, on CentOS-based |prod| systems, the 5 minute block is not an
        absolute window, but a sliding one. That is, if you keep attempting to log
        in within those 5 minutes, the window keeps sliding and the you remain
        blocked. Therefore, you should not attempt any further login attempts for 5
        minutes after 5 unsuccessful login attempts.

        On Debian-based |prod| systems, 5 mins after the account is locked, the
        failed attempts will be reset and failed attempts re-counted.

-   All authentication attempts are recorded on the file /var/log/auth.log
    of the target host.

-   Home directories and passwords are backed up and restored by the system
    backup utilities. Note that only passwords are synced across hosts \(both
    |LDAP| users and **sysadmin**\). Home directories are not automatically
    synced and are local to that host.


.. _local-ldap-linux-user-accounts-section-kts-bvh-ynb:

--------------------------
Default LDAP User Accounts
--------------------------

The following Local |LDAP| user accounts are available by default on newly
deployed hosts, regardless of their personality:

**operator**
    A cloud administrative account, comparable to the default **admin**
    account used in the web management interface.

    This user account has access to all native Linux commands not requiring
    root or sudo privileges, and it's shell is preconfigured to have
    administrative access to StarlingX commands.

**admin**
    A host administrative account. It has access to all native Linux
    commands and is included in the sudoers list.

For increased security, the **admin** and **operator** accounts must be used
from the console ports of the hosts; no |SSH| access is allowed.


.. _local-ldap-linux-user-accounts-ul-h22-ql4-tz:

-   These accounts serve as system access redundancies in the event that |SSH|
    access is unavailable. In the event of any issues with connectivity, user
    lockout, or **sysadmin** passwords being forgotten or not getting propagated
    properly, the presence of these accounts can be essential in gaining access
    to the deployment and rectifying things. This is why these accounts are
    restricted to the console port only, as a form of “manual over-ride.” The
    **operator** account enables access to the cloud deployment only, without
    giving unabated sudo access to the entire system.

.. seealso::

    :ref:`Create LDAP Linux Accounts <create-ldap-linux-accounts>`