Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Preflight validation of vsphere creds for required perms #2744

Closed
vivek-koppuru opened this issue Jul 18, 2022 · 9 comments
Closed

Preflight validation of vsphere creds for required perms #2744

vivek-koppuru opened this issue Jul 18, 2022 · 9 comments
Assignees

Comments

@vivek-koppuru
Copy link
Member

vivek-koppuru commented Jul 18, 2022

Currently users need to add the following permissions to their users/roles when creating an EKS-A cluster.
https://anywhere.eks.amazonaws.com/docs/reference/vsphere/vsphere-preparation/

However, we currently don't have robust validations on whether the user they provide has the appropriate permissions that we are asking for in the documentation. govc has a few commands that would help be able to do this programmatically. Here is the usage instructions for govc: https://github.com/vmware/govmomi/blob/master/govc/USAGE.md

The list of permissions we ask above can be turned into a list that we can check for by running the govc role.ls command, which would list out all the applicable permissions defined for the role. It is described differently through the cli as follows:

If described as the following in the documentation:

> Content Library
* Add library item

It translates to the following in the permissions list for the cli (running the command for an Admin user should list all the possible values, and we might have to map them accordingly to the documentation):

ContentLibrary.AddLibraryItem

There are also the permissions.ls command and the sso.user.ls command that might list out what roles are associated with the user, however, the documentation on the usage is sparse, so we need to see if permissions.ls command supports -principal flag and if the sso.user.ls supports listing permissions based on passing in the name of the user.

@vivek-koppuru
Copy link
Member Author

This example may help understand how users, groups and roles might all be associated with each other, but am not sure if it applies to our usecase.

@jonathanmeier5 jonathanmeier5 self-assigned this Jul 25, 2022
@jonathanmeier5
Copy link
Member

jonathanmeier5 commented Jul 26, 2022

Based on my research so far we can implement this ticket but the check will require admin credentials.

We can view the roles associated with an object using:

govc permissions.ls  /Datacenter/datastore/datastore2

You can ignore inherited roles using the -a flag:

govc permissions.ls -a=false  /Datacenter/datastore/datastore2

This gives the information we need about a particular object's associated roles.

We can check that roles privileges with role.ls:

govc role.ls EKS\ Anywhere\ User

However, the only way I have found to establish which roles a user is associated to is with sso.user.id as described in this issue:

govc sso.user.id jwmeier

But this command requires a user have the Administrator role.

I'm trying to determine if lower levels of access may be able to run this command but haven't found any yet.

@jonathanmeier5
Copy link
Member

I timeboxed some additional exploration to determine if it is possible to list a user's groups without the Administrator role and have not come up with anything.

I'm waiting on a response to a discussion item I filed, but I don't expect much to come of it.

As a side note, govc appears to provide the functionality we would need to automatically generate the user with appropriate roles and permissions.

@jonathanmeier5
Copy link
Member

jonathanmeier5 commented Aug 1, 2022

After looking further into govmomi and the vSphere API based on @vivek-koppuru's recommendation I was able to find an API method that provides a list of privileges for a particular user on a list of entities without requiring an admin role:

https://vdc-repo.vmware.com/vmwb-repository/dcr-public/fe08899f-1eec-4d8d-b3bc-a6664c168c2c/7fdf97a1-4c0d-4be0-9d43-2ceebbc174d9/doc/vim.AuthorizationManager.html#fetchUserPrivilegeOnEntities

I found a corresponding client method in govmomi here.

As discussed in standup I'm adding govmomi as an explicit project dependency so we can use this functionality.

cc @vivek-koppuru @g-gaston

@g-gaston
Copy link
Member

g-gaston commented Aug 1, 2022

After looking further into govmomi and the vSphere API based on @vivek-koppuru's recommendation I was able to find an API method that provides a list of privileges for a particular user on a list of entities without requiring an admin role:

https://vdc-repo.vmware.com/vmwb-repository/dcr-public/fe08899f-1eec-4d8d-b3bc-a6664c168c2c/7fdf97a1-4c0d-4be0-9d43-2ceebbc174d9/doc/vim.AuthorizationManager.html#fetchUserPrivilegeOnEntities

I found a corresponding client method in govmomi here.

As discussed in standup I'm adding govmomi as an explicit project dependency so we can use this functionality.

cc @vivek-koppuru @g-gaston

Sounds good!
Can we create a ticket to revisit the question govmomi vs govc? Ideally I would like to depend only on one of them.

@vivek-koppuru
Copy link
Member Author

I think it would be a fine option to depend on govmomi only for this and then put an upstream PR to add it to govc, and then for us to change it back. But yea that can be part of the revisiting @g-gaston is suggesting above.

@jonathanmeier5
Copy link
Member

jonathanmeier5 commented Aug 3, 2022

Sure thing 👍

Here's a ticket: #2853.

If there are any labels, etc I should apply please let me know.

@g-gaston
Copy link
Member

g-gaston commented Aug 3, 2022

@jonathanmeier5 you can just follow https://github.com/aws/eks-anywhere/blob/main/docs/developer/issues.md

let me know if you have any questions :)

@jonathanmeier5
Copy link
Member

Completed in #2907.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants