298 lines
10 KiB
ReStructuredText
298 lines
10 KiB
ReStructuredText
========================================
|
||
StarlingX Secure Local OpenLDAP Support
|
||
========================================
|
||
|
||
Storyboard:
|
||
https://storyboard.openstack.org/#!/story/2009834
|
||
|
||
This specification describes what configuration changes are required to support
|
||
a Secure Local OpenLDAP. A Secure OpenLDAP server is the first building block
|
||
in transitioning to all encrypted authentication server communication,
|
||
specifically for LDAP authentication, and the future introduction of SSSD client
|
||
(System Security Services Daemon), as a replacement for the current nslcd
|
||
solution. Some valuable features that SSSD can bring that strongly support the
|
||
move to use it, are:
|
||
* Multi domain remote LDAP authentication
|
||
* Extra security by using data encryption for LDAP user authentication
|
||
* Offline authentication if a LDAP identity store is unavailable by caching
|
||
users and managing caching timeout and refresh
|
||
* High authentication and authorization performance
|
||
|
||
Problem description
|
||
===================
|
||
|
||
An SSSD solution provides a system service that establishes and manages access
|
||
to local and remote LDAP directories and other authentication servers. An SSSD
|
||
client can connect to one or more remote backend systems as opposed to a nslcd
|
||
solution that can connect to only one remote authentication backend. SSSD also
|
||
provides extra security compared to the nslcd by using data encryption for LDAP
|
||
user authentication. SSSD does not support authentication over an unencrypted
|
||
channel. In order to work with SSSD, the local OpenLDAP server requires to be
|
||
configured as a secure OpenLDAP.
|
||
|
||
Use Cases
|
||
---------
|
||
|
||
The secure OpenLDAP configuration will be applied during the host-install step
|
||
of the installation process as well as during the host-unlock step:
|
||
* During the bootstrap step of the host-install, execute in order
|
||
|
||
* CertManager, a Kubernetes component, creates the OpenLDAP certificate
|
||
from a yaml file that defines the certificate spec, only if the certificate
|
||
was not already created.
|
||
* apply updates to the LDAP schema configuration and copy the certificate and
|
||
key files to the "/etc/openldap/certs" directory.
|
||
|
||
* During host-unlock step of host-install, execute in order
|
||
|
||
* apply updates to the OpenLDAP schema configuration to add the certificate
|
||
and key files' location.
|
||
* update the slapd configuration to support "ldaps" protocol to allow
|
||
encryption of the LDAP data, and restart slapd service.
|
||
* CertMon component starts and installs the newly created certificates as
|
||
well as triggering updates to OpenLDAP schema configuration and a restart of
|
||
slapd.
|
||
|
||
* An OpenLDAP certificate gets renewed by the CertManager component before it
|
||
reaches the expiry date. The renewal action creates a new certificate that is
|
||
detected by the CertMon component. CertMon installs the new certificate and
|
||
triggers OpenLDAP configuration updates to refresh the OpenLDAP certificate
|
||
and restart slapd.
|
||
* The system command “system certificate-list” will discover and list the newly
|
||
installed OpenLDAP certificate.
|
||
* A tool called "show-certs.sh" that gives a summary of all the certificates in
|
||
the system will also show OpenLDAP certificate information.
|
||
|
||
Proposed change
|
||
===============
|
||
|
||
Configure a secure local OpenLDAP server.
|
||
|
||
This solution is the first step in transitioning to all encrypted LDAP
|
||
authentication server communication using SSSD system service as a replacement
|
||
for nslcd service that we currently use.
|
||
The capability to connect to local OpenLDAP using the insecure port will be kept
|
||
in this stage.
|
||
Certificate install will not be done using system cli “certificate-install” but
|
||
rather using CertManager CRDs, which will be auto-configured at bootstrap time,
|
||
and detected by CertMon that will use sysinv internal REST APIs to configure the
|
||
openldap certificate.
|
||
|
||
The following new capabilities and extensions will be added to the local
|
||
OpenLDAP configuration:
|
||
|
||
Certificate creation
|
||
--------------------
|
||
|
||
A new OpenLDAP certificate will be auto-configured at bootstrap time using the
|
||
following spec::
|
||
|
||
apiVersion: cert-manager.io/v1alpha2
|
||
kind: Certificate
|
||
metadata:
|
||
name: local-openldap-certificate
|
||
namespace: deployment
|
||
spec:
|
||
secretName: local-openldap-certificate
|
||
ipAddresses:
|
||
- <management floating ip>
|
||
- <management controller0_address>
|
||
- <management controller1_address>
|
||
commonName: local-openldap
|
||
isCA: false
|
||
duration: 2160h # 90d
|
||
renewBefore: 720h # 30d
|
||
issuerRef:
|
||
name: system-local-ca
|
||
kind: ClusterIssuer
|
||
|
||
Newly added functionality will perform the following:
|
||
* The certificate spec will be loaded from a yaml file and created by
|
||
CertManager, a Kubernetes component. This is done during the bootstrap procedure
|
||
of the platform installation phase.
|
||
* Certificate’s IPaddresses will be populated at bootstrap time with the IP
|
||
addreses real values of the server where the certificate will be installed.
|
||
* Certificate will be then installed by CertMon component, together with the
|
||
other certificates, during “host-unlock” phase.
|
||
|
||
The LDAP certificate creation applies to a standalone server and to a Distributed
|
||
Cloud System Controller, but it does not apply to Distributed Cloud subclouds
|
||
because they do not have slapd running.
|
||
|
||
Certificate install
|
||
-------------------
|
||
|
||
The new LDAP certificate is installed during the host-unlock phase when the
|
||
CertMon component starts and discovers that a new certificate was created.
|
||
CertMon’s newly added LDAP certificate watcher class will call the internal
|
||
sysinv REST API “certificate_install' to trigger secure OpenLDAP schema
|
||
configuration changes, as well as slapd configuration changes followed by a
|
||
slapd service restart. The sysinv api uses a puppet runtime manifest mechanism
|
||
to trigger puppet configuration code to be executed to update OpenLDAP and slapd
|
||
configurations.
|
||
|
||
Certificate renewal
|
||
-------------------
|
||
|
||
A certificate can be renewed before it reaches the expiry date or other reasons,
|
||
like the secret is deleted. The certificate specification has a “renewBefore”
|
||
field used to trigger CertManager. A soon to be expired certificate will be
|
||
detected by CertManager and subsequently a new certificate will be created with
|
||
a new expiry date. CertMon will detect the new certificate and call internal
|
||
sysinv REST API “certificate-install” to install the certificate.
|
||
The OpenLDAP certificate renewal will follow the same pattern. The internal
|
||
sysinv REST API “certificate-install” will be used to handle OpenLDAP specific
|
||
configuration changes triggered from the CertMon’s watchers component.
|
||
The configuration changes required by a secure OpenLDAP will be performed using
|
||
the runtime manifest mechanism of the puppet component.
|
||
|
||
Certificate monitoring and alarming
|
||
-----------------------------------
|
||
|
||
This functionality is provided by the existing certificate framework.
|
||
|
||
Certificate List
|
||
----------------
|
||
|
||
The system command “system certificate-list” will discover and list the newly
|
||
installed OpenLDAP certificate.
|
||
|
||
CertMon support for OpenLDAP certificate discovery
|
||
--------------------------------------------------
|
||
|
||
CertMon will discover the new OpenLDAP certificate created by CertManager and
|
||
will use a sysinv REST API to install the certificate.
|
||
CertMon “watchers” component will be enhanced with 2 classes, a “watcher” and
|
||
a “renewal” for the OpenLDAP certificate.
|
||
The Openldap certificate renewal class will use the internal sysinv REST API
|
||
“certificate_install” to install the certificate for the first time or to update
|
||
it.
|
||
|
||
Sysinv api for OpenLDAP certificate install/renewal
|
||
---------------------------------------------------
|
||
|
||
The internal sysinv REST API “certificate_install” will interface with the puppet
|
||
component to apply the secure OpenLDAP configuration and restart "slapd"
|
||
service. The REST API will be called by the CertMon for both initial certificate
|
||
install as well as renewal.
|
||
|
||
Certificate Summary
|
||
-------------------
|
||
|
||
A tool called "show-certs.sh" gives a summary of all the certificates in the
|
||
system. The tool will be enhanced to also include the OpenLDAP certificate.
|
||
|
||
Secure OpenLDAP for System Controller
|
||
-------------------------------------
|
||
|
||
Secure OpenLDAP for System Controller follows the same pattern as for a
|
||
standalone server. Only subclouds would not have any certificate added as they
|
||
do not run slapd.
|
||
|
||
Alternatives
|
||
------------
|
||
|
||
Data model impact
|
||
-----------------
|
||
|
||
This proposal will not impact any data models.
|
||
|
||
REST API impact
|
||
---------------
|
||
|
||
Internal rest api "certificate_install" will add new option "mode=openldap" for
|
||
OpenLDAP certificate.
|
||
CLI "system certificate-install" will disallow "mode=openldap".
|
||
|
||
Security impact
|
||
---------------
|
||
|
||
There is no security impact as the new secure endpoint for openldap/slapd is not
|
||
yet being used. In future next step, when SSSD client is introduced, security
|
||
will be enhanced with use of LDAPS (LDAP over TLS/SSL) for openldap/slapd.
|
||
|
||
Other end user impact
|
||
---------------------
|
||
|
||
Performance Impact
|
||
------------------
|
||
|
||
There is no performance impact because the LDAP configuration will not be used.
|
||
The local OpenLDAP will continue to work using the insecure communication channel.
|
||
|
||
Other deployer impact
|
||
---------------------
|
||
|
||
Developer impact
|
||
----------------
|
||
|
||
There is no developer impact.
|
||
|
||
Upgrade impact
|
||
--------------
|
||
|
||
There is no upgrade impact that be found at this time.
|
||
|
||
Implementation
|
||
==============
|
||
|
||
Assignee(s)
|
||
-----------
|
||
|
||
Primary assignee:
|
||
TDB
|
||
|
||
Other contributors:
|
||
TDB
|
||
|
||
Repos Impacted
|
||
--------------
|
||
|
||
The repos impacted are: config, stx-puppet, ansible-playbooks.
|
||
|
||
Work Items
|
||
----------
|
||
|
||
The following work items will be addressed:
|
||
* Generate OpenLDAP certificate and key using cert-manager
|
||
* Integrate OpenLDAP certificate into the framework provided for Default
|
||
Platform Certificates Install at bootstrap
|
||
* Update OpenLDAP configuration at bootstrap
|
||
* Update OpenLDAP configuration at host-unlock
|
||
* OpenLDAP certificate Renewal
|
||
* OpenLDAP certificate Summary
|
||
|
||
Dependencies
|
||
============
|
||
|
||
Testing
|
||
=======
|
||
|
||
Testing will involve:
|
||
* ensure insecure openldap endpoint is still working for nslcd client.
|
||
* test secure openldap endpoint using a remote sssd client.
|
||
|
||
Documentation Impact
|
||
====================
|
||
|
||
Developer documentation could have information on the new OpenLDAP certificate
|
||
in the list of platform certificates with the note that this certificate is not
|
||
currently being used.
|
||
|
||
References
|
||
==========
|
||
|
||
* https://linux.die.net/man/5/sssd.conf
|
||
|
||
History
|
||
=======
|
||
|
||
.. list-table:: Revisions
|
||
:header-rows: 1
|
||
|
||
* - Release Name
|
||
- Description
|
||
* - STX-7.0
|
||
- Introduced
|
||
|