Local LDAP Linux User Accounts¶
You can create regular Linux user accounts using the StarlingX 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 StarlingX.
Note
For security reasons, it is recommended that ONLY admin level users be allowed to SSH to the nodes of the StarlingX. 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:
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 System Account Password Rules.
Login sessions are logged out automatically after about 15 minutes of inactivity.
After each unsuccessful login attempt, a 3 second delay is imposed before making another attempt. After five consecutive unsuccessful login attempts, further attempts are blocked for about five minutes. On further attempts within 5 minutes, the system will display a message such as:
Account locked due to 6 failed loginsNote
This delay is 3 seconds.
You are alerted on the 6th and subsequent attempts:
Account locked due to 6 failed loginsand an error message is displayed on subsequent attempts.
When you login to the console you are alerted on the 6th, and subsequent attempts:
The account is locked due to 5 failed logins (2 minutes left to unlock)When you login remotely using SSH, you have 3 attempts to try and login before an error
Permission denied (publickey,password)is displayed, during an SSH login session. You can continue to login by starting a new login session, until the user is locked out after 5 consecutive failed attempts. For security reasons, there is no reason or error displayed to the user.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.
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.
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.
See also
