[ English | English (United Kingdom) | español | Deutsch | Indonesia | русский | 한국어 (대한민국) | français ]
Настройки безопасности¶
Данный раздел содержит информацию о настройке определенных параметров безопасности вашего облака OpenStack-Ansible.
Для понимания принципов безопасности обратитесь к Security.
[ English | English (United Kingdom) | español | Deutsch | Indonesia | русский | 한국어 (대한민국) | français ]
Защита сервисов при помощи SSL сертификатов¶
Инструкция по безопасности OpenStack рекомендует использовать защищенное соединение между различными сервисами в окружении OpenStack. Проект OpenStack-Ansible в данный момент предоставляет возможность настройки SSL сертификатов для безопасного взаимодействия между сервисами:
All public endpoints reside behind haproxy, resulting in the only certificate management for externally visible https services are those for haproxy. Certain internal services such as RabbitMQ also require proper SSL configuration.
Во время развертывания с OpenStack-Ansible вы можете либо использовать самоподписанные сертификаты, которые будут сгенерированы во время процесса развертывания, либо предоставить SSL сертификаты, ключи и промежуточные сертификаты для вашего доверенного центра сертификации. Высокозащищенные окружения используют доверенные сертификаты, предоставленные пользователями, для максимально возможного количества сервисов.
Примечание
Выполните все настройки SSL сертификатов в файле /etc/openstack_deploy/user_variables.yml
. Не редактируйте роли или плейбуки самостоятельно для этого.
Openstack-Ansible uses an ansible role ansible_role_pki as a general tool to manage and install self-signed and user provided certificates.
Примечание
The openstack-ansible example configurations are designed to be minimal
examples and in test or development use-cases will set external_lb_vip_address
to the IP address of the haproxy external endpoint. For a production
deployment it is advised to set external_lb_vip_address
to be
the FQDN which resolves via DNS to the IP of the external endpoint.
Самоподписанные сертификаты¶
Self-signed certificates enable you to start quickly and encrypt data in transit. However, they do not provide a high level of trust for public endpoints in highly secure environments. By default, self-signed certificates are used in OpenStack-Ansible. When self-signed certificates are used, certificate verification is automatically disabled.
Self-signed certificates can play an important role in securing internal services within the Openstack-Ansible deployment, as they can only be issued by the private CA associated with the deployment. Using mutual TLS between backend services such as RabbitMQ and MariaDB with self-signed certificates and a robust CA setup can ensure that only correctly authenticated clients can connect to these internal services.
Генерация и пере-генерация самоподписанных сертификатов¶
Самоподписанные сертификаты генерируются для каждого сервиса во время первого запуска плейбука.
To regenerate a new self-signed certificate for a service, you must set
the <servicename>_pki_regen_cert
variable to true in one of the
following ways:
Для принудительного обновления самоподписанного сертификата, вы можете передать переменную
openstack-ansible
в командной строке:# openstack-ansible -e "haproxy_pki_regen_cert=true" haproxy-install.yml
To force a self-signed certificate to regenerate with every playbook run, set the appropriate regeneration option to
true
. For example, if you have already run thehaproxy
playbook, but you want to regenerate the self-signed certificate, set thehaproxy_pki_regen_cert
variable totrue
in the/etc/openstack_deploy/user_variables.yml
file:haproxy_pki_regen_cert: true
Generating and regenerating self-signed user certificates¶
Self-signed user certificates are generated but not installed for services outside of Openstack ansible. These user certificates are signed by the same self-signed certificate authority as is used by openstack services but are intended to be used by user applications.
To generate user certificates, define a variable with the prefix
user_pki_certificates_
in the /etc/openstack_deploy/user_variables.yml
file.
Example
user_pki_certificates_example:
- name: "example"
provider: ownca
cn: "example.com"
san: "DNS:example.com,IP:x.x.x.x"
signed_by: "{{ openstack_pki_service_intermediate_cert_name }}"
key_usage:
- digitalSignature
- keyAgreement
extended_key_usage:
- serverAuth
Generate the certificate with the following command:
# openstack-ansible certificate-generate.yml
To regenerate a new self-signed certificate for a service, you must set
the user_pki_regen_cert
variable to true in one of the
following ways:
Для принудительного обновления самоподписанного сертификата, вы можете передать переменную
openstack-ansible
в командной строке:# openstack-ansible -e "user_pki_regen_cert=true" certificate-generate.yml
To force a self-signed certificate to regenerate with every playbook run, set the
user_pki_regen_cert
variable totrue
in the/etc/openstack_deploy/user_variables.yml
file:user_pki_regen_cert: true
Сертификаты, предоставленные пользователем¶
Для большего доверия в высоконадежных окружениях, вы можете предоставить собственный SSL сертификат, ключи и промежуточные сертификаты. Получение сертификатов из доверенного центра сертификации находится за пределами данного документа, но раздел Управление Сертификатами Linux Documentation Project объясняет как создать свой собственный центр сертификации и подписывать сертификаты.
Используйте следующий подход для установки собственных SSL сертификатов в OpenStack-Ansible:
Скопируйте ваш SSL сертификат, ключ и промежуточные сертификаты на хост развертывания.
Укажите путь к вашему SSL сертификату, ключу и промежуточным сертификатам в файле
/etc/openstack_deploy/user_variables.yml
.Запустите плейбуки для этого сервиса.
Пример HAProxy¶
Переменные к определению, которые содержат путь к сертификатам на ноде развертывания для настройки HAProxy:
haproxy_user_ssl_cert: /etc/openstack_deploy/ssl/example.com.crt
haproxy_user_ssl_key: /etc/openstack_deploy/ssl/example.com.key
haproxy_user_ssl_ca_cert: /etc/openstack_deploy/ssl/ExampleCA.crt
Пример RabbitMQ¶
Для установки определенных пользователем сертификатов на RabbitMQ, скопируйте сертификаты на хост развертывания, отредактируйте файл /etc/openstack_deploy/user_variables.yml
и задайте следующие переменные:
rabbitmq_user_ssl_cert: /etc/openstack_deploy/ssl/example.com.crt
rabbitmq_user_ssl_key: /etc/openstack_deploy/ssl/example.com.key
rabbitmq_user_ssl_ca_cert: /etc/openstack_deploy/ssl/ExampleCA.crt
Потом запустите плейбук для применения сертификатов:
# openstack-ansible rabbitmq-install.yml
Плейбук установит предоставленный вами SSL сертификат, ключ и промежуточные сертификаты на каждый контейнер RabbitMQ.
Процесс идентичен для остальных сервисов. Замените префикс rabbitmq в переменной на horizon, haproxy или keystone, а после запустите плейбук для данного сервиса для разливки предоставленного сертификата на данные сервисы.
Certbot certificates¶
The HAProxy ansible role supports using certbot to automatically deploy trusted SSL certificates for the public endpoint. Each HAProxy server will individually request a SSL certificate using certbot.
Certbot defaults to using LetsEncrypt as the Certificate Authority, other
Certificate Authorities can be used by setting the
haproxy_ssl_letsencrypt_certbot_server
variable in the
/etc/openstack_deploy/user_variables.yml
file:
haproxy_ssl_letsencrypt_certbot_server: "https://acme-staging-v02.api.letsencrypt.org/directory"
The http-01 type challenge is used by certbot to deploy certificates so it is required that the public endpoint is accessible directly by the Certificate Authority.
Deployment of certificates using LetsEncrypt has been validated for openstack-ansible using Ubuntu Focal. Other distributions should work but are not tested.
To deploy certificates with certbot, add the following to
/etc/openstack_deploy/user_variables.yml
to enable the
certbot function in the haproxy ansible role, and to
create a new backend service called certbot
to service
http-01 challenge requests.
haproxy_ssl: true
haproxy_ssl_letsencrypt_enable: True
haproxy_ssl_letsencrypt_install_method: "distro"
haproxy_ssl_letsencrypt_email: "email.address@example.com"
If you don’t have horizon deployed, you will need to define dummy service that will listen on 80 and 443 ports and will be used for acme-challenge, whose backend is certbot on the haproxy host:
haproxy_extra_services:
# the external facing service which serves the apache test site, with a acl for LE requests
- service:
haproxy_service_name: certbot
haproxy_redirect_http_port: 80 #redirect port 80 to port ssl
haproxy_redirect_scheme: "https if !{ ssl_fc } !{ path_beg /.well-known/acme-challenge/ }" #redirect all non-ssl traffic to ssl except acme-challenge
haproxy_port: 443
haproxy_frontend_acls: "{{ haproxy_ssl_letsencrypt_acl }}" #use a frontend ACL specify the backend to use for acme-challenge
haproxy_ssl: True
haproxy_backend_nodes: #apache is running on locally on 127.0.0.1:80 serving a dummy site
- name: local-test-service
ip_addr: 127.0.0.1
haproxy_balance_type: http
haproxy_backend_port: 80
haproxy_backend_options:
- "httpchk HEAD /" # request to use for health check for the example service
TLS for Haproxy Internal VIP¶
As well as load balancing public endpoints, haproxy is also used to load balance internal connections.
By default, OpenStack-Ansible does not secure connections to the internal VIP.
To enable this you must set the following variables in the
/etc/openstack_deploy/user_variables.yml
file:
openstack_service_adminuri_proto: https
openstack_service_internaluri_proto: https
haproxy_ssl_all_vips: true
Run all playbooks to configure haproxy and openstack services.
When enabled haproxy will use the same TLS certificate on all interfaces (internal and external). It is not currently possible in OpenStack-Ansible to use different self-signed or user-provided TLS certificates on different haproxy interfaces.
The only way to use a different TLS certificates on the internal and external VIP is to use certbot.
Enabling TLS on the internal VIP for existing deployments will cause some downtime, this is because haproxy only listens on a single well known port for each OpenStack service and OpenStack services are configured to use http or https. This means once haproxy is updated to only accept HTTPS connections, the OpenStack services will stop working until they are updated to use HTTPS.
For this reason it is recommended that TLS for haproxy internal VIP on existing deployments is deployed at the same time as enabling TLS for Haproxy backends, as this may also cause downtime. For new deployments this should be enabled from the start.
TLS for Haproxy Backends¶
Securing the internal communications from haproxy to backend services is currently work in progress.
TLS for Live Migrations¶
Live migration of VM’s using SSH is deprecated and the OpenStack Nova Docs recommends using the more secure native TLS method supported by QEMU. The default live migration method used by OpenStack-Ansible has been updated to use TLS migrations.
QEMU-native TLS requires all compute hosts to accept TCP connections on port 16514 and port range 49152 to 49261.
It is not possible to have a mixed estate of some compute nodes using SSH and some using TLS for live migrations, as this would prevent live migrations between the compute nodes.
There are no issues enabling TLS live migration during an OpenStack upgrade, as long as you do not need to live migrate instances during the upgrade. If you you need to live migrate instances during an upgrade, enable TLS live migrations before or after the upgrade.
To force the use of SSH instead of TLS for live migrations you must set the
nova_libvirtd_listen_tls
variable to 0
in the
/etc/openstack_deploy/user_variables.yml
file:
nova_libvirtd_listen_tls: 0
TLS for VNC¶
When using VNC for console access there are 3 connections to secure, client to haproxy, haproxy to noVNC Proxy and noVNC Proxy to Compute nodes. The OpenStack Nova Docs for remote console access cover console security in much more detail.
In OpenStack-Ansible TLS to haproxy is configured in haproxy, TLS from haproxy to noVNC is not currently enabled and TLS from nVNC to Compute nodes is enabled by default.
Changes will not apply to any existing running guests on the compute node, so this configuration should be done before launching any instances. For existing deployments it is recommended that you migrate instances off the compute node before enabling.
To help with the transition from unencrypted VNC to VeNCrypt, initially noVNC proxy auth scheme allows for both encrypted and unencrypted sessions using the variable nova_vencrypt_auth_scheme. This will be restricted to VeNCrypt only in future versions of OpenStack-Ansible.
nova_vencrypt_auth_scheme: "vencrypt,none"
To not encrypt data from noVNC proxy to Compute nodes you must set the
nova_qemu_vnc_tls
variable to 0
in the
/etc/openstack_deploy/user_variables.yml
file:
nova_qemu_vnc_tls: 0
[ English | English (United Kingdom) | español | Deutsch | Indonesia | русский | 한국어 (대한민국) | français ]
Security Headers¶
Security headers are HTTP headers that can be used to increase the security of a web application by restricting what modern browsers are able to run.
In OpenStack-Ansible, security headers are implemented in haproxy as all the public endpoints reside behind it.
The following headers are enabled by default on all the haproxy interfaces that implement TLS, but only for the Horizon service. The security headers can be implemented on other haproxy services, but only services used by browsers will make use of the headers.
HTTP Strict Transport Security¶
The OpenStack TLS Security Guide recommends that all production deployments use HTTP strict transport security (HSTS).
By design, this header is difficult to disable once set. It is recommended that during testing you set a short time of 1 day and after testing increase the time to 1 year.
To change the default max age to 1 day, override the variable
haproxy_security_headers_max_age
in the
/etc/openstack_deploy/user_variables.yml
file:
haproxy_security_headers_max_age: 86400
If you would like your domain included in the HSTS preload list, which is built
into browsers, before submitting your request to be added to the HSTS preload
list you must add the preload
token to your response header. The preload
token indicates to the maintainers of HSTS preload list that you are happy to
have your site included.
- "http-response set-header Strict-Transport-Security \"max-age={{ haproxy_security_headers_max_age }}; includeSubDomains; preload;\""
X-Content-Type-Options¶
The X-Content-Type-Options
header prevents MIME type sniffing.
This functionality can be changed by overriding the list of headers in
haproxy_security_headers
variable in the
/etc/openstack_deploy/user_variables.yml
file.
Referrer Policy¶
The Referrer-Policy
header controls how much referrer information is sent
with requests. It defaults to same-origin
, which does not send the origin
path for cross-origin requests.
This functionality can be changed by overriding the list of headers in
haproxy_security_headers
variable in the
/etc/openstack_deploy/user_variables.yml
file.
Permission Policy¶
The Permissions-Policy
header allows you to selectively enable, disable or
modify the use of browser features and APIs, previously known as Feature Policy.
By default this header is set to block access to all features apart from the following from the same origin; fullscreen, clipboard read, clipboard write and spatial navigation.
This functionality can be changed by overriding the list of headers in
haproxy_security_headers
variable in the
/etc/openstack_deploy/user_variables.yml
file.
Content Security Policy (CSP)¶
The Content-Security-Policy
header allows you to control what resources a
browser is allowed to load for a given page, which helps to mitigate the risks
from Cross-Site Scripting (XSS) and data injection attacks.
By default, the Content Security Policy (CSP) enables a minimum set of resources
to allow Horizon to work, which includes access the Nova console. If you require
access to other resources these can be set by overriding the
haproxy_security_headers_csp
variable in the
/etc/openstack_deploy/user_variables.yml
file.
Report Only¶
Implementing CSP could lead to broken content if a browser is blocked from
accessing certain resources, therefore it is recommended that when testing CSP
you use the Content-Security-Policy-Report-Only
header, instead of
Content-Security-Policy
, this reports CSP violations to the browser console,
but does not enforce the policy.
To set the CSP policy to report only by overriding the
haproxy_security_headers_csp_report_only
variable to True
in the
/etc/openstack_deploy/user_variables.yml
file:
haproxy_security_headers_csp_report_only: True
Reporting Violations¶
It is recommended that you monitor attempted CSP violations in production, this
is achieved by setting the report-uri
and report-to
tokens.
Federated Login¶
When using federated login you will need to override the default Content
Security Policy to allow access to your authorisation server by overriding the
haproxy_horizon_csp
variable in the
/etc/openstack_deploy/user_variables.yml
file:
haproxy_horizon_csp: "http-response set-header Content-Security-Policy \"default-src 'self'; frame-ancestors 'self'; form-action 'self' {{ external_lb_vip_address }}:5000 <YOUR-AUTHORISATION-SERVER-ORIGIN>; upgrade-insecure-requests; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; child-src 'self' {{ external_lb_vip_address }}:{{ nova_console_port }}; frame-src 'self' {{ external_lb_vip_address }}:{{ nova_console_port }};\""
[ English | English (United Kingdom) | español | Deutsch | Indonesia | русский | 한국어 (대한민국) | français ]
Security.txt¶
security.txt is a proposed IETF standard to allow independent security
researchers to easily report vulnerabilities. The standard defines that a text
file called security.txt
should be found at «/.well-known/security.txt». For
legacy compatibility reasons the file might also be placed at «/security.txt».
In OpenStack-Ansible, security.txt
is implemented in haproxy as all public
endpoints reside behind it and the text file is hosted by keystone. It defaults
to directing any request paths that end with /security.txt
to the text
file using an ACL rule in haproxy.
Enabling security.txt¶
Use the following process to add a security.txt
file to your deployment
using OpenStack-Ansible:
Write the contents of the
security.txt
file in accordance with the standard.Define the contents of
security.txt
in the variablekeystone_security_txt_content
in the/etc/openstack_deploy/user_variables.yml
file:
keystone_security_txt_content: | # This is my example security.txt file # Please see https://securitytxt.org/ for details of the specification of this file
Update keystone
# openstack-ansible os-keystone-install.yml
Update haproxy
# openstack-ansible haproxy-install.yml
Advanced security.txt ACL¶
In some cases you may need to change the haproxy ACL used to redirect requests
to the security.txt
file, such as adding extra domains.
The haproxy ACL is updated by overriding the variable
haproxy_security_txt_acl
in the
/etc/openstack_deploy/user_variables.yml
file.
[ English | English (United Kingdom) | español | Deutsch | Indonesia | русский | 한국어 (대한민국) | français ]
Применение ansible-hardening¶
Роль ansible-hardening
применима к физическим хостам любого типа внутри развертывания OpenStack-Ansible - как инфраструктурного, так и вычислительного. По умолчанию роль включена. Вы можете выключить ее установив значение переменной apply_security_hardening
в файле user_variables.yml
в false
:
apply_security_hardening: false
Вы можете применить настройки усиления безопасности к существующему окружению или провести аудит окружения при помощи предоставляемого OpenStack-Ansible-ом плейбука:
# Apply security hardening configurations
openstack-ansible security-hardening.yml
# Perform a quick audit by using Ansible's check mode
openstack-ansible --check security-hardening.yml
Для более подробной информации касаемо настроек безопасности, обратитесь к документации по роли усиления безопасности