Add Principle Identity resource #1021
Conversation
|
/test-all |
| } | ||
|
|
||
| // Clean up underlying cert imported by NSX if exists | ||
| if len(certID) > 0 { |
There was a problem hiding this comment.
sounds like the cert is created automatically by the create API, but not deleted nu delete API?
|
@wsquan171 @annakhm I'm gonna be a little bold here but since I noticed this PR I wanted to ask if you could maybe also expose the "is_protected" boolean in this resource? We do use PIs quite a lot but at the same time set is_protected to false so we can still manipulate objects from the admin GUI if need be. I believe this boolean cannot be updated after the PI user has been created. Our workaround is to recreate the PI user with the new setting, all objects that "belonged" to the old user are still working as intended afawcs. |
Sure. Wasn't aware of this use case and misread |
|
@wsquan171, you must sign every commit in this pull request acknowledging our Developer Certificate of Origin before your changes are merged. This can be done by adding
|
|
/test-all |
| Required: true, | ||
| }, | ||
| "role": { | ||
| Type: schema.TypeList, |
There was a problem hiding this comment.
I wonder if list of sub-clauses here is justified. Does role_display_name convey useful information?
If not, seems more user friendly to just offer a list of string roles? Unless we expect this object to grow in API
Signed-off-by: Shawn Wang <[email protected]>
Signed-off-by: Shawn Wang <[email protected]>
Signed-off-by: Shawn Wang <[email protected]>
Signed-off-by: Shawn Wang <[email protected]>
Signed-off-by: Shawn Wang <[email protected]>
|
@wsquan171, you must sign every commit in this pull request acknowledging our Developer Certificate of Origin before your changes are merged. This can be done by adding
|
Signed-off-by: Shawn Wang <[email protected]>
|
/test-all |
This PR adds support of Principle Identity resource. A principle identity is identified as a pair of PI
nameandcert. If an API is called with SSL client cert matching with a registered PI, the caller is recognized as the PI, granted with its roles and associated privileges.Currently, the only non-deprecated API on NSX are:
createWithPem: PI's cert pem is in-lined as part of PI creation call. The inlined pem has to be unique / new to NSX. NSX then creates a certificate in the background, and populates the MP cert id incertificate_idin response. This cert, however, will not be removed by NSX upon PI deletion.updateCert: If a PI's cert has expired, it can be updated by using this API call to replace the currentcertificate_idwith another cert that is already in the system. The issue is:nsx_policyand will cause trouble to be used for PItags,display_name,description) can also be updated with this API if and only if thecertificate_idis changed and validdeleteAs a result, PI is in general immutable. This is also reflected on NSX UI. In this implementation, I decided to:
ForceNewdisplay_name,descriptionandrevision. As they're either not used or won't be reflected even on UI.createWithPemfor PI creation and leave outupdateCertto avoid res ownership issues and confusion. Cert updates are handled as PI recreationAlso made some changes to role binding resource to reuse some common arguments. Added TLS cert generation for test.
Principle Identity is also removed from role binding resource, as bindings created for PI is immutable from that API as well.