Open Stack

Hello Robert,

You should get 400 errors for unauthenticated requests, so it seems barbican still isn't running with keystone. Can you reply back with your /etc/barbican/barbican-api-paste.ini file (with passwords removed)?

Thanks,
John


________________________________
From: Robert Marshall -X (robemars - TEKSYSTEMS INC at Cisco) [robemars at cisco.com]
Sent: Thursday, July 17, 2014 11:28 AM
To: openstack-dev at lists.openstack.org
Subject: [openstack-dev] Barbican doesn't authenticate with Keystoine for one particular tenant

We have configure Barbican and Keystone according to the documentation and the direction provided by John Wood. We see Barbican authenticating with Keystone. The problem we see is that when we use the “service” tenant, we can retrieve secrets without authenticating with Keystone, where the “service” tenant is the tenant that we associate with the “barbican” service in Keystone:

(barbican27)[root at iac-int-ma15 ~]# curl -XGET -d '{}' -H "Content-type: application/json" -H "X_IDENTITY_STATUS: Confirmed" -H "X_AU
TH_TOKEN:"  http://localhost:9311/v1/474bc6aec82f447ca5e4452516e0b2aa/secrets                                                                                                    <=========  Empty token   -   “admin” tenant UID
{"secrets": [], "total": 0}                                                                                                                                                                                                                    <========= Doesn’t authenticate therefore no secrets


