Uploaded image for project: 'openATTIC'
  1. openATTIC
  2. OP-1958

Ceph module might use the wrong keyring file



    • Sprint:
      Sprint 27, Sprint 28


      Because of this line 44 in ceph/librados.py oA uses the first keyring in this format that's readable:

      keyrings = glob.glob("{}/{}.client.*.keyring".format(ceph_dir, cluster_name))

      This keyring might be the wrong one if more than one keyring for different users are available. 


      Idea 1:

      We should check if all our API views are supported by the Ceph user permissions. This could be done by

      • Checking the permissions in the keyring file. But these don't necessarily need to represent the current permissions of the user from the Ceph perspective. For example if the permissions of a user are updated in the system but not in the keyring file.
      • We could also ask the Ceph cluster for the permissions of the user by using the ''ceph auth get client.<username>" command. But therefor we would need a connection to the Ceph cluster which we not have, because we are currently about to connect it.

      Idea 2:

      oA iterates through all keyrings in the /etc/ceph directory and takes the first readable key for the librados call. This is a little bit awkward if the Ceph configurations has its own keyring for oA for example in the SES setup.
      oA should search for its own key file at first and only consider then other keyrings if no readable oA keyring file could not be found.

      Idea 3:

      Make keyring file/identity user-configurable:
      As far as I understand, and as Sebastian W. tried to explain, oA will pick one keyring from /etc/ceph/ that has just enough permissions to be accessed by the `openattic` user.
      While this is a neat idea in principle, it falls through in case of a misconfiguration or misunderstanding by the user.
      And even though, in practice, a misconfiguration is not necessarily an openATTIC problem, the fact is that oA does not make it easy to figure out the error has been made, or what's oA's criteria for picking this file over the other.
      What this ticket now proposes, is that the keyring file (or, rather, the identity) should be user configurable. Even if the default auth identity is `client.openattic` (with its default keyring in `/etc/ceph/ceph.client.openattic.keyring`), the user should be able to configure an alternative keyring – e.g., `client.admin`.
      We should not allow oA to decide which keyring it's going to use, unless this is properly done with informative error messages to the user, not only explaining what the error is but also why it's happening and what measures the user can take to resolve the problem.


      Read more about the Ceph user management here

      downstream documentation needs to be fixed, too


          Issue Links



              rimarques Ricardo Marques
              tdehler Dehler, Tatjana
              0 Vote for this issue
              3 Start watching this issue