yahoo-eng-team team mailing list archive

[Stephen Balukoff <stephen@xxxxxxxxxxxx>]

Public bug reported:

I'm hoping this is something that will go away with the neutron-lbaas
and Octavia merge.

Create a self-signed certificate like so:

openssl genrsa -des3 -out self-signed_encrypted.key 2048
openssl rsa -in self-signed_encrypted.key -out self-signed.key
openssl req -new -x509 -days 365 -key self-signed.key -out self-signed.crt

As the admin user, grant the demo user the ability to create cloud
resources on the demo project:

openstack role add --project demo --user demo creator

Now, become the demo user:

source ~/devstack/openrc demo demo

As the demo user, upload the self-signed certificate to barbican:

openstack secret store --name='test_cert' --payload-content-type='text/plain' --payload="$(cat self-signed.crt)"
openstack secret store --name='test_key' --payload-content-type='text/plain' --payload="$(cat self-signed.key)"
openstack secret container create --name='test_tls_container' --type='certificate' --secret="certificate=$(openstack secret list | awk '/ test_cert / {print $2}')" --secret="private_key=$(openstack secret list | awk '/ test_key / {print $2}')"

As the demo user, grant access to the the above secrets BUT NOT THE
CONTAINER to the 'admin' user. In my test, the admin user has ID:
02c0db7c648c4714971219ae81817ba7

openstack acl user add -u 02c0db7c648c4714971219ae81817ba7 $(openstack secret list | awk '/ test_cert / {print $2}')
openstack acl user add -u 02c0db7c648c4714971219ae81817ba7 $(openstack secret list | awk '/ test_key / {print $2}')

Now, as the demo user, attempt to deploy a neutron-lbaas listener using
the secret container above:

neutron lbaas-loadbalancer-create --name lb1 private-subnet
neutron lbaas-listener-create --loadbalancer lb1 --protocol-port 443 --protocol TERMINATED_HTTPS --name listener1 --default-tls-container=$(openstack secret container list | awk '/ test_tls_container / {print $2}')

The neutron-lbaas command succeeds, but the Octavia deployment fails
since it can't access the secret container.

This is fixed if you remember to grant access to the TLS container to
the admin user like so:

openstack acl user add -u 02c0db7c648c4714971219ae81817ba7 $(openstack
secret container list | awk '/ test_tls_container / {print $2}')

However, neutron-lbaas and octavia should have similar failure scenarios
if the permissions aren't set up exactly right in any case.

** Affects: neutron
     Importance: Undecided
         Status: New

** Affects: octavia
     Importance: Undecided
         Status: New


** Tags: tls

** Also affects: neutron
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1627393

Title:
  Neuton-LBaaS and Octavia out of synch if TLS container secret ACLs not
  set up correctly

Status in neutron:
  New
Status in octavia:
  New

Bug description:
  I'm hoping this is something that will go away with the neutron-lbaas
  and Octavia merge.

  Create a self-signed certificate like so:

  openssl genrsa -des3 -out self-signed_encrypted.key 2048
  openssl rsa -in self-signed_encrypted.key -out self-signed.key
  openssl req -new -x509 -days 365 -key self-signed.key -out self-signed.crt

  As the admin user, grant the demo user the ability to create cloud
  resources on the demo project:

  openstack role add --project demo --user demo creator

  Now, become the demo user:

  source ~/devstack/openrc demo demo

  As the demo user, upload the self-signed certificate to barbican:

  openstack secret store --name='test_cert' --payload-content-type='text/plain' --payload="$(cat self-signed.crt)"
  openstack secret store --name='test_key' --payload-content-type='text/plain' --payload="$(cat self-signed.key)"
  openstack secret container create --name='test_tls_container' --type='certificate' --secret="certificate=$(openstack secret list | awk '/ test_cert / {print $2}')" --secret="private_key=$(openstack secret list | awk '/ test_key / {print $2}')"

  As the demo user, grant access to the the above secrets BUT NOT THE
  CONTAINER to the 'admin' user. In my test, the admin user has ID:
  02c0db7c648c4714971219ae81817ba7

  openstack acl user add -u 02c0db7c648c4714971219ae81817ba7 $(openstack secret list | awk '/ test_cert / {print $2}')
  openstack acl user add -u 02c0db7c648c4714971219ae81817ba7 $(openstack secret list | awk '/ test_key / {print $2}')

  Now, as the demo user, attempt to deploy a neutron-lbaas listener
  using the secret container above:

  neutron lbaas-loadbalancer-create --name lb1 private-subnet
  neutron lbaas-listener-create --loadbalancer lb1 --protocol-port 443 --protocol TERMINATED_HTTPS --name listener1 --default-tls-container=$(openstack secret container list | awk '/ test_tls_container / {print $2}')

  The neutron-lbaas command succeeds, but the Octavia deployment fails
  since it can't access the secret container.

  This is fixed if you remember to grant access to the TLS container to
  the admin user like so:

  openstack acl user add -u 02c0db7c648c4714971219ae81817ba7 $(openstack
  secret container list | awk '/ test_tls_container / {print $2}')

  However, neutron-lbaas and octavia should have similar failure
  scenarios if the permissions aren't set up exactly right in any case.

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