Additional Security Options on Flatcar Container Linux

Configuring SSSD on Flatcar Container Linux

Mon, 01 Jan 0001 00:00:00 +0000

Flatcar Container Linux ships with the System Security Services Daemon, allowing integration between Flatcar Container Linux and enterprise authentication services.

Configuring SSSD

Edit /etc/sssd/sssd.conf. This configuration file is fully documented here . For example, to configure SSSD to use an IPA server called ipa.example.com, sssd.conf should read:

[sssd]
config_file_version = 2
services = nss, pam
domains = LDAP
[nss]
[pam]
[domain/LDAP]
id_provider = ldap
auth_provider = ldap
ldap_schema = ipa
ldap_uri = ldap://ipa.example.com

Start SSSD

sudo systemctl start sssd

Make SSSD available on future reboots

sudo systemctl enable sssd

Customizing the SSH daemon

Mon, 01 Jan 0001 00:00:00 +0000

Flatcar Container Linux defaults to running an OpenSSH daemon using systemd socket activation – when a client connects to the port configured for SSH, sshd is started on the fly for that client using a systemd unit derived automatically from a template. In some cases you may want to customize this daemon’s authentication methods or other configuration. This guide will show you how to do that at boot time using a Butane Config , and after building by modifying the systemd unit file.

SELinux on Flatcar Container Linux

Mon, 01 Jan 0001 00:00:00 +0000

SELinux is a fine-grained access control mechanism integrated into Flatcar Container Linux and rkt. Each container runs in its own independent SELinux context, increasing isolation between containers and providing another layer of protection should a container be compromised.

Flatcar Container Linux implements SELinux, but currently does not enforce SELinux protections by default. This allows deployers to verify container operation before enabling SELinux enforcement. This document covers the process of checking containers for SELinux policy compatibility, and switching SELinux into enforcing mode.

Setting up LUKS disk encryption

Mon, 01 Jan 0001 00:00:00 +0000

Depending on where you run Flatcar Container Linux you might want to protect the data on disk against attackers that could pull out a hard disk or get access to a snapshot copy of it. Like a laptop, a server can use disk encryption to protect the contents. However, since there is no-one to type the password for unlocking, the unlocking has to happen automatically. It’s hard to do this in a secure way that also protects against attackers with prolonged physical access to the system or similar modification capabilities.

Flatcar Container Linux FIPS guide

Mon, 01 Jan 0001 00:00:00 +0000

FIPS stands for Federal Information Processing Standards, a set of standards issued by the National Institute of Standards and Technology (NIST). While Flatcar is not officially FIPS certified, it is possible to deploy it so that it is compliant with two of these standards:

Enabling FIPS

Booting the instance with the kernel parameter fips=1 allows the instance to operate in a FIPS 200 mode. This means the kernel will use FIPS-compliant algorithms and will enforce some security practices like RSA key size . It’s also recommended to create the empty file /etc/system-fips for other software (like cryptsetup).

Flatcar Container Linux hardening guide

Mon, 01 Jan 0001 00:00:00 +0000

This guide covers the basics of securing a Flatcar Container Linux instance. Flatcar Container Linux has a very slim network profile and the only service that listens by default on Flatcar Container Linux is sshd on port 22 on all interfaces. There are also some defaults for local users and services that should be considered.

Remote listening services

Disabling sshd

To disable sshd from listening you can stop the socket:

Setting up the Linux Auditing System

Mon, 01 Jan 0001 00:00:00 +0000

On Flatcar Container Linux audit-rules.service loads the audit rules to set up the logging filters for the kernel messages. The auditd.service daemon to collect these logs does not run by default.

Enabling the standard rules or custom rules

There is an ignore rule by default that suppresses the standard rules, which means that certain PAM audit messages are not shown. It is also important to remove this default ignore rule when setting up own rules, or otherwise they will be ignored, too. The following Butane Config will overwrite the default ignore rule:

Trusted Computing requirements on Flatcar Container Linux

Mon, 01 Jan 0001 00:00:00 +0000

Trusted Computing requires support in both system hardware and firmware. This document specifies the required support and explains how to determine if a physical machine has the features needed to enable Trusted Computing in Flatcar Container Linux.

1. Check for Trusted Platform Module

Trusted Computing depends on the presence of a Trusted Platform Module (TPM). The TPM is a motherboard component responsible for storing the state of the system boot process, and providing a secure communication channel over which this state can be verified. To check for the presence of a TPM, install the latest Alpha version of Flatcar Container Linux and try to list the TPM device file in the /sys system control filesystem:

Custom certificate authorities

Mon, 01 Jan 0001 00:00:00 +0000

Flatcar Container Linux supports custom Certificate Authorities (CAs) in addition to the default list of trusted CAs. Adding your own CA allows you to:

Use a corporate wildcard certificate
Use your own CA to communicate with an installation of CoreUpdate

The setup process for any of these use-cases is the same:

Copy the PEM-encoded certificate authority file (usually with a .pem file name extension) to /etc/ssl/certs
Run the update-ca-certificates script to update the system bundle of Certificate Authorities. All programs running on the system will now trust the added CA.

Generate self-signed certificates

Mon, 01 Jan 0001 00:00:00 +0000

If you build Flatcar Container Linux cluster on top of public networks it is recommended to enable encryption for Flatcar Container Linux services to prevent traffic interception and man-in-the-middle attacks. For these purposes you have to use Certificate Authority (CA), private keys and certificates signed by CA. Let’s use cfssl and walk through the whole process to create all these components.

NOTE: We will use basic procedure here. If your configuration requires advanced security options, please refer to official cfssl documentation.

Disabling SMT on Flatcar Container Linux

Mon, 01 Jan 0001 00:00:00 +0000

Recent Intel CPU vulnerabilities ( L1TF and MDS ) cannot be fully mitigated in software without disabling Simultaneous Multi-Threading. This can have a substantial performance impact and is only necessary for certain workloads, so for compatibility reasons, SMT is enabled by default.

In addition, the Intel TAA vulnerability cannot be fully mitigated without disabling either of SMT or the Transactional Synchronization Extensions (TSX). Disabling TSX generally has less performance impact, so is the preferred approach on systems that don’t otherwise need to disable SMT. For compatibility reasons, TSX is enabled by default.