docs/doc/source/security/openstack/update-the-domain-name.rst
Ron Stone 6abab2e712 Align r5 and r6 bare metal procedures
Bring r6 procedures into alignment with updates on r5
Fix substitutions in unexpandable contexts.
|prereq| > |prefix| as required.

Signed-off-by: Ron Stone <ronald.stone@windriver.com>
Change-Id: I4a13d8cb447c014f311228943551e117f8f3b773
2021-09-08 15:08:33 -04:00

8.2 KiB
Raw Blame History

Update the Domain Name

Containerized OpenStack services in are deployed behind an ingress controller (nginx) that listens, by default, on either port 80 (HTTP) or port 443 (HTTPS).

The ingress controller routes packets to the specific OpenStack service, such as the Cinder service, or the Neutron service, by parsing the in the packet. For example, neutron.openstack.svc.cluster.local is for the Neutron service, cinderapi.openstack.svc.cluster.local is for the Cinder service.

This routing requires that access to OpenStack REST APIs (directly or via remote OpenStack ) must be via a . You cannot access OpenStack REST APIs using an IP address.

(such as cinderapi.openstack.svc.cluster.local) must be in a server that is publicly accessible.

Note

It is possible to wildcard a set of to the same IP address in a server configuration so that you don't need to update the server every time an OpenStack service is added. Check your particular server for details on how to wild-card a set of .

In a "real" deployment, that is, not a lab scenario, you cannot use the default openstack.svc.cluster.local domain name externally. You must set a unique domain name for your system. Use the system serviceparameter-add command to configure and set the OpenStack domain name:

  • You must have an external Server for which you have authority to add new domain name to IP address mappings (e.g. A, AAAA or CNAME records).

  • The server must be added to your list.

  • Your server must have A, AAAA or CNAME records for the following domain names, representing the corresponding openstack services, defined as the Floating IP address. Refer to the configuration manual for the particular server you are using on how to make these updates for the domain you are using for the system.

    Note

    recommends that you not define domain names for services you are not using.

    # define A record for general domain for system <my--domain> IN A 10.10.10.10

    # define alias for general domain for horizon dashboard REST API URL horizon.<my--domain> IN CNAME <my--domain>.<my-company>.com

    # define alias for general domain for keystone identity service REST API URLs keystone.<my--domain> IN CNAME <my--domain>.<my-company>.com keystone-api.<my--domain> IN CNAME <my--domain>.<my-company>.com

    # define alias for general domain for neutron networking REST API URL neutron.<my--domain> IN CNAME <my--domain>.<my-company>.com

    # define alias for general domain for nova compute provisioning REST API URLs nova.<my--domain> IN CNAME <my--domain>.<my-company>.com nova-api-internal.<my--domain> IN CNAME <my--domain>.<my-company>.com placement.<my--domain> IN CNAME <my--domain>.<my-company>.com rest-api.<my--domain> IN CNAME <my--domain>.<my-company>.com

    # define no vnc proxy alias for VM console access through Horizon REST API URL novncproxy.<my--domain> IN CNAME <my--domain>.<my-company>.com

    # define alias for general domain for barbican secure storage REST API URL barbican.<my--domain> IN CNAME <my--domain>.<my-company>.com.

    # define alias for general domain for glance VM management REST API URL glance.<my--domain> IN CNAME <my--domain>.<my-company>.com.

    # define alias for general domain for cinder block storage REST API URL cinder.<my--domain> IN CNAME <my--domain>.<my-company>.com cinder2.<my--domain> IN CNAME <my--domain>.<my-company>.com cinder3.<my--domain> IN CNAME <my--domain>.<my-company>.com

    # define alias for general domain for heat orchestration REST API URLs heat.<my--domain> IN CNAME <my--domain>.<my-company>.com cloudformation.<my--domain> IN CNAME my--domain.<my-company>.com

    # define alias for general domain for starlingx REST API URLs # ( for fault, patching, service management, system and VIM ) fm.<my--domain> IN CNAME <my--domain>.<my-company>.com patching.<my--domain> IN CNAME <my--domain>.<my-company>.com smapi.<my--domain> IN CNAME <my--domain>.<my-company>.com sysinv.<my--domain> IN CNAME <my--domain>.<my-company>.com vim.<my--domain> IN CNAME <my--domain>.<my-company>.com

  1. Source the environment.

    $ source /etc/platform/openrc
    ~(keystone_admin)$
  2. To set a unique domain name, use the system serviceparameter-add command.

    The command has the following syntax.

    ~(keystone_admin)$ system service-parameter-add openstack helm endpoint_domain=<domain_name>

    <domain_name> should be a fully qualified domain name that you own, such that you can configure the Server that owns <domain_name> with the OpenStack service names underneath the domain.

    See the prerequisites <update-the-domain-name-prereq-FQDNs> for a complete list of .

    For example:

    ~(keystone_admin)$ system service-parameter-add openstack helm endpoint_domain=my-|prefix|-domain.mycompany.com

    Note

    If an error occurs, remove the following ingress parameters, nova-cluster-fqdn and nova-namespace-fqdn and reapply OpenStack using system application-apply -openstack.

  3. Apply the -openstack application.

    For example:

    ~(keystone_admin)$ system application-apply -openstack

The helm charts of all OpenStack services are updated and restarted. For example cinderapi.openstack.svc.cluster.local would be changed to cinderapi.my--domain.mycompany.com, and so on for all OpenStack services.

Note

OpenStack Horizon is also changed to listen on horizon.my--domain.mycompany.com:80 (instead of the initial oamfloatingip:31000), for example, horizon.my-wr-domain.mycompany.com:80.

After changing the Helm endpoint domain using the above procedure, OpenStack will switch from Kubernetes node_port controller to the nginx ingress controller, that adds a 2500 MiB size limit to all HTTP requests done using for security reasons.

Note

For images that are larger than 2500 MiB in size, uploading the images using Horizon Web Interface will fail. Use the steps below to change the maximum image size supported by the Horizon ingress resource, by applying an override to the Horizon Helm chart.

  1. Create a horizon-overrides.yaml file using the following overrides, and change the value of the proxy-body-size to the new size. For example, to support uploads of images up to 3500 MiB in size using the Horizon Web Interface, update the following value:

    cat <<EOF > horizon-overrides.yaml
    network:
      dashboard:
        ingress:
          annotations:
            nginx.ingress.kubernetes.io/proxy-body-size: "3500m"
    EOF
  2. Use the system helm-override-update command to update the overrides for the Horizon Helm chart.

    ~(keystone_admin)]$ system helm-override-update -openstack horizon openstack --values=horizon-overrides.yaml

  3. Apply the updated Horizon Helm chart overrides to the -openstack application

    ~(keystone_admin)$ system application-apply -openstack