| 2017-03-20 14:03:03 |
Pushkar Umaranikar |
bug |
|
|
added bug |
| 2017-03-20 14:03:19 |
Pushkar Umaranikar |
tags |
|
rfe |
|
| 2017-03-20 14:04:21 |
Pushkar Umaranikar |
description |
When other services like Nova talks to the Neutron REST API, it uses an admin token, in some scenarios like setting the port binding on a port. In these cases, the admin token is
used to ensure only Nova has access to the binding API, not the end user.
With the introduction of service token, we can use service token instead of
admin token to perform metadata API services related operations which
currently uses admin token.
In Ocata, Nova started sending a service token along with the user token, so Neutron already
knows it is Nova sending a request on behalf of the user.
https://review.openstack.org/#/c/410394/
We can make use new role added by keystoneauth.
"service_roles": "service:nova"
The above role can be used in policy to define level of access for an
action when service token is used along with user context. This allows to perform any actions for which we have added service role in policy configurations.
For example, if we want to perform "binding port to host id" operation with
service token authentication, we will pass service token along with auth token
to communicate with Neutron. In this case, Neutron policy should also allow
performing this operation with "service_roles".
Spec in Nova:
https://review.openstack.org/#/c/439890/ |
When other services like Nova talks to the Neutron REST API, it uses an admin token, in some scenarios like setting the port binding on a port. In these cases, the admin token is
used to ensure only Nova has access to the binding API, not the end user.
With the introduction of service token, we can use service token instead of
admin token to perform metadata API services related operations which
currently uses admin token.
In Ocata, Nova started sending a service token along with the user token, so Neutron already
knows it is Nova sending a request on behalf of the user.
https://review.openstack.org/#/c/410394/
We can make use new role added by keystoneauth.
"service_roles": "service:nova"
The above role can be used in policy to define level of access for an
action when service token is used along with user context. This allows to perform any actions for which we have added service role in policy configurations.
For example, if we want to perform "binding port to host id" operation with service token authentication, we will pass service token along with auth token to communicate with Neutron. In this case, Neutron policy should also allow performing this operation with "service_roles".
Spec in Nova:
https://review.openstack.org/#/c/439890/ |
|
| 2017-03-20 14:05:26 |
Pushkar Umaranikar |
description |
When other services like Nova talks to the Neutron REST API, it uses an admin token, in some scenarios like setting the port binding on a port. In these cases, the admin token is
used to ensure only Nova has access to the binding API, not the end user.
With the introduction of service token, we can use service token instead of
admin token to perform metadata API services related operations which
currently uses admin token.
In Ocata, Nova started sending a service token along with the user token, so Neutron already
knows it is Nova sending a request on behalf of the user.
https://review.openstack.org/#/c/410394/
We can make use new role added by keystoneauth.
"service_roles": "service:nova"
The above role can be used in policy to define level of access for an
action when service token is used along with user context. This allows to perform any actions for which we have added service role in policy configurations.
For example, if we want to perform "binding port to host id" operation with service token authentication, we will pass service token along with auth token to communicate with Neutron. In this case, Neutron policy should also allow performing this operation with "service_roles".
Spec in Nova:
https://review.openstack.org/#/c/439890/ |
When other services like Nova talks to the Neutron REST API, it uses an admin token, in some scenarios like setting the port binding on a port. In these cases, the admin token is used to ensure only Nova has access to the binding API, not the end user.
With the introduction of service token, we can use service token instead of admin token to perform metadata API services related operations which
currently uses admin token.
In Ocata, Nova started sending a service token along with the user token, so Neutron already knows it is Nova sending a request on behalf of the user.
https://review.openstack.org/#/c/410394/
We can make use new role added by keystoneauth.
"service_roles": "service:nova"
The above role can be used in policy to define level of access for an
action when service token is used along with user context. This allows to perform any actions for which we have added service role in policy configurations.
For example, if we want to perform "binding port to host id" operation with service token authentication, we will pass service token along with auth token to communicate with Neutron. In this case, Neutron policy should also allow performing this operation with "service_roles".
Spec in Nova:
https://review.openstack.org/#/c/439890/ |
|
| 2017-03-20 14:14:03 |
Pushkar Umaranikar |
description |
When other services like Nova talks to the Neutron REST API, it uses an admin token, in some scenarios like setting the port binding on a port. In these cases, the admin token is used to ensure only Nova has access to the binding API, not the end user.
With the introduction of service token, we can use service token instead of admin token to perform metadata API services related operations which
currently uses admin token.
In Ocata, Nova started sending a service token along with the user token, so Neutron already knows it is Nova sending a request on behalf of the user.
https://review.openstack.org/#/c/410394/
We can make use new role added by keystoneauth.
"service_roles": "service:nova"
The above role can be used in policy to define level of access for an
action when service token is used along with user context. This allows to perform any actions for which we have added service role in policy configurations.
For example, if we want to perform "binding port to host id" operation with service token authentication, we will pass service token along with auth token to communicate with Neutron. In this case, Neutron policy should also allow performing this operation with "service_roles".
Spec in Nova:
https://review.openstack.org/#/c/439890/ |
When other services like Nova talks to the Neutron REST API, it uses an admin token, in some scenarios like setting the port binding on a port. In these cases, the admin token is used to ensure only Nova has access to the binding API, not the end user.
With the introduction of service token, we can use service token instead of admin token to perform metadata API services related operations which
currently uses admin token.
In Ocata, Nova started sending a service token along with the user token, so Neutron already knows it is Nova sending a request on behalf of the user.
https://review.openstack.org/#/c/410394/
We can make use new role added by keystoneauth.
"service_roles": "service:<service name>"
The above role can be used in policy to define level of access for an
action when service token is used along with user context. This allows to perform any actions for which we have added service role in policy configurations.
For example, if we want to perform "binding port to host id" operation with service token authentication, we will pass service token along with auth token to communicate with Neutron. In this case, Neutron policy should also allow performing this operation with "service_roles".
Spec in Nova:
https://review.openstack.org/#/c/439890/ |
|
| 2017-03-21 15:28:32 |
Akihiro Motoki |
neutron: status |
New |
Triaged |
|
| 2017-03-21 15:28:40 |
Akihiro Motoki |
neutron: importance |
Undecided |
Wishlist |
|
| 2017-03-21 15:37:56 |
Akihiro Motoki |
tags |
rfe |
api rfe |
|
| 2017-03-22 12:12:59 |
OpenStack Infra |
neutron: status |
Triaged |
In Progress |
|
| 2017-03-22 12:12:59 |
OpenStack Infra |
neutron: assignee |
|
Akihiro Motoki (amotoki) |
|
| 2017-03-30 18:29:59 |
Akihiro Motoki |
neutron: status |
In Progress |
Triaged |
|
| 2017-04-06 22:24:15 |
Ihar Hrachyshka |
neutron: status |
Triaged |
In Progress |
|
| 2017-04-06 22:24:22 |
Ihar Hrachyshka |
tags |
api rfe |
api rfe-approved |
|
| 2017-04-06 22:25:15 |
Ihar Hrachyshka |
neutron: milestone |
|
pike-1 |
|
| 2017-05-18 01:20:57 |
Armando Migliaccio |
neutron: milestone |
pike-1 |
pike-2 |
|
| 2022-10-19 11:43:29 |
Rodolfo Alonso |
neutron: status |
In Progress |
Invalid |
|
