[openstack-dev] [Solum] Oslo Context and SecurityContext
angus.salkeld at rackspace.com
Tue Jan 28 23:26:54 UTC 2014
On 28/01/14 07:13 -0800, Georgy Okrokvertskhov wrote:
>From my experience context is usually bigger then just a storage for user
>credentials and specifics of request. Context usually defines an area
>within the called method should act. Probably the class name RequestContext
>is a bit confusing. The actual goal of the context should be defined by a
>service design. If you have a lot of independent components you will
>probably will ned to pass a lot of parameters to specify specifics of work,
>so it is just more convenient to have dictionary like object which carry
>all necessary information about contextual information. This context can be
>used to pass information between different components of the service.
I think we should be using the nova style objects for passing data
between solum services (they can be serialized for rpc). But you hit
on a point - this "context" needs to be called something else, it is
not a RequestContext (we need the RequestContext regardless).
I'd also suggest we don't build it until we know we
need it (I am just suspicious as the other openstack services I
have worked on don't have such a thing). Normally we just pass
arguments to methods.
How about we keep things simple and don't get
into designing a boeing, we can always add these things later if
they are really needed. I get the feeling we are being distracted from
our core problem of getting this service functional by "nice to
>On Mon, Jan 27, 2014 at 4:27 PM, Angus Salkeld
><angus.salkeld at rackspace.com>wrote:
>> On 27/01/14 22:53 +0000, Adrian Otto wrote:
>>> On Jan 27, 2014, at 2:39 PM, Paul Montgomery <
>>> paul.montgomery at RACKSPACE.COM>
>>> Solum community,
>>>> I created several different approaches for community consideration
>>>> regarding Solum context, logging and data confidentiality. Two of these
>>>> approaches are documented here:
>>>> A) Plain Oslo Log/Config/Context is in the "Example of Oslo Log and Oslo
>>>> Context" section.
>>>> B) A hybrid Oslo Log/Config/Context but SecurityContext inherits the
>>>> RequestContext class and adds some confidentiality functions is in the
>>>> "Example of Oslo Log and Oslo Context Combined with SecurityContext"
>>>> None of this code is production ready or tested by any means. Please
>>>> examine the general architecture before I polish too much.
>>>> I hope that this is enough information for us to agree on a path A or B.
>>>> I honestly am not tied to either path very tightly but it is time that we
>>>> reach a final decision on this topic IMO.
>>> I have a strong preference for using the SecurityContext approach. The
>>> main reason for my preference is outlined in the Pro/Con sections of the
>>> Wiki page. With the "A" approach, leakage of confidential information mint
>>> happen with *any* future addition of a logging call, a discipline which may
>>> be forgotten, or overlooked during future code reviews. The "B" approach
>>> handles the classification of data not when logging, but when placing the
>>> data into the SecurityContext. This is much safer from a long term
>>> maintenance perspective.
>> I think we seperate this out into:
>> 1) we need to be security aware whenever we log information handed to
>> us by the user. (I totally agree with this general statement)
>> 2) should we log structured data, non structured data or use the
>> notification mechanism (which is structured)
>> There have been some talks at summit about the potential merging of
>> the logging and notification api, I honestly don't know what
>> happened to that but have no problem with structured logging. We
>> should use the notification system so that ceilometer can take
>> advantage of the events.
>> 3) should we use a RequestContext in the spirit of the olso-incubator
>> (and inherited from it too). OR one different from all other
>> IMHO we should just use oslo-incubator RequestContext. Remember the
>> context is not a generic dumping ground for "I want to log stuff so
>> lets put it into the context". It is for user credentials and things
>> directly associated with the request (like the request_id). I don't
>> see why we need a generic dict style approach, this is more likely
>> to result in programming error context.set_priv('userid', bla)
>> instead of:
>> context.set_priv('user_id', bla)
>> I think my point is: We should very quickly zero in on the
>> attributes we need in the context and they will seldom change.
>> As far as security goes Paul has shown a good example of how to
>> change the logging_context_format_string to achieve structured and
>> secure logging of the context. oslo log module does not log whatever
>> is in the context but only what is configured in the solum.conf (via
>> logging_context_format_string). So I don't believe that the
>> new/different RequestContext provides any improved security.
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>OpenStack Platform Products,
>Tel. +1 650 963 9828
>Mob. +1 650 996 3284
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev