Security Overview

This document provides an overview of Livepatch Server security measures, focusing on areas related to authentication, transmission, and cryptographic technologies.

Livepatch server exposes various API endpoints for interaction with the Livepatch client, Livepatch admin tool and other Livepatch servers. These endpoints are protected by different authentication mechanisms.

Livepatch server also interacts with other services and data stores in hosted as well as on-prem environments. The communications have either TLS enforced or optional and enforceable by configuration changes.

Built-in Protection

Authentication

Livepatch server supports different mechanisms for authenticating different APIs:

Admin APIs: Admin users are authenticated via SSO or BasicAuth + Macaroons based authentication.
Client APIs: Livepatch clients are authenticated using an AuthToken or a Resource Token. AuthToken is the deprecated method of authentication wherein a machine token is issued to a client after an initial UUID based authentication. Resource tokens are Macaroon-based authentication verified against the Ubuntu Pro backend.
Server APIs: Other livepatch servers and Grafana use SyncToken and WebhookToken respectively for authentication. Both are UUID-based tokens generated by the admin tool and stored in Postgres for verification.

TLS Communication

TLS encryption is optional between the different Livepatch Server components.

communications	TLS
livepatch-server ↔ livepatch-client	optional
livepatch-server ↔ livepatch-admin-tool	optional
livepatch-server ↔ upstream livepatch-server	optional
livepatch-server ↔ SSO server	enforced
livepatch-server ↔ Ubuntu Pro backend	enforced
livepatch-server ↔ Postgresql	optional
livepatch-server ↔ S3	optional
livepatch-server ↔ Swift	optional
livepatch-server ↔ InfluxDB	disabled
livepatch-server ↔ CVE service	optional

Risks

On-prem Livepatch server does not enforce TLS when communicating with data stores. This is done to provide flexibility for customers operating in air-gapped environments where they wouldn’t necessarily want TLS encryption due to existing network security measures, such as network isolation and firewalls, in-place. It is still highly recommended to enable TLS encryption to prevent malicious actors from sniffing data over the network.

How-to guides

Enabling TLS with data stores

To enable TLS for optional communications with other services, provide the corresponding https endpoint of the service in the Livepatch server configuration and leave the http endpoint empty. Eg:

patch_sync:
    proxy:
        enabled: true
        http: ""
        https: "https://myproxyurl.com"
        no_proxy:
            - 1.2.3.4

To enable TLS for Postgres, provide the sslmode parameter in the connection string:

# Postgres
database:
    connection_string: postgresql://user:pass@host:8080/db?sslmode=require
    connection_pool_max: 10
    connection_lifetime_max: 10m