04fa7c039c
Change-Id: I657ff1427908610a8aa2397b4ce1115be0ac8ace Partial-Implements: blueprint ansible-specific-task-become
79 lines
3.6 KiB
ReStructuredText
79 lines
3.6 KiB
ReStructuredText
.. _security:
|
|
|
|
==============
|
|
Kolla Security
|
|
==============
|
|
|
|
Non Root containers
|
|
~~~~~~~~~~~~~~~~~~~
|
|
|
|
The OpenStack services, with a few exceptions, run as non root inside
|
|
of Kolla's containers. Kolla uses the Docker provided ``USER`` flag to
|
|
set the appropriate user for each service.
|
|
|
|
SELinux
|
|
~~~~~~~
|
|
|
|
The state of SELinux in Kolla is a work in progress. The short answer
|
|
is you must disable it until selinux polices are written for the
|
|
Docker containers.
|
|
|
|
To understand why Kolla needs to set certain selinux policies for
|
|
services that you wouldn't expect to need them (rabbitmq, mariadb, glance
|
|
and so on) we must take a step back and talk about Docker.
|
|
|
|
Docker has not had the concept of persistent containerized data until
|
|
recently. This means when a container is run the data it creates is
|
|
destroyed when the container goes away, which is obviously no good
|
|
in the case of upgrades.
|
|
|
|
It was suggested data containers could solve this issue by only holding
|
|
data if they were never recreated, leading to a scary state where you
|
|
could lose access to your data if the wrong command was executed. The
|
|
real answer to this problem came in Docker 1.9 with the introduction of
|
|
named volumes. You could now address volumes directly by name removing
|
|
the need for so called **data containers** all together.
|
|
|
|
Another solution to the persistent data issue is to use a host bind
|
|
mount which involves making, for sake of example, host directory
|
|
``var/lib/mysql`` available inside the container at ``var/lib/mysql``.
|
|
This absolutely solves the problem of persistent data, but it introduces
|
|
another security issue, permissions. With this host bind mount solution
|
|
the data in ``var/lib/mysql`` will be owned by the mysql user in the
|
|
container. Unfortunately, that mysql user in the container could have
|
|
any UID/GID and thats who will own the data outside the container
|
|
introducing a potential security risk. Additionally, this method
|
|
dirties the host and requires host permissions to the directories
|
|
to bind mount.
|
|
|
|
The solution Kolla chose is named volumes.
|
|
|
|
Why does this matter in the case of selinux? Kolla does not run the
|
|
process. It is launching as root in most cases. So glance-api is run
|
|
as the glance user, and mariadb is run as the mysql user, and so on.
|
|
When mounting a named volume in the location that the persistent data
|
|
will be stored it will be owned by the root user and group. The mysql
|
|
user has no permissions to write to this folder now. What Kolla does
|
|
is allow a select few commands to be run with sudo as the mysql user.
|
|
This allows the mysql user to chown a specific, explicit directory
|
|
and store its data in a named volume without the security risk and
|
|
other downsides of host bind mounts. The downside to this is selinux
|
|
blocks those sudo commands and it will do so until we make explicit
|
|
policies to allow those operations.
|
|
|
|
Kolla-ansible users
|
|
===================
|
|
|
|
Prior to Queens, when users want to connect using non-root user, they must add
|
|
extra option ``ansible_become=True`` which is inconvenient and add security
|
|
risk. In Queens, almost all services have support for escalation for only
|
|
necessary tasks. In Rocky, all services have this capability, so users do not
|
|
need to add ``ansible_become`` option if connection user has passwordless sudo
|
|
capability.
|
|
|
|
Prior to Rocky, ``ansible_user`` (the user which Ansible uses to connect via SSH)
|
|
is default configuration owner and group in target nodes.
|
|
From Rocky release, Kolla support connection using any user which has
|
|
passwordless sudo capability. For setting custom owner user and group, user can
|
|
set ``config_owner_user`` and ``config_owner_group`` in ``globals.yml``
|