Merge "Secure OpenLDAP support for StarlingX"
This commit is contained in:
Zuul
Gerrit Code Review
commit
ea7023cf7c
@ -0,0 +1,296 @@
|
||||
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
|
||||
|
||||
Loading…
Reference in New Issue
Block a user