starlingx
/
docs
Code Issues Proposed changes

Local/WAD ldap users sudo and local linux group assignment (stx 9.0) 

Added "sudo" and "sys_protected" privileges support for LDAP servers accessed using SSSD service

Story: 2010589
Task: 49410

Change-Id: Ia05edc04feb465c1b59a2a1e4cff26218b144788
Signed-off-by: Ngairangbam Mili <ngairangbam.mili@windriver.com>
This commit is contained in:
Ngairangbam Mili 2024-01-16 06:40:50 +00:00
parent b8d3ae4f68
commit 93e265fbf3
4 changed files with 310 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

38
doc/source/security/kubernetes/create-ldap-linux-accounts.rst
View File

@ -57,19 +57,46 @@ For convenience, identify the user's Keystone account user name in |prod-long|.
.. code-block:: none
Enter username to add to LDAP:
Enter username to add to LDAP: teamadmin
.. code-block:: none
Successfully added user user1 to LDAP
Successfully set password for user user1
Successfully added user teamadmin to LDAP
Successfully set password for user teamadmin
Warning : password is reset, user will be asked to change password at login
#. Specify whether the user should have sudo capabilities or not.
Enabling ``sudo`` privileges allows the LDAP users to execute the
following operations:
#. Specify a secondary user group for this |LDAP| user.
- ``sw_patch`` to unauthenticated endpoint
- ``docker`` and/or ``crictl`` commands to communicate with the respective daemons
- Utilities ``show-certs.sh`` and ``license-install`` (recovery only)
- IP configuration for local network setup
- Password change of local openldap users
- Access to restricted files, example: restricted logs
- Manual reboots
.. code-block:: none
Add teamadmin to sudoer list? (yes/NO): yes
Successfully added sudo access for user teamadmin to LDAP
#. Specify a secondary user group for this |LDAP| user. For example, ``sys_protected group``.
The purpose of having OpenLDAP/WAD users as a part of the ``sys_protected`` group on the |prod|
platform is to allow them to execute the |prod| system operations via
``source/etc/platform/openrc``. The LDAP user in the ``sys_protected`` group will be
equivalent to the special ``sysadmin`` bootstrap user, and will have the following:
- Keystone admin/admin identity and credentials
- Kubernetes ``/etc/kubernetes/admin.conf`` credentials
.. code-block:: none
Add user1 to secondary user group (yes/No):
Add teamadmin to secondary user group? (yes/NO): yes
Secondary group to add user to? [sys_protected]:
Successfully added user teamadmin to group cn=sys_protected,ou=Group,dc=cgcs,dc=local
#. Change the password duration.
@ -90,6 +117,7 @@ For convenience, identify the user's Keystone account user name in |prod-long|.
.. code-block:: none
Successfully modified user entry uid=teamadmin,ou=People,dc=cgcs,dc=local in LDAP
Updating password expiry to 2 days

1
doc/source/security/kubernetes/index-security-kub-81153c1254c3.rst
View File

@ -118,6 +118,7 @@ HTTPS Certificate Management
etcd-certificates-c1fc943e4a9c
kubernetes-certificates-f4196d7cae9c
starlingx-rest-api-applications-and-the-web-admin-server-cert-9196c5794834
local-ldap-certificates-4e1df1e39341
configure-rest-api-apps-and-web-admin-server-certs-after-inst-6816457ab95f
configure-docker-registry-certificate-after-installation-c519edbfe90a
oidc-client-dex-server-certificates-dc174462d51a

52
doc/source/security/kubernetes/local-ldap-certificates-4e1df1e39341.rst Normal file
View File

@ -0,0 +1,52 @@
.. _local-ldap-certificates-4e1df1e39341:
=======================
Local LDAP Certificates
=======================
The local |LDAP| server by default serves both HTTPS on port 636 and HTTP on port 389.
The HTTPS server certificate is issued by cert-manager ClusterIssuer
``system-local-ca`` and is managed internally by cert-manager. The certificate
will be automatically renewed when the expiration date approaches. The
certificate is called ``system-openldap-local-certificate`` with its secret
having the same name ``system-openldap-local-certificate`` in the
``deployment`` namespace. The server certificate and private key files are
stored in the ``/etc/ldap/certs/`` system directory.
In |DC| system, the |LDAP| service runs only in the central cloud. Clients in
the subcloud (|SSSD|, |LDAP| client tools) are configured so that they can
access the |LDAP| services in the central cloud using HTTPS. Thus,
``system-local-ca`` ClusterIssuer's certificate is installed in the subcloud as
a trusted |CA| certificate.
The insecure HTTP service is only supported for backward compatibility with
subclouds running older versions of |prod| that supports only HTTP. If no such
subclouds are present, the insecure HTTP service can be disabled by system
service parameter.
Run the following command to disable the insecure service:
.. code-block:: none
~(keystone_admin)]$ system service-parameter-add identity local-openldap insecure_service=disabled
If the service parameter already exists, run the following command:
.. code-block:: none
~(keystone_admin)]$ system service-parameter-modify identity local-openldap insecure_service=disabled
The insecure service can be enabled if it has been disabled. Run the following
command to enable the insecure service:
.. code-block:: none
~(keystone_admin)]$ system service-parameter-modify identity local-openldap insecure_service=enabled
After disabling or enabling the insecure local-openldap service, for the change
to take effect, apply the service parameter by running the following command:
.. code-block:: none
~(keystone_admin)]$ system service-parameter-apply identity --section local-openldap

