4.4. Distributing Ceph secret keys across sites

When you deploy a distributed compute node (DCN) environment with multiple Red Hat Ceph Storage backends, you create a Ceph authentication key for each backend. Limiting key distribution to only necessary credentials minimizes security exposure at each location.

Add the key for each Ceph backend to the secret for the default location.
Add the key for the default Ceph backend, as well as the local ceph backend for each additional location.

For three locations, az0, az1, and az2, you must have three secrets. Locations az1 and az2 each have keys for the local backend as well as the keys for az0. Location az0 contains all Ceph back end keys.

You create the required secrets after Ceph has been deployed at each edge location, and the keyring and configuration file for each has been collected. Alternatively, you can deploy each Ceph backend as needed, and update secrets with each edge deployment.

Procedure

Create a secret for location az0.

If you have already deployed Red Hat Ceph Storage (RHCS) at all edge sites which require storage, create a secret for az0 which contains all keyrings and conf files:

oc create secret generic ceph-conf-az-0 \
--from-file=az0.client.openstack.keyring \
--from-file=az0.conf \
--from-file=az1.client.openstack.keyring \
--from-file=az1.conf \
--from-file=az2.client.openstack.keyring \
--from-file=az2.conf -n openstack

If you have not deployed RHCS at all edge sites, create a secret for az0 which contains the keyring and conf file for az0:

oc create secret generic ceph-conf-az-0 \
--from-file=az0.client.openstack.keyring \
--from-file=az0.conf -n openstack

When you deploy RHCS at the edge location at availability zone 1 (az1), create a secret for location az1 which contains keyrings and conf files for the local backend, and the default backend:
```
oc create secret generic ceph-conf-az-1 \
--from-file=az0.client.openstack.keyring \
--from-file=az0.conf \
--from-file=az1.client.openstack.keyring \
--from-file=az1.conf -n openstack
```

If needed, update the secret for the central location:

oc delete secret ceph-conf-az-0 -n openstack

oc create secret generic ceph-conf-az-0 \
--from-file=az0.client.openstack.keyring \
--from-file=az0.conf \
--from-file=az1.client.openstack.keyring \
--from-file=az1.conf -n openstack

When you deploy RHCS at the edge location at availability zone 2 (az2) create a secret for location az2 which contains keyrings and conf files for the local backend, and the default backend:
```
oc create secret generic ceph-conf-az-2 \
--from-file=az0.client.openstack.keyring \
--from-file=az0.conf \
--from-file=az2.client.openstack.keyring \
--from-file=az2.conf -n openstack
```

If needed, update the secret for the central location:

oc delete secret ceph-conf-az-0 -n openstack

oc create secret generic ceph-conf-az-0 \
--from-file=az0.client.openstack.keyring \
--from-file=az0.conf \
--from-file=az1.client.openstack.keyring \
--from-file=az1.conf \
--from-file=az1.client.openstack.keyring \
--from-file=az1.conf \
--from-file=az2.client.openstack.keyring \
--from-file=az2.conf

[Optional] When you have finished creating the necessary keys, you can verify that they show up in the openstack namespace:
```
oc get secret -n openstack -o name | grep ceph-conf
```
Example output:
```
secret/ceph-conf-az-0
secret/ceph-conf-az-1
secret/ceph-conf-az-2
```

When you create an OpenStackDataPlaneNodeSet, use the appropriate key under the extraMounts field:

apiVersion: dataplane.openstack.org/v1beta1
kind: OpenStackDataPlaneNodeSet
metadata:
  name: openstack-edpm-dcn-0
  namespace: openstack
spec:
  ...
  nodeTemplate:
    extraMounts:
    - extraVolType: Ceph
      volumes:
      - name: ceph
        secret:
          secretName: ceph-conf-az-0
      mounts:
      - name: ceph
        mountPath: "/etc/ceph"
        readOnly: true

When you create a data plane NodeSet, you must also update the OpenStackControlPlane custom resource (CR) with the secret name:

apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
spec:
  extraMounts:
    - name: v1
      region: r1
      extraVol:
        - propagation:
          - az0
          - CinderBackup
          extraVolType: Ceph
          volumes:
          - name: ceph
            secret:
              name: ceph-conf-az-0
          mounts:
          - name: ceph
            mountPath: "/etc/ceph"
            readOnly: true
        - propagation:
          - az1
          extraVolType: Ceph
          volumes:
          - name: ceph
            secret:
              name: ceph-conf-az-1
          mounts:
          - name: ceph
            mountPath: "/etc/ceph"
            readOnly: true
        ...

참고

If the CinderBackup service is a part of the deployment, then you must include it in the propagation list because it does not have the availability zone in its pod name.

When you update the glanceAPIs field in the OpenStackControlPlane CR, the Image service (glance) pod name matches the extraMounts propagation instances:
```
     glanceAPIs:
       az0:
         customServiceConfig: |
         ...
       az1:
         customServiceConfig: |
         ...
```
When you update the cinderVolumes field in the OpenStackControlPlane CR, the Block Storage service (cinder) pod names must also match the extraMounts propagation instances:
```
kind: OpenStackControlPlane
spec:
  <...>
  cinder
    <...>
    cinderVolumes:
      az0:
        <...>
      az1:
        <...>
```

Additional resources

Preparing Red Hat OpenShift Container Platform for Red Hat OpenStack Services on OpenShift

4.4. Distributing Ceph secret keys across sites

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 소개

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat 문서 정보

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links