anchor.diff:  [[creating-ceph-secret]]
   === Creating the Ceph Secret
   
  -In a secret definition, the storage administrator must define the admin authorization key,
  -which is then converted to base-64 for use by OpenShift. The `ceph auth get-key` command
  -is run on a Ceph MON node to display the key value for the _client.admin_ user:
  -
  -.Ceph Secret Definition
  -====
  -[source,yaml]
  +Define the authorization key in a secret configuration, which is then converted to base64 for use by {product-title}. 
  +
  +. Run `ceph auth get-key` on a Ceph MON node to display the key value for the
  +`client.admin` user:
  ++
  +[source,yaml]
  +====
   ----
   apiVersion: v1
   kind: Secret
   metadata:
     name: ceph-secret
   data:
  -  key: QVFBOFF2SlZheUJQRVJBQWgvS2cwT1laQUhPQno3akZwekxxdGc9PQ== <1>
  -
  -----
  -<1> this base64 key is generated on one of the Ceph MON nodes using the following command:
  -  `ceph auth get-key client.admin | base64`
  -and then copying the output and pasting it as the secret key's value.
  -====
  -
  -Save the secret definition to a file, for example *_ceph-secret.yaml_*,
  -then create the secret:
  -
  +  key: QVFBOFF2SlZheUJQRVJBQWgvS2cwT1laQUhPQno3akZwekxxdGc9PQ==
  +
  +----
  +====
  +
  +. Save the secret definition to a file, for example *_ceph-secret.yaml_*, then
  +create the secret:
  ++
   ====
   ----
   $ oc create -f ceph-secret.yaml
  -secret "ceph-secret" created
  -----
  -====
  -
  -Verify that the secret was created:
  -
  +----
  +====
  +
  +. Verify that the secret was created:
  ++
   ====
   ----
   # oc get secret ceph-secret
  
positive.code:     readOnly: false
    persistentVolumeReclaimPolicy: Recycle
  ----
  <1> The name of the PV which is referenced in pod definitions or displayed in
  various `oc` volume commands.
  <2> The amount of storage allocated to this volume.
  <3> `accessModes` are used as labels to match a PV and a PVC. They currently
  do not define any form of access control. All block storage is defined to be
  single user (non-shared storage).
  <4> This defines the volume type being used, in this case the *rbd* plug-in.
  <5> This is an array of Ceph monitor ip addresses and ports.
  <6> This is the Ceph secret, defined above, used to create a secure connection
  from OpenShift to the Ceph server.
  <7> This is the file system type mounted on the Ceph RBD block device.
  ====
  
  Save your definition to a file, for example *_ceph-pv.yaml_*, and create the
  persistent volume:
  
  ====
  ----
  # oc create -f ceph-pv.yaml
  persistentvolume "ceph-pv" created
  ----
  ====
  
  Verify that the persistent volume was created:
  
  ====
  ----
  # oc get pv
  
negative.code: Security] before implementing Ceph RBD volumes.
  ====
  
  A significant difference between shared volumes (NFS and GlusterFS) and block
  volumes (Ceph RBD, iSCSI, and most cloud storage), is that the user and group
  IDs defined in the pod definition or docker image are applied to the target
  physical storage. This is referred to as managing ownership of the block device.
  For example, if the Ceph RBD mount has its owner set to *123* and its group ID
  set to *567*, and if the pod defines its `runAsUser` set to *222* and its
  `fsGroup` to be *7777*, then the Ceph RBD physical mount's ownership will be
  changed to *222:7777*.
  
  [NOTE]
  ====
  Even if the user and group IDs are not defined in the pod specification, the
  resulting pod may have defaults defined for these IDs based on its matching SCC,
  or its project. The
  link:../../install_config/persistent_storage/pod_security_context[pod security
  section] covers storage aspects of SCCs and defaults in greater detail.
  ====
  
  A pod defines the group ownership of a Ceph RBD volume using the `*fsGroup*`
  stanza under the pod's `*securityContext*` definition:
  
  [source,yaml]
  ====
  ----
  spec:
  