16 KiB
Security Service Updates for In Use Share Networks
https://blueprints.launchpad.net/manila/+spec/improve-security-service-update
https://blueprints.launchpad.net/manila/+spec/add-security-service-in-use-share-networks
Manila security service is an entity that stores client configuration used for authentication and authorization. It abstracts a set of configuration data that can be used by back ends that support it, to configure a server that can join specific authentication domains.
Manila supports different types of security services such as LDAP, Kerberos and Microsoft Active Directory [1]. Users can create, update, view and delete security services, however, in order to apply its configuration, manila needs to maintain an association between security services and share networks. Although, there is no way of providing such association or update any of its parameters after a share network starts being used by a share server.
This spec proposes an improvement on both security service update and share network association with security services, that will allow users update their share networks to replace or to add new security services, which can reflect on modifications in all related share servers.
Problem Description
Security service has configurations that might change while it's
still associated to share servers, leaving the latter outdated and
possibly with problems to authenticate within domains. Furthermore,
users won't be able to grant access to shares that live on these share
servers, and Manila doesn't provide an easy way of updating such
configurations, since the current implementation only supports update of
name
and description
attributes [2] since they
do not affect share server's configuration.
Likewise, share network association with security services can't be changed after a share server has been provisioned, and new authentication server configurations can't be added to the already deployed share servers. In this scenario, users can only create new share networks that will be used to create new share servers.
Use Cases
Security service attributes such as dns
and
password
might change due to network changes or password
update policies and hence affect one or more share servers. Users must
be able to modify these attributes in all affected security services
which must reflect such configuration change in all associated share
servers. A security service is qualified to be updated only if all its
associated share servers have support of such operation, otherwise it
must be denied.
Moreover, new security services might need to be associated with in use share networks, in order to bring more flexibility to users that want to create new shares using different authentication methods. Users must be able to include new security service associations to their share networks, which must reflect on security service updates in all associated share servers. A new security service association is qualified to be configured only if all affected share servers support such capability.
This specification focuses on both scenarios where share networks are being used by share servers and an update or a new association of security service is requested by the user, which will end up with one or more share servers being updated in the back end storages.
Proposed Solution
To solve these use cases, the share network entity will need be
improved to support updates and association of new security services,
even when it is already in use. A new status
field will be
added to represent the current state of a share network. While under
modification, the share network will stay in a maintenance mode, meaning
that back end configurations are being changed. The update will finish
when all affected resources finish their respective configurations.
Users will be able to check the current status of a share network and
will be blocked of requesting new operations that can be affected by the
current modification in progress.
To have these new operations working, the following changes are being proposed:
- Share network will have a new
status
attribute; - Share network API will be updated to allow association and update of
security services for in use share networks. The API will also be
improved to accept share network
reset-status
operation. - Update share server model to include a new capability, for supporting security service updates.
- Add a new share server state, indicating that it's under network modification.
- New share network states will be added to cover all scenarios.
- Add a new driver interface for share server update;
- Add a new back end capability to identify drivers that support such functionality;
- A new share network property will be added to indicate if it supports security service updates based on its share servers' capabilities.
API Changes
When receiving a request for security service update or association,
the API will check if there are share servers associated with the share
network. If the list of share servers is not empty, the API will need to
check the new share network's property,
security_service_update_support
, to see if the request can
be completed or not and fail earlier if doesn't support it.
A new API will be create to handle security service update, which will allow the replacement of an already configured security service by another one, that should be of the same type.
The new share network's status will need to be validated in many other resources' operations, which end up on backend changes. These operations should wait until the associated share network become available again, in order to proceed with the new modifications.
Share API and Manager Changes
Share network updates can be an one-to-many operation, which might trigger multiple share server updates, for different back ends in different share services. To update a security service information associated with a share network, the share API will need to validate if all affected resources are healthy before proceeding with the request.
After that, both share network and share servers status will be
updated to network_change
, the share network and security
service association in the database will be updated and the respective
share services will be called to initiate back end updates.
The share manager will be responsible for updating share servers' backend details, and for calling the driver's interface with the corresponding network update. At the end of the share server update operation, the share server's status will be updated accordingly, while the share network will be updated only if all share servers under modification already finished their configuration.
If the update ends up on a failure, the share server status will be
set to error
along with all affected shares access rules.
The share server's backend details will remain with the most recent
security service information, but will be up to the administrator to
check in the storage system if the configuration is correct, before
reset the status back to active
, using the
share-server-reset-state
API. The network status won't be
affected by errors raised by back end drivers, and will have its status
updated to active
again at the end of the security service
update.
Scheduler Capability
Backends that support this functionality will be able to report the security_service_update_support capability as True to the scheduler, which can further be used to select backend pools that support it.
Manila Manage
By adding a new capability to the share server model, it's important
to consider that existing share servers will need to update this field
in the future, based on driver's support, to have this functionality
enabled. This will be achieved by providing a new management command for
manila-manage
tool that will let administrators update
their share servers accordingly.
Alternatives
Alternatively, the security service resource could handle the update operation and trigger back end modification for all share servers associated with the affected share networks. This alternative can lead to scenarios with lots of back end modification at once, and as possible result, many failed share servers if the new parameters or associations are invalid.
Impacts
Data model impact
A new security_service_update_support
capability field
will be added to manila.db.sqlalchemy.models.ShareServer
indicating if the driver and the back end where this share server
resides support the new security service update operations. In database
migration upgrade, the new column will be added with a default value set
to False
, meaning that all share servers already deployed
won't be able to update their security service configuration even if the
driver supports it. In database migration downgrade the column will be
dropped.
A new status
field will be added to the
manila.db.sqlalchemy.models.ShareNetwork
to hold new states
that will assist on different share network operations. At this moment,
only three status could be assigned to share networks:
active
, error
and network_change
.
The share network is considered healthy and is available to be used only
if its status is active
. The status
network_change
represents a share network that is under
modification and can't be changed or used until it becomes
active
again. For specific failure scenarios, that can't be
recovered without administrator intervention, the share network will
receive an error
status.
A new security_service_update_support
property will be
added to manila.db.sqlalchemy.models.ShareNetwork
to
indicate whether a share network supports or not the new security
service update operations. This property will inherited its value from
all current associated share servers. If all associated share servers
support security_service_update_support
, the share network
property will be set to True
, otherwise it will be set to
False
.
REST API impact
- Both share server and share network view will include a new response
parameter, the
security_service_update_support
that will indicate if the share server (or share network) is capable of updating security service configuration. - Share network view will include a new
status
parameter that will indicate its current status. - All share network dependant operations will be blocked in the API
for share networks with status different from
active
, to avoid conflicting backend configurations. - Semantic changes are expected in the share network API. Associating
new security services for in use share networks will require that all
share servers affected by the change support such operation, or the API
will will respond with
403 Forbidden
. If the destination share service is unavailable, the API will respond with409 Conflict
. - New share network APIs will be added:
share-network-security-service-update
Updates an existing security service association:
POST /v2/{project_id}/share-networks/{share_network_id}/action
Body:
{ "update_security_service": { "current_service_id": "bab0debd-fa50-4ade-80c5-ce85e2fc2614", "new_service_id": "1ec35b2b-5d0c-4c46-a6ca-71f9eab49ce2" } }
Response:
Code: 200 OK { "name": "my_network", "id": "620a1050-1711-4961-908a-bd6f7c0b1d00", "project_id": "f227b9e2cbdc40e78ed761e5e22c5fb4", "description": "This is my share network", "created_at": "2020-11-27T11:26:10.000000" "updated_at": null, "status": "network_change", "security_service_update_support": true, "share_network_subnets": [ { "created_at": "2020-11-27T11:26:10.000000", "id": "aa7a1269-703b-4832-a3df-17ed954c276c", "availability_zone": null, "segmentation_id": null, "neutron_subnet_id": "12c1490a-e82c-4f5e-bcb1-fb267a58cf10", "updated_at": null, "neutron_net_id": "998b42ee-2cee-4d36-8b95-67b5ca1f2109", "ip_version": null, "cidr": null, "network_type": null, "gateway": null, "mtu": null } ] }
If the provided new_service_id doesn't have the same type as the current one, or one of the security services' ID don't exist, the API will respond with 400 Bad Request. If the provided share-network-id doesn't exist, the API will respond with
404 Not Found
. If at least one of the destinations share services is unavailable, the API will respond with409 Conflict
.share-network-reset-status
:Reset the status of a share network:
POST /v2/{project_id}/share-networks/{share_network_id}/action
Body:
{ "reset_status": { "status": "active" } }
If the provided share-network-id doesn't exist, the API will respond with
404 Not Found
. If the user doesn't have permission to execute this operation, the API will respond403 Forbidden
.
Security impact
None.
Notifications impact
None.
Other end user impact
None.
Performance impact
None.
Other deployer impact
- No new configurations are expected to be added.
- The back end capability will help deployers to identify pools that support new security service association.
- All existing share servers will have their
security_service_update_support
set toFalse
, even if the driver supports it. New share servers will have the correspondent capability set according to the back end capability reported by the drivers. Administrators will need to manually update share server's capability usingmanila manage
commands.
Developer impact
None
Driver impact
There is no impact for drivers that don't want to support the proposed feature.
A new driver interface will be included to support share server
security service update. Both share server and network info will be
provided during this call. Drivers that want to support this operation
will need to implement this call and report the capability
security_service_update_support
as True
.
Implementation
Assignee(s)
- Primary assignee:
-
dviroel
Work Items
- Implement core changes that must include:
- Add share network and share server model attributes;
- Change API behavior when associating new security services with a share network;
- Create new share network APIs to update security service and reset share network status;
- New Share API interface for updating security service information;
- New driver interface will be included to update share server network configuration;
- New back end capability for supporting security service association will be added to share driver.
- Implementation in a first party driver
- Add new functional test in manila-tempest-plugin
- Add new command to manila-manage for share server capability update
- Update manila documentation
Dependencies
None.
Testing
Unit test coverage will be added/maintained as per community standards. New tempest tests will be added to cover new security service association scenarios. The container or the dummy driver will be improved to properly configure security services and be used to validate the proposed changes.
Documentation Impact
The following OpenStack documentation will be updated to reflect this change:
- Admin Guide: document the premises for having new security service association applied to share servers;
- API Reference: include share server new status and new capability field;
- Developer Reference: add information about how to implement and add support for this new functionality.
References
[1]: https://docs.openstack.org/manila/latest/admin/shared-file-systems-security-services.html
[2]: https://docs.openstack.org/api-ref/shared-file-system/#update-security-service