Add an Image service API

You can add a new Image service API (glanceAPI) to a Red Hat OpenStack Services on OpenShift (RHOSO) deployment to support multiple workloads or to maintain the lifecycle of an existing glanceAPI and its back-end services. For example, if your deployment has a back end with a split layout, such as Red Hat Ceph Storage, and a back end with a single layout, such as NFS, you cannot make changes to the single or split layout because they impact configuration elements such as PersistentVolumeClaims (PVCs). Instead, you can add a new glanceAPI to switch between the back ends.

Procedure
Copy link

  1. Open your OpenStackControlPlane CR file, openstack_control_plane.yaml, and add the parameters to the glance template to configure a new glanceAPI. In the following example, there is an existing default API that uses the Object Storage service (swift) as a back end, and you update the OpenStackControlPlane to deploy a new default1 API: 
    ...
apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
spec:
  glance:
    template:
      databaseInstance: openstack
      keystoneEndpoint: default
      glanceAPIs:
        default:
          customServiceConfig: |
            [DEFAULT]
            enabled_backends = <backend_name>:swift
            [glance_store]
            default_backend = <backend_name>
            [<backend_name>]
            swift_store_create_container_on_put = True
            swift_store_auth_version = 3
            swift_store_auth_address = {{ .KeystoneInternalURL }}
            swift_store_endpoint_type = internalURL
            swift_store_user = service:glance
            swift_store_key = {{ .ServicePassword }}
          preserveJobs: false
          replicas: 3
        default1:
          type: single
          replicas: 1
      storage:
        storageRequest: 10G
...
    • Replace <backend_name> with the name of the default back end.
  2. Update the control plane: 
    $ oc apply -f openstack_control_plane.yaml -n openstack
  3. Wait until RHOCP creates the resources related to the OpenStackControlPlane CR. Run the following command to check the status: 
    $ oc get openstackcontrolplane -n openstack

    The OpenStackControlPlane resources are created when the status is "Setup complete".

    Tip
    Append the -w option to the end of the get command to track deployment progress.

Remove an Image service API
Copy link

To decommission an existing Image service API (glanceAPI), you must do the following:

About this task
Copy link

  • Delete the glanceAPI CR and its associated objects, for example, pods and StatefulSets.
  • Update the keystoneEndpoint to point to an active glanceAPI.

You cannot delete a glanceAPI if it is the only glanceAPI in the OpenStackControlPlane, and you cannot point the keystoneEndpoint parameter in your OpenStackControlPlane CR file to a non-existent glanceAPI.

When you remove a glanceAPI, PersistentVolumeClaims (PVCs) that are associated to the API are preserved so that you can re-add the API with its previous settings if required.

Procedure
Copy link

  1. Verify that more that one glanceAPI is deployed in the OpenStackControlPlane: 
    $ oc -n openstack get oscp  $(oc get oscp -o custom-columns=NAME:.metadata.name --no-headers) -o jsonpath='{.spec.glance.template.glanceAPIs}' | jq
  2. Identify the current glanceAPI that is registered in the Keystone catalog: 
    $ oc -n openstack get oscp $(oc get oscp -o custom-columns=NAME:.metadata.name --no-headers) -o jsonpath='{.spec.glance.template.keystoneEndpoint}'
  3. Verify that the new glanceAPI has a Keystone endpoint: 
    $ oc exec -it openstackclient bash -- openstack endpoint list | grep image
  4. If the glanceAPI that you are removing is the API registered in the Keystone catalog, open your OpenStackControlPlane CR file, openstack_control_plane.yaml to decommission the API and update the keystoneEndpoint parameter. In the following example, you remove the glanceAPI that is named default and update the keystoneEndpoint parameter to default1: 
    ...
apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
spec:
  glance:
    template:
      keystoneEndpoint: default1
      glanceAPIs:
        default1:
          type: single
          replicas: 1
      storage:
        storageRequest: 10G
...
  5. Update the control plane: 
    $ oc apply -f openstack_control_plane.yaml -n openstack
  6. Wait until RHOCP creates the resources related to the OpenStackControlPlane CR. Run the following command to check the status: 
    $ oc get openstackcontrolplane -n openstack

    The OpenStackControlPlane resources are created when the status is "Setup complete".

    Tip
    Append the -w option to the end of the get command to track deployment progress.

Image signature verification
Copy link

You can use image signature verification to validate images that are uploaded to the Image service (glance) before storing the images in the configured back end. If validation fails for an image, then the upload is stopped and the image is deleted.

To protect image integrity and authenticity, you can save the signatures and public key certificates as image properties.

You store the secret for signature verification in the Key Manager service (barbican), and the Image service interacts with the Key Manager service through the internal endpoint provided by the Identity service (keystone):

[key_manager]
backend = barbican

[barbican]
auth_endpoint={{ .KeystoneInternalURL }}
barbican_endpoint_type=internal

Other services, such as the Compute service (nova) can use the image properties to perform data validation when a user downloads the image from the Image service.

Note
Image signing and verification is not supported if the Compute service (nova) is using Ceph RADOS Block Device (RBD) to store virtual machines disks.

Metadef API security
Copy link

In Red Hat OpenStack Services on OpenShift (RHOSO), you can define key value pairs and tag metadata with metadata definition (metadef) APIs. There is no limit on the number of metadef namespaces, objects, properties, resources, or tags that you can create.

Image service policies control metadef APIs. By default, only administrators can create, update, or delete (CUD) metadef APIs. This limitation prevents metadef APIs from exposing information to unauthorized users and mitigates the risk of a malicious user filling the Image service (glance) database with unlimited resources, which can create a denial of service (DoS) style attack.