yahoo-eng-team team mailing list archive

[John Dennis <jdennis@xxxxxxxxxx>]

Public bug reported:

The Oslo Policy Enforcer requires 3 pieces of run-time information in
addition to the policy rules to issue a RBAC decision:

1) the name of the rule to be evaluated (called target in the oslo-policy doc)
2) the auth context (called credentials in the oslo-policy doc)
3) the target data (resource data relevant to the rule)

If you are trying to debug policy enforcement or simply validate your
policy works as expect one can use the oslopolicy-checker tool. But the
oslopolicy-checker tool needs the *exact* same data keystone passes to
the policy enforcement engine.

The fact the target data needs to be logged but isn't is captured in
this comment from Henry Nash in authorize.py

    # TODO(henry-nash) need to log the target attributes as well

https://github.com/openstack/keystone/blob/stable/rocky/keystone/common/authorization.py#L139

But that is not the best location to log, the best place is where
oslo.policy is called to evaluate a policy rule, that occurs in
Policy.enforce() in keystone/policy/backends/policy.py

https://github.com/openstack/keystone/blob/stable/rocky/keystone/policy/backends/rules.py#L29:#L34

Here we can see it logs the rule name (e.g. action) and the auth context
(credentials)

msg = 'enforce %(action)s: %(credentials)s'

but the target data is not logged.

Besides the fact the target data is not logged is the fact the logging
relies on Python's str() method to convert an object into a string
representation. This has two problems, 1) all contained objects must
also have __str__() methods that fully log their contents, 2) the
formatting is often in Python's "representation" style which only humans
and Python can parse.

Since both the credential and targets parameters to the enforce method
are dicts (with arbitrary complex nesting) and the fact JSON is the data
format we use for data exchange and the format used by oslopolicy-
checker it makes sense to log the enforcement parameters in JSON format.
This way no data is lost (because there wasn't an appropriate formatter
for the object) and it makes it easy import the data to another tool
(again, without loss of data).

** Affects: keystone
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1804073

Title:
  Keystone fails to log policy target data

Status in OpenStack Identity (keystone):
  New

Bug description:
  The Oslo Policy Enforcer requires 3 pieces of run-time information in
  addition to the policy rules to issue a RBAC decision:

  1) the name of the rule to be evaluated (called target in the oslo-policy doc)
  2) the auth context (called credentials in the oslo-policy doc)
  3) the target data (resource data relevant to the rule)

  If you are trying to debug policy enforcement or simply validate your
  policy works as expect one can use the oslopolicy-checker tool. But
  the oslopolicy-checker tool needs the *exact* same data keystone
  passes to the policy enforcement engine.

  The fact the target data needs to be logged but isn't is captured in
  this comment from Henry Nash in authorize.py

      # TODO(henry-nash) need to log the target attributes as well

  https://github.com/openstack/keystone/blob/stable/rocky/keystone/common/authorization.py#L139

  But that is not the best location to log, the best place is where
  oslo.policy is called to evaluate a policy rule, that occurs in
  Policy.enforce() in keystone/policy/backends/policy.py

  https://github.com/openstack/keystone/blob/stable/rocky/keystone/policy/backends/rules.py#L29:#L34

  Here we can see it logs the rule name (e.g. action) and the auth
  context (credentials)

  msg = 'enforce %(action)s: %(credentials)s'

  but the target data is not logged.

  Besides the fact the target data is not logged is the fact the logging
  relies on Python's str() method to convert an object into a string
  representation. This has two problems, 1) all contained objects must
  also have __str__() methods that fully log their contents, 2) the
  formatting is often in Python's "representation" style which only
  humans and Python can parse.

  Since both the credential and targets parameters to the enforce method
  are dicts (with arbitrary complex nesting) and the fact JSON is the
  data format we use for data exchange and the format used by
  oslopolicy-checker it makes sense to log the enforcement parameters in
  JSON format. This way no data is lost (because there wasn't an
  appropriate formatter for the object) and it makes it easy import the
  data to another tool (again, without loss of data).

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1804073/+subscriptions