While working with the python SDK for NSX-T, I happened to notice a parameter for objects called ‘Protection’. Here is the definition of the parameter directly from the source code:
Protection status is one of the following: PROTECTED - the client
who retrieved the entity is not allowed to modify it. NOT_PROTECTED
- the client who retrieved the entity is allowed to modify it
REQUIRE_OVERRIDE - the client who retrieved the entity is a super
user and can modify it, but only when providing the request header
X-Allow-Overwrite=true. UNKNOWN - the _protection field could not
be determined for this entity.
This attribute may be present in responses from the server, but if
it is present in a request to server it will be ignored.
Notice the above states that this attribute is ignored if it is set in a client request. Setting this attribute will prevent users (with the exception of enterprise admins) from deleting or editing objects in the NSX Manager. Having this functionality could be useful, so let’s dive a bit deeper on how to use it!
Normal REST calls
To prove that the call does not work with a regular rest call, let’s try it. Below is an object we want to create in the NSX Manager:
{
"display_name" : "TestGroup",
"_protection" : "REQUIRE_OVERRIDE"
}
We will attempt to set the _protection attribute by setting the variable in the data and sending the call to the NSX Manager via CURL.
curl -k -u admin -d @testgroup.json -X POST https://XX.XX.XX.XX/api/v1/ns-groups/ --header "Content-Type: application/json"
{
"resource_type" : "NSGroup",
"id" : "8d8fe782-7767-4b39-a26e-5af09e48a281",
"display_name" : "TestGroup",
"members" : [ ],
"member_count" : 0,
"_create_time" : 1537278850472,
"_last_modified_user" : "admin",
"_last_modified_time" : 1537278850475,
"_system_owned" : false,
"_create_user" : "admin",
"_protection" : "NOT_PROTECTED",
"_revision" : 1
}
Notice how the object in the GUI does not have a lock next to it. That is because, as stated above, a client request cannot set the protection attribute. The setting can only be done by the NSX Manager. What we need to perform this change, is a trusted ID in the NSX Manager that is allowed to set the attribute upon creation. We need a principal ID defined in the system
Create a Principal ID
Principal IDs must be created based off of a trusted certificate that is uploaded to the NSX Manager. The NSX Manager does not validate the certificate chain, so a basic self-signed certificate will do just fine here. In this example, I will be creating a cert using openssl. The NSX Manager can be very picky so use the example below as a baseline template for creating your certificate:
openssl req -newkey rsa:2048 -extensions usr_cert -nodes -keyout test.key -x509 -days 365 -out test.crt -subj "/C=US/ST=Michigan/L=Detroit/O=NSX/CN=test" -sha256
The command above generates a certificate (test.crt) and a private key (test.key). We can now upload these to the NSX Manager:
Go to System->Trust and click ‘Import’
Upload the cert and key into the NSX Manager:
You should now see the cert in the NSX Manager:
Now that the cert is uploaded, we can grab its ID so we can create a principal ID off it. The cert will be used to validate the REST calls being sent from that machine.
The example below is the payload needed to create a principal ID using the cert ID of “d5f0549d-004f-45f7-b544-97251972c46c”.
{
"name" : "testuser",
"node_id" : "testuser",
"is_protected" : "true",
"certificate_id" : "d5f0549d-004f-45f7-b544-97251972c46c",
"permission_group" : "read_write_api_users"
}
The Node_ID can be used to differentiate multiple nodes in a cluster that could make changes to the NSX Manager. This is primarily used in a VIO (VMware Integrated Openstack) environment. In this case, we make it the same as the ‘name’ attribute. Also, the ‘is_protected’ attribute MUST be set to “true”. With this, any object created by this principal ID will be protected from other admin users.
We use the admin account to create the principal ID:
curl -k -u admin -d @principalid.json -X POST https://XX.XX.XX.XX/api/v1/trust-management/principal-identities/ --header "Content-Type: application/json"
{
"resource_type" : "PrincipalIdentity",
"id" : "eabc82a4-c5e7-4e14-84fb-21de38a898d1",
"display_name" : "testuser@testuser",
"tags" : [ ],
"certificate_id" : "d5f0549d-004f-45f7-b544-97251972c46c",
"role" : "enterprise_admin",
"name" : "testuser",
"permission_group" : "undefined",
"is_protected" : true,
"node_id" : "testuser",
"_create_time" : 1537280635914,
"_last_modified_user" : "admin",
"_last_modified_time" : 1537280635914,
"_system_owned" : false,
"_create_user" : "admin",
"_protection" : "NOT_PROTECTED",
"_revision" : 0
}
If it worked, we should have something like the output above. The NSX Manager will now show the new testuser principal ID:
Now we can test!!
Testing REST Calls
I deleted the old “testgroup” and will recreate it with the principal ID now:
{
"display_name" : "TestGroup"
}
curl -k --cert ./certs/test/test.crt --key ./certs/test/test.key -d @testgroup.json -X POST https://XX.XX.XX.XX/api/v1/ns-groups/ --header "Content-Type: application/json"
{
"resource_type" : "NSGroup",
"id" : "0ec60ce2-deea-4e74-9a0c-d867e88c16e7",
"display_name" : "TestGroup",
"members" : [ ],
"member_count" : 0,
"_create_time" : 1537281161137,
"_last_modified_user" : "testuser",
"_last_modified_time" : 1537281161140,
"_system_owned" : false,
"_create_user" : "testuser",
"_protection" : "NOT_PROTECTED",
"_revision" : 1
}
Now you are probably looking at the output above and saying “wait a minute! The _protection attribute still says “NOT_PROTECTED”!
Correct, because from the perspective of the testuser, it CAN edit that value. If we are to look at it in the NSX Manager, we will see that it has a lock symbol by it and shouldn’t be editable.
As you can see, the edit button is grayed out in the GUI and there is a lock symbol by the object. We successfully created a protected object in the NSX Manager! Let’s look at the object from the perspective of another user:
curl -k -u admin -X GET https://XX.XX.XX.XX/api/v1/ns-groups/
{
“resource_type” : “NSGroup”,
“id” : “0ec60ce2-deea-4e74-9a0c-d867e88c16e7”,
“display_name” : “TestGroup”,
“members” : [ ],
“member_count” : 0,
“_create_time” : 1537281161137,
“_last_modified_user” : “testuser”,
“_last_modified_time” : 1537281161140,
“_system_owned” : false,
“_create_user” : “testuser”,
“_protection” : “REQUIRE_OVERRIDE”,
“_revision” : 1
}
The admin account, from its perspective, can see it is a protected object and would require a special override to delete or edit it. If the user were not an enterprise admin, then the _protection attribute would say “PROTECTED”.
To override it and delete the object, we have to set a special header variable called X-Allow-Overwrite to ‘true’:
curl -k -u admin -X DELETE https://XX.XX.XX.XX/api/v1/ns-groups/0ec60ce2-deea-4e74-9a0c-d867e88c16e7 --header "X-Allow-Overwrite: true"
Now if we look in the NSX Manager, it should be gone:
All set! Hope this was helpful.
AJ