Enable cascading ACLs based on container ID
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Barbican |
New
|
Undecided
|
Unassigned | ||
Bug Description
Octavia needs read/reg/un-reg access to containers and the content of those containers to enable TLS offloading.
Currently there are two options to provide Octavia with access to the user's content:
1. Modify the barbican policies to allow Octavia access to all users containers/content. (This is a bad option)
2. The user explicitly gives the Octavia service account ACL access to the container and it's content.
Option two is better from a security standpoint, but provides a poor user experience in that they need to issue a lot of ACL calls to barbican and they are required to know the Octavia service account. An example of the commands (simple case) are:
openstack acl user add -u admin_id $(openstack secret list | awk '/ cert1 / {print $2}')
openstack acl user add -u admin_id $(openstack secret list | awk '/ key1 / {print $2}')
openstack acl user add -u admin_id $(openstack secret list | awk '/ intermediates1 / {print $2}')
openstack acl user add -u admin_id $(openstack secret list | awk '/ tls_container1 / {print $2}')
When the user has a large number of intermediate certificates, this an be a significant number of barbican CLI/API calls.
What we need is a single API call that Octavia can make to barbican that will add an ACL to a container and all of the container's contents. Octavia will have the user's token and the supplied container ID when they create a listener. We want to use that user token to tell barbican to authorize our service account for the container the user specified.
Octavia would make the cascade ACL call to barbican, using the user token, providing the Octavia service account and the container ID. This would cascade provide the Octavia service account permission to read/reg/un-reg for the content of the container the user provided.
