Multi-Tenancy

Lightbits v2.2.1 and above enforces tenant isolation on the control plane ("multi-tenancy"). With multi-tenancy, multiple tenants can share a Lightbits cluster without being able to see or affect each other's resources when accessing the Lightbits API or using the Lightbits command line tools.

Command line tools and all other API users must use the v2 Lightbits API. The v2 API includes provisions for authentication and authorization via standard JSON Web Tokens ("JWTs"), as well as transport security for all API operations.

The following three predefined roles are created by default:

• cluster-admin (system scope)
• admin (project scope)
• viewer (project scope)

Currently, roles cannot be added.

At installation, the user can provide their own certificate and CA to be used by the peers. If these files are not provided, the installation will generate self-signed certificates.

Certificates Directory

By default, certificates are stored at certificates_directory=~/lightos-certificates on the Ansible controller machine.

certificates_directory can be overridden via cmd-line:

ansible-playbook playbooks/deploy-lightos.yml \

  -e 'certificates_directory=/path/to/certs' ...

Or via group_vars/all.yml:

certificates_directory: /path/to/certs

Certificate Types

Implementing multi-tenancy involves three sets of certificates:

• Multi-Tenancy

  • Certificates Directory

• etcd Certificates for mTLS Peer Communication

• API Service Certificates for TLS

• System Scope Cluster Admin Certificates

  • Generating Self-Signed Certificates
  • Bring Your Own Certificates

etcd Certificates for mTLS Peer Communication

All etcd services serve client APIs only on localhost. This minimizes the exposure of etcd to outside malicious activity.

Peer communication must be encrypted at all times, since etcd passes sensitive traffic between its peers.

The installation script expects the following files to be present at certificates_directory on the Ansible controller machine:

etcd-ca-key.pem

etcd-ca.pem

{ansible_hostname}-cert-etcd-peer-key.pem

{ansible_hostname}-cert-etcd-peer.pem

• etcd-ca: Certificate authority (CA) parameters for etcd certificates. This CA is used to sign certificates used by etcd (such as peer and server certificates).
• {ansible_hostname}-cert-etcd-peer: The peer certificate is used by etcd for peer communication.

These files are passed to the following etcd parameters: --peer-cert-file and --peer-key-file.

Example

A three-node cluster with server00-02 will result in:

etcd-ca-key.pem

etcd-ca.pem

server00-cert-etcd-peer-key.pem

server00-cert-etcd-peer.pem

server01-cert-etcd-peer-key.pem

server01-cert-etcd-peer.pem

server02-cert-etcd-peer-key.pem

server02-cert-etcd-peer.pem

API Service Certificates for TLS

All API endpoints are TLS-enabled by default.

The user can provide their own SSL certificates, or the installation process will generate a self-signed certificate.

These are the files used by api-service to set up TLS communication.

cert-lb-api-service-key.pem

cert-lb-api-service.pem

System Scope Cluster Admin Certificates

These files will be stored in etcd and used to authenticate a system-scope project.

These are the files used to generate system scope credentials:

cert-lb-admin-key.pem

cert-lb-admin.pem

Generating Self-Signed Certificates

The Lightbits installation playbook checks for certificates_directory existence. If it does not exist, a folder will be created and populated with self-signed certificates. If it exists, the playbook will verify that all expected certificates files are present. In case one is missing the installation will fail.

Bring Your Own Certificates

You can provide your own certificates for each of the components.

You can override part or all of the files before running the install-lightos.yaml playbook.