dropdown menu



A project (sometimes called as a tenant) is a unit of ownership. The "ibm-default" project is created during installation, but PowerVC supports additional projects for resource segregation. By creating several projects we can separate virtual machines, volumes, and images from others. (For example a specific virt. machine can be seen only in one project, and it is not possible to see that in another project.) Other components of PowerVC, such as storage connectivity groups and compute templates do not belong to a specific project (these are generally available in each project). Only users with a role assignment can work with the resources of a specific project. 

After creating a project, you are automatically assigned the admin role for that project. This allows you to assign additional roles to users in that project.

Role assignments are specific to a project. For example, a user could have the vm_manager and storage_manager roles in one project and only the viewer role in another project. Users can only log in to one project at a time. If they have a role on multiple projects, they can switch to other projects. When users log in to a project they will only see resources, messages etc. that belong to that project. They will not see resources that belong to other projects.

OpenStack does not support moving resources from one project to another. You can move volumes and virtual machines by unmanaging them and then remanaging them in the new project. All resources within a project must be deleted or unmanaged before the project can be deleted. The ibm-default project cannot be deleted.

openstack project create   create and manage projects
openstack role add ...     assign roles to users in a project



By default, PowerVC uses the local operating system to manage users and groups. To avoid exposing all of the system's users and groups, filtering is implemented. Only users and groups which match the corresponding filter will be exposed in PowerVC.

On a new installation, a new group named "powervc-filter" is created, the default user (root) is added to that group, and the filters are configured so that only the powervc-filter group and its members are visible to PowerVC. When a user is visible in PowerVC, this user is visible independently of a project. But when a role is assigned to a user it is important in which project this happens. Switch projects when you want to assign a role in antother project. If a role is assigned in 2 projects then the user can switch between projects.

PowerVC backups include the user and group filters. However, they do not create users or groups, or adjust group memberships. If operating system users and groups are configured differently when the backup is restored, this might lead to issues. For example, if the system on which the restore is being performed does not have the same users in the powervc-filter group, different users will be seen in PowerVC. Some role assignments might no longer work because the user or group to which they were granted does not exist or is not visible based on the user and group filters.

Checking the current filters (for groups and users) and authentication type (os or ldap)
[root@powervc ~]# powervc-config identity repository
Type: os
User filter: (memberOf=powervc-filter)
Group filter: (name=powervc-filter)

With these default filters, only the OS users that are members of the group ‘powervc-filter’ are visible to PowerVC. Similarly, the only group that is visible in PowerVC is the one named ‘powervc-filter’
(In earlier versions of powervc this filtering mechanism was missing for OS user it worked only for LDAP)

Create a filter so that PowerVC can see all of the users that are members of the groups power1, power2, and can also see any groups that are named power1, power2:
# powervc-config identity repository -t os --user-filter "(|(memberOf=power1)(memberOf=power2))" --group-filter "(|(name=power1)(name=power2))"



Roles are used to specify what actions a user can perform. Roles are assigned to a user (or group, in which case they are inherited by all users in that group). A user or group can have more than one role, in which case they are able to perform any action that at least one of their roles allows.

admin: It can do all tasks and access all resources. Only adminis on the ibm-default project can list, create, and delete projects.
deployer: Deploying a virtual machine from an image, Viewing all resources except users and groups
image_manager: Capturing, importing, or deleting an image, Editing description of an image, Viewing all resources except users and groups
storage_manager: Creating, deleting, or resizing a volume, Viewing all resources except users and groups
viewer: can view resources and the properties of resources, but can perform no tasks. They cannot view users and groups.
vm_user: Starting, stopping, or restarting a virtual machine, Viewing all resources except users and groups
vm_manager: Deploying a virtual machine from an image, Deleting, resizing, starting, stopping, or restarting a virtual machine, Attaching or detaching volume/network interface, Editing details of a deployed virtual machine, Viewing all resources except users and groups, Creating, attaching, detaching, and deleting floating IP addresses

Some tips:
If a user needs to write automation to deploy virtual machines, but does not need to perform any other tasks, assign that user deployer.
If a user needs to deploy and manage their own virtual machines , but does not need to work with images, storage, or infrastructure tasks, such as registering hosts, assign that user vm_manager.
If a user needs to deploy and manage VMs but also needs to capture and manage images, assign the user both vm_manager and image_manager.
If a user needs to work with storage volumes and nothing else, assign that user storage_manager.
If a user needs to manage virtual machines that others have created, assign that user vm_manager.


Self-service user roles- policies:

Self-service users are limited to only using deploy templates for images that are assigned to their project.