(barbican27)[root at iac-int-ma15 ~]# curl -XGET -d '{}' -H "Content-type: application/json" -H "X_IDENTITY_                                                             <========= Empty token   -    “service” tenant UID
TH_TOKEN:"  http://localhost:9311/v1/4d9cc78fdd7746c1895d0c0fc37d8a24/secrets                                                                                                     <========= Shouldn’t authenticate, but secrets returned
{"secrets": [{"status": "ACTIVE", "secret_ref": "http://localhost:9311/v1/4d9cc78fdd7746c1895d0c0fc37d8a24/secrets/88a99c9f-5c32-444
6-8868-f732ca0c8df3", "updated": "2014-07-09T14:21:53.845324", "name": "test", "algorithm": null, "created": "2014-07-09T14:21:53.84
5315", "content_types": {"default": "text/plain"}, "mode": null, "bit_length": null, "expiration": null}, {"status": "ACTIVE", "secr
et_ref": "http://localhost:9311/v1/4d9cc78fdd7746c1895d0c0fc37d8a24/secrets/005c4bba-959e-4deb-9be3-1115516ff20f", "updated": "2014-
07-09T14:33:13.908756", "name": "ppm", "algorithm": null, "created": "2014-07-09T14:33:13.908746", "content_types": {"default": "tex
t/plain"}, "mode": null, "bit_length": null, "expiration": null}, {"status": "ACTIVE", "secret_ref": "http://localhost:9311/v1/4d9cc
78fdd7746c1895d0c0fc37d8a24/secrets/1c095c70-c8bb-452d-b4c4-db0685d448b5", "updated": "2014-07-09T14:34:44.042212", "name": "nsapi",      <snip>

The following comes from the “populate-data.sh” script that we use to populate the empty Keystone DB at Keystone/Barbican setup:
# Add Roles to Users in Tenants
keystone user-role-add --user $ADMIN_USER --role $ADMIN_ROLE --tenant-id $ADMIN_TENANT
keystone user-role-add --user $SERVICE_USER --role $SERVICE_ROLE --tenant-id $SERVICE_TENANT
keystone user-role-add --user $BARBICAN_USER --role $ADMIN_ROLE  --tenant-id $SERVICE_TENANT

# Create BARBICAN Service
BARBICAN_SERVICE=$(get_id keystone service-create --name=barbican --type="keystore" --description="Barbican Key Management Service")

# Create BARBICAN Endpoint
keystone endpoint-create --region RegionOne --service_id $BARBICAN_SERVICE --publicurl "http://localhost:9311/v1" --adminurl "http://localhost:9312/v1" --internalurl http://localhost:9313/v1


Some questions:

1.      Should the “service” tenant bypass authentication and return secrets, due to its registered association with the Barbican Service?

2.      If so, is there a way to turn this off, so that the service tenant can’t be used to gather secrets?

3.      How do we turn on DEBUG in Keystone, so that we can see authentication occurring in Keystone in real time?

We are planning on distributing Barbican and Keystone as a secure keystore in an upcoming release of Cisco Systems cloud automation software, and are hoping to nail this down soon to get this release ready, so we are grateful for any help we can get to wrap this up.

Bob Marshall
Cloud Developer
Cisco Systems
Austin Campus
210-853-7041


From: John Wood [mailto:john.wood at RACKSPACE.COM]
Sent: Wednesday, July 16, 2014 5:30 PM
To: Robert Marshall -X (robemars - TEKSYSTEMS INC at Cisco)
Cc: Matt Brown -X (mattbro2 - KFORCE INC at Cisco); Yogi Porla -X (yporla - KFORCE INC at Cisco); Greg Brown (gbrown2)
Subject: RE: Barbican issue: Failure to authenticate with Keystone: Security Issue?

Hello Robert,

Please feel free to send such emails out to the public list at: openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org> and also add '[barbican]' before the subject name.

To facilitate quick evaluation of the API, out of the box Barbican is not secured: https://github.com/cloudkeep/barbican/wiki/Developer-Guide#setup-insecure-development-environment

In particular, Keystone authentication is not enabled.  See this link to enable it: https://github.com/cloudkeep/barbican/wiki/Barbican-Options:-authentication-with-Keystone#running-openstack-keystone-authentication-middleware-on-the-barbican-api-node

!!! Just a reminder as well that we are working on a production deployment of Barbican, but have not yet created one with this code base !!!

Please let me know if this helps!

Thanks,
John


________________________________
From: Robert Marshall -X (robemars - TEKSYSTEMS INC at Cisco) [robemars at cisco.com]
Sent: Wednesday, July 16, 2014 2:26 PM
To: John Wood
Cc: Matt Brown -X (mattbro2 - KFORCE INC at Cisco); Yogi Porla -X (yporla - KFORCE INC at Cisco); Greg Brown (gbrown2)
Subject: Barbican issue: Failure to authenticate with Keystone: Security Issue?
Hello John.
   We are getting close to including Barbican and Keystone as a secure credential service in the next release of Cisco’s Intelligent Automation for Cloud (IAC) and an issue has arisen. Several of us have kicked this issue around, and we are wondering if we are missing something important.
    We are using Barbican and Keystone on a management appliance within the datacenter, and expect to use the Python client on a second VM to store and retrieve all the credentials for accessing all of the other systems in the cloud that is managed by IAC. We think we have found a mode in which Barbican does not authenticate with Keystone and returns secrets to the requester.
    Our installation goes like this:

1.      Create virtualenvs for the Barbican and Keystone servers, and install the Barbican and Keystone servers therein.

2.      Create empty Barbican and Keystone databases (schemas) in PostgreSQL.

3.      Start Keystone with keystone-all, and run keystone-manage db_sync to create the (empty) tables in Keystone.

4.      Run Barbican.sh install to (among other things) create the (empty) tables in Barbican.

5.      Run a populate-data.sh script that uses the Keystone CLI to create tenants, users, roles, and the Barbican service and endpoint, as follows:
#!/bin/bash
ADMIN_PASSWORD=admin_gen_passwd
SERVICE_PASSWORD=service_gen_passwd
BARBICAN_PASSWORD=barbican_gen_passwd

export OS_SERVICE_TOKEN=ADMIN
export OS_SERVICE_ENDPOINT="http://localhost:35357/v2.0"

get_id () {
          echo `$@ | awk '/ id / { print $4 }'`
}

# Tenants
ADMIN_TENANT=$(get_id keystone tenant-create --name=admin)
SERVICE_TENANT=$(get_id keystone tenant-create --name=service)

# Users
ADMIN_USER=$(get_id keystone user-create --name=admin --pass="$ADMIN_PASSWORD" --email=user at localhost.com<mailto:--email=user at localhost.com>)
SERVICE_USER=$(get_id keystone user-create --name=PPM --pass="$SERVICE_PASSWORD" --email=user at localhost.com<mailto:--email=user at localhost.com>)
BARBICAN_USER=$(get_id keystone user-create --name=barbican --pass="$BARBICAN_PASSWORD"  --email=user at localhost.com<mailto:--email=user at localhost.com>)

# Roles
ADMIN_ROLE=$(get_id keystone role-create --name=admin)
SERVICE_ROLE=$(get_id keystone role-create --name=service)

# Add Roles to Users in Tenants
keystone user-role-add --user $ADMIN_USER --role $ADMIN_ROLE --tenant-id $ADMIN_TENANT
keystone user-role-add --user $SERVICE_USER --role $SERVICE_ROLE --tenant-id $SERVICE_TENANT
keystone user-role-add --user $BARBICAN_USER --role $ADMIN_ROLE  --tenant-id $SERVICE_TENANT

# Create BARBICAN Service
BARBICAN_SERVICE=$(get_id keystone service-create --name=barbican --type="keystore" --description="Barbican Key Management Service")

# Create BARBICAN Endpoint
keystone endpoint-create --region RegionOne --service_id $BARBICAN_SERVICE --publicurl "http://localhost:9311/v1" --adminurl "http://localhost:9312/v1" --internalurl http://localhost:9313/v1

6.      Restart Barbican using barbican.sh start
What we are subsequently seeing is users being able to retrieve decrypted secrets by passing the SERVICE_TENANT value created in the populate-data.sh script. I’m including here a message from one of our people:
Barbican is a server that stores data. Barbican uses keystone to authenticate users who wish to store and retrieve this data. Barbican should not permit any transaction to occur unless a valid session has been created by a client authenticating against keystone:


•        The client sends keystone a username, password and tenant combination.  Keystone returns an authentication token.

•        The client sends Barbican a request to retrieve some data, and provides the authentication token.

•        Barbican checks with Keystone to see if the authentication token is valid. If the authentication token is valid, it returns the requested data to the client.

What is occurring is this:


•        The client sends barbican a request to retrieve some data.

•        Barbican returns the requested data to the client.

The only security is that you have to know in advance a UID of the tenant that is holding the data you want to query. This is security through obscurity. Once you have this UID of the tenant you can forever query all data stored in barbican for that tenant without any further authentication or security checks. This is bad because an employee can get this UID while working at the company, leave and there’s no way to revoke access to the Barbican database.

I don’t know how I can make it any clearer than this. I can demonstrate that barbican is configured to not use authentication and I can demonstrate that barbican is not configured to use keystone. The configuration in the how to set up barbican with keystone guide was not followed. I can turn off keystone and drop its database and still retrieve data within barbican. This can’t be the intended operation of the system.

This was after calls of this type were made:

I’ve been doing some basic security testing on Barbican. The Barbican deployment that I received does not appear to be integrated to use Keystone authentication at all. It is returning decrypted passwords without requiring authentication. This  is why I was asking about all the default entries in the Barbican configuration files a few days ago. Can Bob and team please revisit this and provide a secure configuration that we can load into the appliance?

Here’s an example of me using the curl command to query Barbican for decrypted credentials using no authentication.

List secrets for tenant a08a91ad5e9c473a844beafbd5deb31f

curl  'http://localhost:9311/v1/a08a91ad5e9c473a844beafbd5deb31f/secrets/'

{"secrets": [{"status": "ACTIVE", "secret_ref": "http://localhost:9311/v1/a08a91ad5e9c473a844beafbd5deb31f/secrets/0c77cccd-7134-400d-aadf-e28af81df12f", "updated": "2014-07-15T20:09:43.136984", "name": "assurance", "algorithm": null, "created": "2014-07-15T20:09:43.136962", "content_types": {"default": "text/plain"}, "mode": null, "bit_length": null, "expiration": null}, {"status": "ACTIVE", "secret_ref": "http://localhost:9311/v1/a08a91ad5e9c473a844beafbd5deb31f/secrets/c43d57f2-7a56-47be-b9be-54b4e2b1fe85", "updated": "2014-07-15T20:09:55.289725", "name": "assurance", "algorithm": null, "created": "2014-07-15T20:09:55.289707", "content_types": {"default": "text/plain"}, "mode": null, "bit_length": null, "expiration": null}], "total": 2}

Query Barbican for those two secrets:

curl -H 'Accept: text/plain' http://localhost:9311/v1/a08a91ad5e9c473a844beafbd5deb31f/secrets/0c77cccd-7134-400d-aadf-e28af81df12f
{"password": "admin", "url": "https://localhost:5001<https://localhost:5001/>", "login": "service"}

curl -H 'Accept: text/plain' http://localhost:9311/v1/a08a91ad5e9c473a844beafbd5deb31f/secrets/c43d57f2-7a56-47be-b9be-54b4e2b1fe85
{"login": "gbrown2", "password": "test123", "url": "https://localhost:5001<https://localhost:5001/>"}

Did we miss something in the setup?
Thanks in advance,

Bob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140717/7552e6b5/attachment.html>