235
doc/source/security/kubernetes/sssd-support-5fb6c4b0320b.rst
View File

@ -7,7 +7,7 @@ SSH User Authentication using Windows Active Directory (WAD)
By default, |SSH| to |prod| hosts supports authentication using the 'sysadmin'
Local Linux Account and |prod| Local |LDAP| Linux User Accounts. |SSH| can
also be optionally configured to support authentication with 1 or more remote
|LDAP| identity providers (such as Windows Active Directory (WAD)). Internally,
|LDAP| identity providers (such as |WAD|). Internally,
|SSH| uses |SSSD| service to provide NSS and PAM interfaces and a backend
system able to remotely connect to multiple different |LDAP| domains.
@ -56,7 +56,6 @@ The command to add |WAD| |CA| certificate:
system certificate-install --mode ssl_ca <AD CA certificate file>
---------------------
Add Remote WAD Domain
---------------------
@ -163,7 +162,7 @@ follows:
Default WAD Domain Configuration
---------------------------------
The default WAD domain configuration parameters are pre-configured. Main |SSSD|
The default |WAD| domain configuration parameters are pre-configured. Main |SSSD|
default configuration settings include:
- Offline Authentication is enabled, allowing users to still authenticate
@ -280,19 +279,233 @@ responsibility to clean up users' home directories that are no longer used.
SUDO Capability and Local Group Membership
------------------------------------------
Support of sudo users and local linux group membership (e.g. ``sys_protected``)
in |prod| platform is done locally after |WAD| users have been discovered by
|SSSD|.
This section describes how to enable the ``sudo`` and ``sys_protected`` privileges
for configured users in |WAD| servers.
For example:
The Linux specification stipulates that the GUID values in the range 0 to 99
should be statically allocated by the system and shall not be created by
applications. Therefore, a ``sudo`` group with GUID 27 and the ``root`` group
GUID 0 are special groups that cannot be created by the |SSSD| client interfacing
with the |WAD| server.
The ``sudo`` privileges can be assigned to |WAD| users using the ``sudo rules`` mechanism.
``Sudo rules`` are access control rules that define the users who are granted access,
the commands a user has access to, and the target hosts to which the rules
apply.
Enable Sudo Privileges for WAD Users
-------------------------------------
You can enable ``sudo All`` privileges for LDAP users from a remote |WAD| server.
Enabling ``sudo`` privileges allows the LDAP users to execute the following
operations:
- ``sw_patch`` to unauthenticated endpoint
- ``docker`` and/or ``crictl`` commands to communicate with the respective daemons
- Utilities ``show-certs.sh`` and ``license-install`` (recovery only)
- IP configuration for local network setup
- Password change of local openldap users
- Access to restricted files, example: restricted logs
- Manual reboots
Load Sudo Schema in WAD LDAP Server
-----------------------------------
The ``sudo rules`` schema is not a part of standard |WAD| installation. For |WAD|
servers, the schema needs to be loaded and installed using the ``ldifde``
utility.
LDAP ``sudo rules`` schema is contained in the package ``libsss-sudo``. The
schema will be loaded in ``/usr/share/doc/sudo-ldap/schema.ActiveDirectory.gz``
during system installation.
Install Schema
--------------
.. rubric:: |proc|
#. Extract the schema from ``schema.ActiveDirectory.gz`` and copy it in a file
on the |WAD| server.
#. Install the schema by running the following command on the |WAD| server:
.. code-block:: none
ldifde -v -i -f ``schema.ActiveDirectory.txt`` -j
.. rubric:: |result|
The following shows the successful loading of a schema:
.. code-block:: none
# To add the WAD-discovered user "pvtest1" to the group 'sudo'
sudo usermod -a -G sudo pvtest1@ad.wad-server.com
Importing directory from file ``schema.ActiveDirectory.txt``
Loading entries
…….
12 entries modified successfully.
The command has completed successfully
# To add the WAD-discovered user "pvtest1" to the group 'sys_protected'
sudo usermod -a -G sys_protected pvtest1@ad.wad-server.com
Create Directory Entry for Sudo Rules in WAD Server
---------------------------------------------------
The ``sudoers`` OU needs to be created on the domain root. This OU will hold all
the ``sudo rules`` defined using ``sudoRole`` object.
.. note::
The ``sudoers`` OU directory path will be automatically set as the
``ldap_sudo_search_base`` parameter value in the sssd configuration file
``/etc/sssd/sssd.conf``. The ``ldap_search_base`` parameter
must be set at the same level in the domain root as shown in the following example:
.. code-block:: none
ldap_search_base = CN=Users,DC=domain,DC=com (set using ``system service-parameter`` command)
ldap_sudo_search_base = OU=sudoers,DC=domain,DC=com (pre-configured in sssd configuration)
.. rubric:: |proc|
#. Create an ``ldif`` file with the following content:
.. code-block:: none
dn: OU=sudoers,DC= dc=domain,DC=com
changetype: add
objectClass: top
objectClass: organizationalUnit
ou: sudoers
#. Import the file by running the following command on the |WAD| server:
.. code-block:: none
ldifde -v -i -f "sudoers_ou.txt" -j
where, ``sudoers_ou.txt`` is the ``ldif`` file created in the previous step.
.. rubric:: |result|
The following shows the successful loading of the ``ldif`` file:
.. code-block:: none
Connecting to ``ad.domain.com``
Logging in as current user using SSPI
Importing directory from file "sudoers_ou.txt"
Loading entries
1: OU=sudoers,DC=domain,DC=com
Entry modified successfully
Create a Sudo Rule for a WAD User
---------------------------------
.. rubric:: |proc|
#. To assign ``sudo All`` privileges to a |WAD| user with name ``techadmin``, create
and load the following ``ldif`` file content:
.. code-block:: none
dn: CN=techadmin,OU=sudoers,DC=domain,DC=com
changetype: add
objectClass: top
objectClass: sudoRole
cn: techadmin
distinguishedName: CN=techadmin,OU=sudoers,DC=domain,DC=com
name: techadmin
sudoUser: techadmin
sudoHost: ALL
sudoRunAsUser: ALL
sudoCommand: ALL
#. Load the ``ldif`` file by running the following command on the |WAD| server:
.. code-block:: none
ldifde -v -i -f "sudo-rule.txt" -j
where, ``sudo-rule.txt`` is the ``ldif`` file created in the previous step.
.. rubric:: |result|
The following shows the successful loading of the ``ldif`` file:
.. code-block:: none
Connecting to "ad.domain.com"
Logging in as current user using SSPI
Importing directory from file "sudo-rule.txt"
Loading entries
1: CN=techadmin,OU=sudoers,DC=domain,DC=com
Entry modified successfully.
1 entry modified successfully.
The command has completed successfully
The ``sudo rules`` will be discovered by sssd service and cached in the |prod|
platform. The sssd logs in ``/var/log/sssd/sssd_ad.domain.log`` will show the
number of rules downloaded from |WAD| server that indicates that the ``sudo rules``
were received.
.. code-block:: none
(2023-02-28 22:35:16): [be[ad.domain.com]] [sdap_search_bases_ex_donee] (0x0400): Receiving data from base [OU=sudoers,DC=domain,DC=com]
(2023-02-28 22:35:16): [be[ad.domain.com]] [sdap_sudo_load_sudoers_done] (0x0200): Received 1 sudo rules
(2023-02-28 22:35:16): [be[ad.domain.com]] [sdap_sudo_refresh_done] (0x0400): Received 1 rules
Verify Sudo All Privileges for the WAD Sudo User
------------------------------------------------
SSH to the |prod| platform using the ``sudo`` user and verify that the user has
``sudo All`` privileges.
.. code-block:: none
techadmin@controller-0:~$ sudo -l
Password:
Matching Defaults entries for techadmin on controller-0:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin,
lecture=never,
secure_path=/usr/local/bin\:/usr/bin\:/bin\:/usr/local/sbin\:/usr/sbin\:/sbin,
lecture=never,
secure_path=/usr/local/bin\:/usr/bin\:/bin\:/usr/local/sbin\:/usr/sbin\:/sbin,
passprompt="Password: "
User techadmin may run the following commands on controller-0:
(ALL) ALL
techadmin@controller-0:~$
Creating a User in the Linux Sys_protected Group on a WAD Server
----------------------------------------------------------------
Create a ``sys_protected`` group in the |WAD| server and set the ``gidNumber`` to
345 to be the same as Linux ``sys_protected`` group. Add a |WAD| user (example:
techadmin) as a member in the ``sys_protected`` group. The ``sys_protected``
LDAP group and its member will be discovered and cached in the |prod| platform
by SSSD service.
To check if the |WAD| user has been added to the ``sys_protected`` group, SSH to
|prod| as the |WAD| user and check the groups the user is a member of.
.. code-block:: none
Linux controller-0 5.10.0-6-amd64 #1 SMP PREEMPT StarlingX Debian 5.10.162-1.stx.64 (2023-02-16) x86_64
Last login: Fri Mar 10 22:20:16 2023 from 10.10.10.254
techadmin@controller-0:~$ groups
domain users sys_protected
techadmin@controller-0:~$
.. note::
When creating a |WAD| user that will be discovered and created on the
|prod| Linux host as part of the ``users`` group, set the |WAD| user GUID value
to 100 that is the same as that of the Linux ``users`` group. The |WAD| user
UID should be set to a unique value within the Linux ``users`` group.
When a new |WAD| user is created using the Active Directory Users and Group
Administration tool, the **User must change password at next login**
checkbox must be unchecked, otherwise the user login to the |prod| host will fail.
-------------------------------------------
Default Local OpenLDAP Domain Configuration