Open Stack

Asha,
We landed the fix in: https://review.openstack.org/#/c/183391/
Hopefully, that should address the problem you've been seeing.

Thanks!

John Vrbanac


On Thu, 2015-05-14 at 18:14 -0500, Douglas Mendizábal wrote:
> Hi Asha,
> 
> The reason we support an Unauthenticated Context in Barbican is purely
> for development purposes.  We recommend that all production Barbican
> deployments use Keystone or an alternative AuthN/AuthZ service in
> front of Barbican.
> 
> Setting up a working Keystone environment just to hack on Barbican is
> a steep requirement, which is why we need the Unauthenticated Context
> to work.
> 
> - Douglas Mendizabal
> 
> On 5/14/15 6:07 PM, Asha Seshagiri wrote:
> > Thanks a lot John for your response. But would like to know why do
> > would we have to fix the issue for creating the secret for
> > unauthenticated context for Barbican since it would be good to have
> > access control mechanism  enforced to access secrets , orders and
> > other entities from Barbican.
> > 
> > This should be the expected behavior from security perspective .And
> > also we are able to access secrets by providing the right token
> > from the Identity service (Keystone ). Looking forward for your
> > response.
> > 
> > Thanks and Regards, Asha Seshagiri
> > 
> > On Thu, May 14, 2015 at 4:43 PM, John Vrbanac 
> > <john.vrbanac at rackspace.com <mailto:john.vrbanac at rackspace.com>>
> > wrote:
> > 
> > __ Asha, I spent some time looking into this, It looks to be a
> > regression that occurred a few days ago when a CR was merged that
> > moved us over to oslo_context. I have reported the issue here: 
> > https://bugs.launchpad.net/barbican/+bug/1455247
> > 
> > I have a couple ideas on how to fix it, so keep your eyes out for
> > a CR to resolve the issue.
> > 
> > John Vrbanac
> > 
> > 
> > 
> > On Thu, 2015-05-14 at 12:26 -0500, Asha Seshagiri wrote:
> >> Hi all ,
> >> 
> >> 
> >> We are able to execute the curl commands on new barbican code 
> >> provided we integrated it with keystone . I ran into this issue
> >> because I was trying to configure localhost to actual IP on a
> >> plain barbican server so that I would get the response and
> >> request objects with the actual IP rather than the local host . 
> >> This configuration was required for seting up HA proxy for
> >> Barbican.
> >> 
> >> And then I thought of integrating with the keystone and
> >> configure Babrican server to https.
> >> 
> >> *Its a good learning to know that the latest code drop of
> >> Barbican enforces the authentication mechanism with the keystone
> >> which would not allow us to execute the curl command without
> >> providing the token of Identity service (Keystone ) in the
> >> request unlike the previous Barbican versions*
> >> 
> >> Please find the curl command request and responses for 
> >> uploading/reteriving the secets on Barbican Server
> >> 
> >> root at Clientfor-HAProxy barbican]# curl -X POST -H 
> >> 'content-type:application/json' -H 'X-Project-Id:12345' \
> >>> -H "X-Auth-Token:c9ac81784e1e4e089fccbca19f862be2" -d
> >> '{"payload": "my-secret-here","payload_content_type":
> >> "text/plain"}' \
> >>> -k https://localhost:9311/v1/secrets
> >> {"secret_ref": 
> >> "https://localhost:9311/v1/secrets/02336016-623b-4deb-bca5-caedc0bf0e
> 35"}[root at Clientfor-HAProxy
> >>
> >> 
> barbican]#
> >> 
> >> [root at Clientfor-HAProxy barbican]# curl -H 'Accept: 
> >> application/json' -H 'X-Project-Id:12345' \
> >>> -H "X-Auth-Token:c9ac81784e1e4e089fccbca19f862be2" -k
> >> https://localhost:9311/v1/secrets {"secrets": [{"status":
> >> "ACTIVE", "secret_type": "opaque", "updated":
> >> "2015-05-14T16:35:44.109536", "name": null, "algorithm": null,
> >> "created": "2015-05-14T16:35:44.103982", "secret_ref": 
> >> "https://localhost:9311/v1/secrets/02336016-623b-4deb-bca5-caedc0bf0e
> 35",
> >>
> >> 
> "content_types": {"default": "text/plain"}, "creator_id":
> >> "cedd848a8a9e410196793c601c03b99a", "mode": null, "bit_length": 
> >> null, "expiration": null}], "total": 1}[root at Clientfor-HAProxy 
> >> barbican]#
> >> 
> >> Thanks and Regards, Asha Seshagiri
> >> 
> >> On Wed, May 13, 2015 at 4:26 PM, Asha Seshagiri 
> >> <asha.seshagiri at gmail.com <mailto:asha.seshagiri at gmail.com>>
> >> wrote:
> >> 
> >> Hi all ,
> >> 
> >> 
> >> 
> >> When I started  debugging ,we find that default group  is not 
> >> used instead oslo_policy would be used
> >> 
> >> Please find the logs below :
> >> 
> >> 
> >> *2015-05-13 15:59:34.393 13210 WARNING oslo_config.cfg [-] Option
> >> "policy_default_rule" from group "DEFAULT" is deprecated. Use
> >> option "policy_default_rule" from group "oslo_policy".* 
> >> *2015-05-13 15:59:34.394 13210 WARNING oslo_config.cfg [-] Option
> >> "policy_file" from group "DEFAULT" is deprecated. Use option
> >> "policy_file" from group "oslo_policy".* 2015-05-13 15:59:34.395
> >> 13210 DEBUG oslo_policy.openstack.common.fileutils 
> >> [req-0c6d2db4-bc15-4752-93ca-5203cf742d79 - 12345 - - -] 
> >> Reloading cached file /etc/barbican/policy.json read_cached_file 
> >> /usr/lib/python2.7/site-packages/oslo_policy/openstack/common/fileuti
> ls.py:64
> >>
> >> 
> 2015-05-13 15:59:34.398 13210 DEBUG oslo_policy.policy
> >> [req-0c6d2db4-bc15-4752-93ca-5203cf742d79 - 12345 - - -] Reloaded
> >> policy file: /etc/barbican/policy.json _load_policy_file 
> >> /usr/lib/python2.7/site-packages/oslo_policy/policy.py:424 
> >> 2015-05-13 15:59:34.399 13210 ERROR barbican.api.controllers 
> >> [req-0c6d2db4-bc15-4752-93ca-5203cf742d79 - 12345 - - -] Secret
> >> creation attempt not allowed - please review your user/project
> >> privileges 2015-05-13 15:59:34.399 13210 TRACE
> >> barbican.api.controllers Traceback (most recent call last): 
> >> 2015-05-13 15:59:34.399 13210 TRACE barbican.api.controllers File
> >> "/root/barbican/barbican/api/controllers/__init__.py", line 104,
> >> in handler 2015-05-13 15:59:34.399 13210 TRACE 
> >> barbican.api.controllers     return fn(inst, *args, **kwargs) 
> >> 2015-05-13 15:59:34.399 13210 TRACE barbican.api.controllers File
> >> "/root/barbican/barbican/api/controllers/__init__.py", line 85,
> >> in enforcer 2015-05-13 15:59:34.399 13210 TRACE 
> >> barbican.api.controllers     _do_enforce_rbac(inst, 
> >> pecan.request, action_name, ctx, **kwargs) 2015-05-13
> >> 15:59:34.399 13210 TRACE barbican.api.controllers File
> >> "/root/barbican/barbican/api/controllers/__init__.py", line 68,
> >> in _do_enforce_rbac 2015-05-13 15:59:34.399 13210 TRACE 
> >> barbican.api.controllers     credentials, do_raise=True) 
> >> 2015-05-13 15:59:34.399 13210 TRACE barbican.api.controllers File
> >> "/usr/lib/python2.7/site-packages/oslo_policy/policy.py", line
> >> 493, in enforce 2015-05-13 15:59:34.399 13210 TRACE 
> >> barbican.api.controllers     raise PolicyNotAuthorized(rule, 
> >> target, creds) 2015-05-13 15:59:34.399 13210 TRACE
> >> barbican.api.controllers PolicyNotAuthorized: secrets:post on
> >> {u'payload': u'my-secret-here', u'payload_content_type':
> >> u'text/plain'} by {'project': '12345', 'user': None, 'roles': []}
> >> disallowed by policy 2015-05-13 15:59:34.399 13210 TRACE
> >> barbican.api.controllers 2015-05-13 15:59:34.400 13210 INFO 
> >> barbican.api.middleware.context 
> >> [req-0c6d2db4-bc15-4752-93ca-5203cf742d79 - 12345 - - -] 
> >> req-556e8733-aea2-4acf-ac8b-30bc671a6f22 | Processed request: 403
> >> Forbidden - POST http://localhost:9311/v1/secrets {address space
> >> usage: 364666880 bytes/347MB} {rss usage: 65622016 bytes/62MB}
> >> [pid: 13210|app: 0|req: 1/1] 127.0.0.1 () {30 vars in 358 bytes}
> >> [Wed May 13 15:59:34 2015] POST /v1/secrets => generated 134
> >> bytes in 7 msecs (HTTP/1.1 403) 4 headers in 179 bytes (1
> >> switches on core 0) announcing my loyalty to the Emperor... Wed
> >> May 13 15:59:34 2015 - [emperor] vassal barbican-api.ini is now
> >> loyal
> >> 
> >> 
> >> Hence I tried changing  policy_default_rule value in the 
> >> barbican.conf file to oslo_policy instead of default  and then 
> >> restarting it .It did not work . Please find the rule below :
> >> 
> >> 
> >> *# Rule checked when requested rule is not found (string value)* 
> >> *policy_default_rule=oslo_policy*
> >> 
> >> *[root at Clientfor-HAProxy ~]# curl -X POST -H 
> >> 'content-type:application/json' -H 'X-Project-Id:12345' -d 
> >> '{"payload": "my-secret-here", "payload_content_type": 
> >> "text/plain"}' http://localhost:9311/v1/secrets* *{"code": 403,
> >> "description": "Secret creation attempt not allowed - please
> >> review your user/project privileges", "title": "Forbidden"}*
> >> 
> >> 
> >> It would be great if some one could help me out with this.Any 
> >> help would be highly appreciated.
> >> 
> >> Thanks in advance
> >> 
> >> 
> >> 
> >> Thanks and Regards,
> >> 
> >> Asha Seshagiri
> >> 
> >> 
> >> 
> >> On Tue, May 12, 2015 at 6:31 PM, Asha Seshagiri 
> >> <asha.seshagiri at gmail.com <mailto:asha.seshagiri at gmail.com>> 
> >> wrote:
> >> 
> >> Hi All ,
> >> 
> >> 
> >> Installed the barbican today taking the source from github and
> >> executed the basic curl commands for retrieving and uploading the
> >> secrets.
> >> 
> >> Was unable to  execute the curl commands for retrieving and
> >> uploading the secrets. Please find the request and response for
> >> the command :
> >> 
> >> [root at Clientfor-HAProxy ~]# curl -X POST -H 
> >> 'content-type:application/json' -H 'X-Project-Id:12345' -d 
> >> '{"payload": "my-secret-here", "payload_content_type": 
> >> "text/plain"}' http://localhost:9311/v1/secrets *{"code": 403,
> >> "description": "Secret creation attempt not allowed - please
> >> review your user/project privileges", "title": "Forbidden"}* 
> >> [root at Clientfor-HAProxy ~]# curl -H 'X-Project-Id: 12345' 
> >> http://localhost:9311/v1/secrets *{"code": 403, "description":
> >> "Secret(s) retrieval attempt not allowed - please review your
> >> user/project privileges", "title": "Forbidden"}*
> >> 
> >> 
> >> Would like to know the changes that needs to be done in order to
> >> execute the basic curl commands for Barbican.
> >> 
> >> Also noticed that admin config files are not loaded and only the
> >> APi file is loaded .Please find the logs below :
> >> 
> >> 
> >> *** Operational MODE: single process *** *** uWSGI is running in
> >> multiple interpreter mode *** spawned uWSGI master process (pid:
> >> 9299) Tue May 12 16:23:09 2015 - [emperor] vassal 
> >> barbican-api.ini has been spawned spawned uWSGI worker 1 (pid:
> >> 9300, cores: 1) *Loading paste environment: 
> >> config:/etc/barbican/barbican-api-paste.ini* 2015-05-12
> >> 16:23:11.036 9300 INFO barbican.model.repositories [-] Setting up
> >> database engine and session factory 2015-05-12 16:23:11.044 9300
> >> DEBUG sqlalchemy.pool.NullPool [-] Created new connection 
> >> <sqlite3.Connection object at 0x53d8dc8> __connect 
> >> /usr/lib64/python2.7/site-packages/sqlalchemy/pool.py:540 
> >> 2015-05-12 16:23:11.045 9300 DEBUG sqlalchemy.pool.NullPool [-]
> >> Connection <sqlite3.Connection object at 0x53d8dc8> checked out
> >> from pool checkout 
> >> /usr/lib64/python2.7/site-packages/sqlalchemy/pool.py:458 
> >> 2015-05-12 16:23:11.046 9300 DEBUG sqlalchemy.pool.NullPool [-]
> >> Connection <sqlite3.Connection object at 0x53d8dc8> being
> >> returned to pool _finalize_fairy 
> >> /usr/lib64/python2.7/site-packages/sqlalchemy/pool.py:562 
> >> 2015-05-12 16:23:11.046 9300 DEBUG sqlalchemy.pool.NullPool [-]
> >> Connection <sqlite3.Connection object at 0x53d8dc8> 
> >> rollback-on-return _reset 
> >> /usr/lib64/python2.7/site-packages/sqlalchemy/pool.py:698 
> >> 2015-05-12 16:23:11.046 9300 DEBUG sqlalchemy.pool.NullPool [-]
> >> Closing connection <sqlite3.Connection object at 0x53d8dc8>
> >> _close_connection 
> >> /usr/lib64/python2.7/site-packages/sqlalchemy/pool.py:248
> >> 
> >> 
> >> 
> >> 
> >> *Any help would be highly appreciated since this would impact my
> >> work on setting up HA proxy for Barbican*
> >> 
> >> Thanks in advance !
> >> 
> >> 
> >> --
> >> 
> >> /Thanks and Regards,/
> >> 
> >> /Asha Seshagiri/
> >> 
> >> 
> >> 
> >> 
> >> --
> >> 
> >> /Thanks and Regards,/
> >> 
> >> /Asha Seshagiri/
> >> 
> >> 
> >> 
> >> 
> >> -- /Thanks and Regards,/ /Asha Seshagiri/ 
> >> _____________________________________________________________________
> _____
> >>
> >> 
> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: OpenStack-dev-request at lists.openstack.org
> >> <mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscrib
> e
> >>
> >> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> > ______________________________________________________________________
> ____
> >
> > 
> OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: 
> > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe 
> > <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
> >
> > 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> > 
> > 
> > 
> > -- /Thanks and Regards,/ /Asha Seshagiri/
> > 
> > 
> > ______________________________________________________________________
> ____
> >
> > 
> OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe 
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev