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)
[robem...@cisco.com]
Sent: Thursday, July 17, 2014 11:28 AM
To: openstack-dev@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@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@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.w...@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@lists.openstack.org<mailto:openstack-dev@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)
[robem...@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=u...@localhost.com<mailto:--email=u...@localhost.com>)
SERVICE_USER=$(get_id keystone user-create --name=PPM
--pass="$SERVICE_PASSWORD"
--email=u...@localhost.com<mailto:--email=u...@localhost.com>)
BARBICAN_USER=$(get_id keystone user-create --name=barbican
--pass="$BARBICAN_PASSWORD"
--email=u...@localhost.com<mailto:--email=u...@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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
