From 93e265fbf3308f47475d3eba4f182fbfcb41306d Mon Sep 17 00:00:00 2001 From: Ngairangbam Mili Date: Tue, 16 Jan 2024 06:40:50 +0000 Subject: [PATCH] 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 --- .../kubernetes/create-ldap-linux-accounts.rst | 38 ++- .../index-security-kub-81153c1254c3.rst | 1 + .../local-ldap-certificates-4e1df1e39341.rst | 52 ++++ .../kubernetes/sssd-support-5fb6c4b0320b.rst | 235 +++++++++++++++++- 4 files changed, 310 insertions(+), 16 deletions(-) create mode 100644 doc/source/security/kubernetes/local-ldap-certificates-4e1df1e39341.rst diff --git a/doc/source/security/kubernetes/create-ldap-linux-accounts.rst b/doc/source/security/kubernetes/create-ldap-linux-accounts.rst index 2bfa7f8d6..02af8187e 100644 --- a/doc/source/security/kubernetes/create-ldap-linux-accounts.rst +++ b/doc/source/security/kubernetes/create-ldap-linux-accounts.rst @@ -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 diff --git a/doc/source/security/kubernetes/index-security-kub-81153c1254c3.rst b/doc/source/security/kubernetes/index-security-kub-81153c1254c3.rst index 20c543d0f..e91e6e16d 100644 --- a/doc/source/security/kubernetes/index-security-kub-81153c1254c3.rst +++ b/doc/source/security/kubernetes/index-security-kub-81153c1254c3.rst @@ -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 diff --git a/doc/source/security/kubernetes/local-ldap-certificates-4e1df1e39341.rst b/doc/source/security/kubernetes/local-ldap-certificates-4e1df1e39341.rst new file mode 100644 index 000000000..63a577454 --- /dev/null +++ b/doc/source/security/kubernetes/local-ldap-certificates-4e1df1e39341.rst @@ -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 diff --git a/doc/source/security/kubernetes/sssd-support-5fb6c4b0320b.rst b/doc/source/security/kubernetes/sssd-support-5fb6c4b0320b.rst index f1b046643..4bca576f2 100644 --- a/doc/source/security/kubernetes/sssd-support-5fb6c4b0320b.rst +++ b/doc/source/security/kubernetes/sssd-support-5fb6c4b0320b.rst @@ -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 - --------------------- 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