For example, we can specify how many virtual machines a self-service user can create before needing administrator approval.  After reaching that point, if a user tries to create a virtual machine a request is generated (an email sent to the administrator by PowerVC).  If an administrator approves the request, the virtual machine is then created.
A self-service user will create virtual machines by using deploy templates. These have been set up by the administrator.  Deploy templates are tied to one project, but multiple deploy templates that use different settings can be created from the same image.

The self-service role is exclusive to a project.  That is, if you have the self-service role in a project, you cannot have other roles in that project. However, you can have the same or different roles in other projects. 

The following policies can be set for a self-service user:
- Default expiration date for all VMs created by self-service users in this project.
- How many VM expiration extension requests are automatically approved.  After reaching the limit administrator approval is needed.
- How long a VM expiration extension request waits before being auto-approved.  
- How long to keep an expired VM before it is deleted.
- How many deploys a self-service user can perform without requiring administrator approval.
- How many times a self-service user can capture an image (or take a snapshot) without requiring administrator approval.


Adding users and role

Creating a user in PowerVC and adding a role to that user:
1. # useradd powervc                                   <--create user on linux
2. # passwd powervc                                    <--add a password for that user                                      
3. # usermod -a -G powervc-filter powervc              <--add user to the group (easiest way to make a user visible to PowerVC)
                                                       (after this user can be seen in powervc GUI and also in openstack commands)
4. # openstack role add --project ibm-default --user powervc admin   <--adding admin role to the user 
                                                                     (this can be done in the GUI, which is more preferrable)

if needed:
chfn powervc -f "Admin user for deploy project"         <--changing GECOs for a user
gpasswd -d powervc powervc-filter                       <--remove user from a group (or edit /etc/group))



It is possible to use PowerVC with LDAP configuration. (It is a bit complex, for me did not work, and the help of an LDAP admin is necessary as such LDAP details are needed which can be seen by LDAP admin only).

Some helpful tips:

1. IBM LDAP config document, which is not really available yet  anywhere else:

2. IBM Knowledge Center regarding configuring LDAP:

3. I received this as a working config:
Here is an example of PowerVC LDAP config using our AD Environment this is a windows server 2012 R2 Domain:
user_objectclass = person
user_id_attribute = sAMAccountName
user_name_attribute = sAMAccountName
user_mail_attribute = mail
user_description_attribute = description
group_tree_dn = CN=Users,DC=TestDomain,DC=ibm,DC=com
group_objectclass = group
group_id_attribute = sAMAccountName
group_name_attribute = cn
group_member_attribute = member
group_desc_attribute = description
query_scope = one
use_tls = False
chase_referrals = True

4. My (not working config), with some comments from IBM:
# powervc-config identity repository -t ldap -u "John Doe" --ldap-url ldap://ldap.mycompany.org --insecure   
(IBM recommendded to use one more argument name --chase-referral False for AD)

Configuring PowerVC for LDAP.
Anonymous bind [n]:
User name [dc=Manager,dc=example,dc=com]: CN=ldap_user,OU=Functional,OU=Accounts,DC=mycompany,DC=org
Password: ******
User tree DN [ou=Users,dc=example,dc=com]: OU=EU,OU=Primary,OU=Accounts,DC=mycompany,DC=org  <--looks correct, aligns with ldapsearch dn
User filter [None]: (|(uid=John Doe))      <--please remove this and try; this looks incorrect
User object class [inetOrgPerson]:         <--check if the objectclass corresponding to their user is inetOrgPerson or not. 
                                           It completely depends on how LDAP user has been configured.
User ID attribute [uid]:                   <--check if the unique identifier for LDAP user is the uid attribute or something else. 
                                           It completely depends on how LDAP user has been configured.
User name attribute [cn]:                  <--This should be the LDAP attribute that is associated with the user name. 
                                           From the ldapsearch results, it looks like this is correct.
User mail attribute [email]:
User description attribute [description]:
Group tree DN [ou=Groups,dc=example,dc=com]:   <--This is the group tree under which the users are present.
                                               No value enterd here, so the default value is taken, which is clearly incorrect.
Group filter [None]:
Group object class [groupOfNames]:         <--they have to check and input the objectclass used to define their LDAP group
Group ID attribute [cn]:                   <--same comment as previous (check the LDAP attribute that uniquely identifies their group)
Group name attribute [cn]:                 <--check if the cn attribute is set against their LDAP group to represent the name
Group member attribute [member]:           <--Ensure if this value defines the members of a group
Group description attribute [description]:        
Query scope [one]:                         <--if their users/groups are under multiple hierarchies, recommend changing this to sub
Error: User 'John Doe' was not found
Error: There must be at least one admin user. Check user and group inputs.

No comments:

Post a Comment