From 2b2d19b9bda708e21998f4d4ce22d1b4bfb71093 Mon Sep 17 00:00:00 2001 From: Julia Kreger Date: Fri, 26 Sep 2025 11:10:46 -0700 Subject: [PATCH] docs: remove severely outdated mutlitenancy docs And custom examples. :( Change-Id: Id14e41044787df82b3f6becb0cf240739a1a348b Signed-off-by: Julia Kreger --- doc/source/admin/node-multitenancy.rst | 129 ++----------------------- 1 file changed, 6 insertions(+), 123 deletions(-) diff --git a/doc/source/admin/node-multitenancy.rst b/doc/source/admin/node-multitenancy.rst index 4b46404f9c..5286a7bc13 100644 --- a/doc/source/admin/node-multitenancy.rst +++ b/doc/source/admin/node-multitenancy.rst @@ -19,127 +19,10 @@ or ``lessee`` attribute:: baremetal node set --owner 080925ee2f464a2c9dce91ee6ea354e2 node-7 baremetal node set --lessee 2a210e5ff114c8f2b6e994218f51a904 node-10 +Ironic's API automatically grants visibility and access to these nodes +when a user request comes in with a "project" scope, i.e. credentials +which indicate the user is in a user within a project. -Configuring the Bare Metal Service Policy -========================================= - -By default, the Bare Metal service policy is configured so that a node -owner or lessee has no access to any node APIs. However, the policy -:doc:`policy file ` contains rules that -can be used to enable node API access:: - - # Owner of node - #"is_node_owner": "project_id:%(node.owner)s" - - # Lessee of node - #"is_node_lessee": "project_id:%(node.lessee)s" - -An administrator can then modify the policy file to expose individual node -APIs as follows:: - - # Change Node provision status - # PUT /nodes/{node_ident}/states/provision - #"baremetal:node:set_provision_state": "rule:is_admin" - "baremetal:node:set_provision_state": "rule:is_admin or rule:is_node_owner or rule:is_node_lessee" - - # Update Node records - # PATCH /nodes/{node_ident} - #"baremetal:node:update": "rule:is_admin or rule:is_node_owner" - -In addition, it is safe to expose the ``baremetal:node:list`` rule, as the -node list function now filters non-admins by owner and lessee:: - - # Retrieve multiple Node records, filtered by owner - # GET /nodes - # GET /nodes/detail - #"baremetal:node:list": "rule:baremetal:node:get" - "baremetal:node:list": "" - -Note that ``baremetal:node:list_all`` permits users to see all nodes -regardless of owner/lessee, so it should remain restricted to admins. - -Ports ------ - -Port APIs can be similarly exposed to node owners and lessees:: - - # Retrieve Port records - # GET /ports/{port_id} - # GET /nodes/{node_ident}/ports - # GET /nodes/{node_ident}/ports/detail - # GET /portgroups/{portgroup_ident}/ports - # GET /portgroups/{portgroup_ident}/ports/detail - #"baremetal:port:get": "rule:is_admin or rule:is_observer" - "baremetal:port:get": "rule:is_admin or rule:is_observer or rule:is_node_owner or rule:is_node_lessee" - - # Retrieve multiple Port records, filtered by owner - # GET /ports - # GET /ports/detail - #"baremetal:port:list": "rule:baremetal:port:get" - "baremetal:port:list": "" - - -Allocations ------------ - -Allocations respect node tenancy as well. A restricted allocation creates -an allocation tied to a project, and that can only match nodes where that -project is the owner or lessee. Here is a sample set of allocation policy -rules that allow non-admins to use allocations effectively:: - - # Retrieve Allocation records - # GET /allocations/{allocation_id} - # GET /nodes/{node_ident}/allocation - #"baremetal:allocation:get": "rule:is_admin or rule:is_observer" - "baremetal:allocation:get": "rule:is_admin or rule:is_observer or rule:is_allocation_owner" - - # Retrieve multiple Allocation records, filtered by owner - # GET /allocations - #"baremetal:allocation:list": "rule:baremetal:allocation:get" - "baremetal:allocation:list": "" - - # Retrieve multiple Allocation records - # GET /allocations - #"baremetal:allocation:list_all": "rule:baremetal:allocation:get" - - # Create Allocation records - # POST /allocations - #"baremetal:allocation:create": "rule:is_admin" - - # Create Allocation records that are restricted to an owner - # POST /allocations - #"baremetal:allocation:create_restricted": "rule:baremetal:allocation:create" - "baremetal:allocation:create_restricted": "" - - # Delete Allocation records - # DELETE /allocations/{allocation_id} - # DELETE /nodes/{node_ident}/allocation - #"baremetal:allocation:delete": "rule:is_admin" - "baremetal:allocation:delete": "rule:is_admin or rule:is_allocation_owner" - - # Change name and extra fields of an allocation - # PATCH /allocations/{allocation_id} - #"baremetal:allocation:update": "rule:is_admin" - "baremetal:allocation:update": "rule:is_admin or rule:is_allocation_owner" - -Deployment and Metalsmith -------------------------- - -Provisioning a node requires a specific set of APIs to be made available. -The following policy specifications are enough to allow a node owner to -use :metalsmith-doc:`Metalsmith ` to deploy upon a node:: - - "baremetal:node:get": "rule:is_admin or rule:is_observer or rule:is_node_owner" - "baremetal:node:list": "" - "baremetal:node:update_extra": "rule:is_admin or rule:is_node_owner" - "baremetal:node:update_instance_info": "rule:is_admin or rule:is_node_owner" - "baremetal:node:validate": "rule:is_admin or rule:is_node_owner" - "baremetal:node:set_provision_state": "rule:is_admin or rule:is_node_owner" - "baremetal:node:vif:list": "rule:is_admin or rule:is_node_owner" - "baremetal:node:vif:attach": "rule:is_admin or rule:is_node_owner" - "baremetal:node:vif:detach": "rule:is_admin or rule:is_node_owner" - "baremetal:allocation:get": "rule:is_admin or rule:is_observer or rule:is_allocation_owner" - "baremetal:allocation:list": "" - "baremetal:allocation:create_restricted": "" - "baremetal:allocation:delete": "rule:is_admin or rule:is_allocation_owner" - "baremetal:allocation:update": "rule:is_admin or rule:is_allocation_owner" +In older versions of Ironic, this functionality had to be manually configured +and then set via custom policies, but now it is automatically available +in modern versions of Ironic.