8. User Management¶
This section provides an overview of user management on a Robin Platform cluster and the underlying Kubernetes cluster.
Topics covered in this chapter:
|
Add a new user to the Robin Platform cluster |
|
Update a user’s attributes |
|
Remove a user from the Robin Platform cluster |
|
List Robin Platform cluster users |
|
Log into the Robin Platform cluster |
|
Change the password for the current Robin Platform user |
|
Change the tenant for the current user |
|
Change the role a user has for specified tenant |
|
List details about user capabilities that can be assigned to users |
|
Add a custom user capability |
|
Remove a custom user capability |
|
Update one or more attributes for a custom user capability |
|
Add one or more capability entries to a custom user capability |
|
Remove one or more capability entries from a custom user capability |
|
Add one or more capability providers to a custom user capability |
|
Remove one or more capability providers from a custom user capability |
|
List operations that can be shared with users for various sharable objects |
|
Add an LDAP server |
|
Remove an LDAP server |
|
List named LDAP server or all LDAP servers |
|
List one or more LDAP groups |
|
List one or more LDAP users |
|
Import one or more LDAP users |
|
Import members of a LDAP group |
|
List LDAP attributes |
|
Update an LDAP attribute |
|
Reset an LDAP attribute to its default value |
|
List one or more OpenShift users or all OpenShift users |
|
List one or more OpenShift groups or all OpenShift groups |
|
Import one or more OpenShift users |
|
Import all users from an OpenShift groups |
8.1. Kubernetes user management¶
Note
Details on Kubernetes user management are provided for information purposes only. The Robin Platform handles all interaction between Robin Server and the Kubernetes API Server on behalf of all Robin Platform users.
Kubernetes clusters support two categories of users: service accounts, and normal users (users). Service accounts are managed by the Kubernetes cluster. But Kubernetes doesn’t have a mechanism for managing users. In fact, it doesn’t even contain an object that represents a user, and there is no way for a user to log into a Kubernetes cluster. In a Kubernetes cluster, user management is off-loaded to an external facility or auth provider.
Namespaces
Kubernetes provides a construct, called ‘namespace’, which allows a cluster to be partitioned into multiple “virtual clusters”. Names for resources deployed in a namespace must be unique, but that restriction does not apply across namespaces. In addition to isolating application resources, namespaces also provide a way to isolate groups of users and apportion cluster resources to those groups.
Usernames
In a Kubernetes cluster, each user is identified by a unique username and possibly one or more affiliated group names. Kubernetes maps (binds) the username and affiliated group names to roles that define which resources can be accessed and which operations can be performed on those resources. These role bindings can apply to a specific namespace or they can apply across the entire cluster (namespaced roles bindings cannot reference more than one namespace).
There are no hard and fast rules regarding what form a Kubernetes username may take. It may be a user’s email address that they use when authenticating themselves with an authentication provider. Or it may be an arbitrary name that is encoded in an externally generated TLS certificate. Whatever username is specified, it needs to map to role bindings that provide full access to the namespace where the user’s applications are deployed (this should already be the case if the user used Helm or an operator to deploy their application). It is beyond the scope of this document to determine how Kubernetes users should be managed. The following command can be used, however, to ensure that a username is mapped to a role with adequate permissions for a specific namespace:
$ kubectl create rolebinding <role_binding_name> --clusterrole=edit --user=<username> -n=<namespace>
Authentication and authorization
Each time a user issues a kubectl or helm command, their credentials (bearer token, TLS certificate, username/password, etc.) are sent on their behalf to the Kubernetes API server. There, the API server performs a user authentication check and if the user is authenticated, the user’s username and group names are matched against role bindings, to determine if the user is authorized to perform the requested operation. If the user is not authenticated, or the user does not have adequate permissions to perform the operation, then an error will be returned.
8.2. Robin user management¶
Robin Platform includes a robust user management system with Role Based Access Control (RBAC) that allows fine grain control of what operations each user is able to perform and which resources they are able to access. Robin Platform also manages all interactions with the Kubernetes API Server on behalf of all Robin users.
Users
Each person accessing a Robin cluster should do so using their own user account. The user account contains a username and Id that uniquely identifies the user within the cluster. All objects created by the user (e.g., applications) will be tagged with the user’s Id. The user account also contains key attributes about the user, such as first and last name, email address, phone number, etc., and provides a means for authenticating the user when they log into the cluster.
Tenants
Tenants are a Robin Platform construct that allows users to be organized into discrete groups based on function or business requirements. A user can be a member of multiple tenants, but each user is only able to access resources that are bound to the tenant they are currently logged into (e.g., a user would not be able to access an application they deployed when they were logged into a different tenant).
User roles
Each Robin user is assigned a role for each tenant they are a member of. The role determines which capabilities the user has and which objects they are able to access. Users who are assigned to multiple tenants can have a different role for each tenant they are a member of. Currently there are three roles that can be assigned to a user:
superadmin – A user assigned the superadmin role has full access to all cluster objects and resources (including those bound to individual tenants), and is able to perform all administrative functions in the Robin Platform cluster, such as adding users to the cluster, registering and sharing storage repositories, exporting/importing application backups, etc. Note that the superadmin role can only be assigned to a member of the Administrators tenant.
superadmin with limited capabilities – A superadmin with limited capabilities is a default superadmin user type without the following user capabilities.
ManageUserCapabilitiesManageAdministratorsTenantAddSelfToTenants
You can create a superadmin user with limited capabilities if you need the superadmin user with most of the superadmin capabilities but want to limit the capabilities to perform actions that elevate their permissions or affect critical system resources. When you have such scenarios, you can create a superadmin user and restrict the user with the following capabilities. For more information, see
tenantadmin – A user assigned the tenantadmin role has many of the same permissions as user with the superadmin role. But their scope is limited to a particular tenant which they are a member of. A tenantadmin user is able to view all resources bound to their respective tenant, can register and share storage repositories, export/import application backups, etc.
user – A user assigned the user role has no cluster admin capabilities and is, generally speaking, limited to managing the applications they have deployed or registered.
Authentication and authorization
Every command issued using the Robin Platform CLI results in a request being sent to the Robin Server. Before acting on the request, a check is made to ensure that the user making the request is authenticated and that they are authorized to perform the requested action on the specified object type.
Each request sent to the Robin Server contains a token that includes the username of the user, the tenant they are currently logged into, and an expiration timestamp. If the token is invalid (malformed) or it has expired, then the request will be denied. If the user is authenticated, then an authorization check is performed.
The first phase of the authorization check ensures that the user has adequate permissions to access the request method. The user needs to have the view permission for the specified object type when making a call to GET, the create permission when making a call to POST, the modify permission when making a call to PUT, and the delete permission when making a call to DELETE. For example, if the user issued the following Robin Platform CLI command:
robin app list
then a check will be made to ensure the user has permission to view objects of type APPLICATION.
When making a request to modify specific object instances, an additional check may be made to see if the user has permission to perform the specified action. For example, when a user issues a command to stop an application instance, before the action is taken a check is made to ensure the user has permission to perform the stop action on objects of type APPLICATION.
If the action the user wishes to perform will be applied to an actual object instance (which would normally be the case when making a request to modify or delete an object), then an additional check will be performed to ensure that the user is able to access the referenced object. Access to the object will be granted if one of the following conditions is met:
The user created and owns the object instance
The user has been assigned the tenantadmin role for the tenant the object is bound to, and they are logged into that tenant.
The user has been assigned the superadmin role, and they are logged into the Administrators tenant
The object type supports sharing and it has explicitly been shared with the user (for the requested action) or it has been shared with the user’s tenant (for the requested action).
Note that not all object types support additional actions beyond the standard permissions: view, create, update, and delete.
User capabilities
In addition to being assigned a role when they are added to a tenant, users are also assigned one or more User Capabilities. User capabilities are groupings of permissions that map individual object types to specific operations. As was outlined above, each object type has four permission mappings that map to standard API endpoint methods, GET, POST, PUT, and DELETE (view, create, update, and delete respectively). Additional permission mappings are provided that allow for a more granular level of access control. These additional mappings all extend the update permission, which controls the modification of existing objects. All object update operations for an object type are handled by its PUT method.
Object permission mappings are hierarchical in nature. For example, before you can start or stop an application, you first must be able to access (view) the application. Including the view, update, start, and stop permission mappings in the same user capability would be one way to accomplish this. Doing so would impose some significant limitations, however. It would make it nearly impossible to allow one set of users to have full access to apps and another to have view only capabilities.
To allow for a higher degree of flexibility, user capabilities
support the concept of inheritance. A user capability only needs to
include permission mappings that make sense for the stated purpose of
the user capability (e.g., Manage Applications). Dependent
permission mappings defined in other user capabilities are included
in the capability’s list of providers. Below is an example of how
this works. The ManageApplications user capability inherits
various user capabilities (providers) such as ViewApplications,
ViewBackups, ViewInstances, etc. It also defines permission
mappings that pertain specifically to the management of application
objects.
{
"id":3,
"name":"ManageApplications",
"capability_group":"Application",
"description":"Manage Applications"
"hidden":false,
"tenant_roles":[
"superadmin",
"tenantadmin",
"user"
],
"providers":[
"ViewApplications",
"ViewBackups",
"ViewInstances",
"ManageInstances",
"ViewDocker",
"ViewTags",
"ViewResourcePools",
"ViewBundles",
"ViewImages",
"ViewConfig",
"ViewEvents",
"ViewNetworking",
"ViewNodes",
"ViewJobs",
"ViewZones",
"ViewStorageArray",
"ViewNFSExports"
],
"capability_entries":[
{
"object_type":"APPLICATION",
"operation":"add_repo"
},
{
"object_type":"APPLICATION",
"operation":"addkey"
},
{
"object_type":"APPLICATION",
"operation":"addtrigger"
},
{
"object_type":"APPLICATION",
"operation":"addvol"
},
{
"object_type":"APPLICATION",
"operation":"computeqos"
},
{
"object_type":"APPLICATION",
"operation":"config"
},
{
"object_type":"APPLICATION",
"operation":"deltrigger"
},
{
"object_type":"APPLICATION",
"operation":"delvol"
},
{
"object_type":"APPLICATION",
"operation":"expandvol"
},
{
"object_type":"APPLICATION",
"operation":"hydrate"
},
{
"object_type":"APPLICATION",
"operation":"moveresources"
},
{
"object_type":"APPLICATION",
"operation":"probe"
},
{
"object_type":"APPLICATION",
"operation":"redeploy"
},
{
"object_type":"APPLICATION",
"operation":"register"
},
{
"object_type":"APPLICATION",
"operation":"remove_repo"
},
{
"object_type":"APPLICATION",
"operation":"restart"
},
{
"object_type":"APPLICATION",
"operation":"rollback"
},
{
"object_type":"APPLICATION",
"operation":"run_hook"
},
{
"object_type":"APPLICATION",
"operation":"scale"
},
{
"object_type":"APPLICATION",
"operation":"setreslimits"
},
{
"object_type":"APPLICATION",
"operation":"start"
},
{
"object_type":"APPLICATION",
"operation":"stop"
},
{
"object_type":"APPLICATION",
"operation":"storageqos"
},
{
"object_type":"APPLICATION",
"operation":"unregister"
},
{
"object_type":"APPLICATION",
"operation":"update"
},
{
"object_type":"APPLICATION",
"operation":"update_hpa"
},
{
"object_type":"APPLICATION",
"operation":"upgrade"
},
{
"object_type":"SNAPSHOT",
"operation":"update"
}
]
}
Note
Each user capability contains a list of the user roles it can be use with.
There are certain, special user capabilities that contain all of
the permission mappings (including those provided via inheritance)
needed for each user role. These are AllUserCapabilities,
AllTenantAdminCapabilities, and AllSuperAdminCapabilities.
User permissions
Each user that logs into a Robin cluster has a set of permission mappings that determine which operations they can perform on which object types. The set of permission mappings is determined by which user capabilities have been assigned to the user for the tenant they are currently logged into (users have a different set of permission mappings for each tenant they are a member of). A user’s current permissions are the set of all permission mappings assigned to the user based on their assigned user capabilities, plus those from all inherited capabilities.
Note
If multiple user capabilities assigned to a user inherit the same user capability, only one set of the inherited permission mappings will be assigned to the user.
Custom user capabilities
Robin provides a wide range of user capabilities that address the needs of users at various levels (cluster administrators, tenant administrators, and regular users). By default, each user when added to a tenant, will be assigned one of the following user capabilities, based on their assigned tenant role:
superadmin –
AllSuperAdminCapabilitiestenantadmin –
AllTenantAdminCapabilitiesuser –
AllUserCapabilities
Each of the above user capabilities provides the user with a full set of permissions appropriate for the role they have been assigned. It does this by including all relevant user capabilities in the provider list of the assigned capability. Cluster administrators can remove select capabilities from a user. They cannot, however, add or remove individual permissions. Nor are they able to give a user a specific set of permissions. If there is a need for this, then a custom user capability might be the way to go.
Custom user capabilities give cluster administrators the ability to give a user only those permissions needed for a particular use case. The permission mappings can be specified in a number of ways:
By including user capabilities that provide the desired permission mappings in the custom capability’s providers list.
By including individual permission mappings in the custom capability’s capability entries list.
By employing a combination of providers and capability entries.
When creating a custom user capability, you need to specify which
user roles the capability can be used with. For example, a custom
capability that focuses on cluster infrastructure probably should be
limited in scope to users having the superadmin role. Use the
following command to see which of the current user capabilities
(including custom capabilities) might provide the desired set of
permissions (or a sub-set of this list).
robin capabilities list-options --full
You can narrow the output by including the --group command line
option, or you can specify specific user capabilities on the command
line. When specifying capability entries on the command line, they
should be of the following format:
<object_type>:<operation>
Once you have created a custom user capability, you can assign it to
users when adding them to the cluster or to a tenant. You would do
this by including the custom capability on the command line when
using the Robin CLI to issue a robin user add or robin tenant
add-users command. Note that if no user capabilities are specified,
then one of the role specific default capabilities specified above
will be assigned.
Strictly speaking, a custom user capability is not the same thing as
a custom user role. It can, however, be deployed in such a way as to
provide functionality people think of when they think of custom
roles. Robin does not allow the creation of custom tenant roles
because tenant roles are very specifically focused on controlling a
user’s access level for object types they have permission to
access (granted by their assigned user capabilities). For example, a
regular user (one who has been assigned the user role) may have
permission to view applications (because they have been assigned the
ViewApplications user capability), but the access level imposed
by their role (user) prevents them from viewing applications they
didn’t create (don’t own). If you want to prevent a user from viewing
all applications, you need to remove those capabilities giving them
view permission on APPLICATION objects. Accomplishing this
may not be as straight forward as you might think. That’s because of
the loosely hierarchical nature of user capabilities. By design, each
user capability includes all of the user capabilities it is dependent
on in its providers list (e.g., the ManageApplications capability
includes the ViewApplications capability). This makes it hard to
remove specific permission mappings (the ViewApplications
capability may be imported by multiple user capabilities). This is not
an issue with a custom user capability. If there are a desired set of
permissions you wish to give to a user (or group of users) then it’s
just a matter of creating a custom capability and including the
permission mappings in the capability entries list.
Once created, custom user capabilities can be assigned to users, just like the capabilities provided by Robin. If a custom user capability is assigned to multiple users, then any change to the capability will be reflected in the permissions for each of the assigned user.
Note
Please refer to the previous section that provides details about user capabilities. When creating a custom user capability, describes what a user capability is.
Care should be taken when creating custom user capabilities as they may prevent or impede access to the Robin UI.
A user capability group is not specified when creating a custom
user capability as they are all assigned to the Custom
capability group.
Object sharing
As was outlined above, Robin RBAC control prevents users from
accessing objects they do not have permission to access. For example,
a regular user (a user assigned the role of user) will only be
able to view and manage objects (applications, snapshots, backups,
etc.) they create and own. Other users, even those in the same
tenant, will not be able to see the objects, let alone perform any
operations on them. There are restrictions on which objects a Tenant
Administrator can access as well. Tenant Administrators have
permission to view all objects created by all users in their tenant,
however they are not able to access objects created by users from
other tenants. Cluster Administrators, however, are able to access
all objects created by all users in all tenants, but only when they
are logged into the Administrators tenant.
There are times when it might be desirable to share an object with one or more users in a tenant. It also might be desirable for certain objects to be shared with users in multiple tenants. The Robin platform contains a mechanisim for sharing certain objects with multiple tenants and users.
The extent to which a particular object can be shared depends on what type of object it is. For example, it makes sense for bundles or application backups to be shared with users in multiple tenants, because these objects do not contain any context that is bound to a single tenant. The same can not be said for an application, however, which has a context which is bound to a tenant.
When sharing certain objects with a tenant, all members of the tenant automatically get full access to the object (e.g., all members of a tenant will be able to create applications from a shared Bundle). For other object types, sharing them with a tenant only allows the object to be shared with tenant users. It’s up to a cluster or tenant administrator to provide users with access.
Only a Cluster Administrators can share an object with a tenant other than the one it is bound to. Once an object has been shared with a tenant, however, administrators of the tenant can then share the object with members of the tenant (assuming the object supports user sharing). Following are a list of objects that can be shared with tenants:
Bundles
Images
Storage Repos
Docker Registries
Application Backups
Following is a list of objects that can be shared with tenant users:
Storage Repos
Applications
Application Backups
Application Snapshots
Namespaces
Note
By default, when a Cluster Administrator shares an object with a
tenant, administrators of the tenant will not be able to share the
object with members of their tenant. This, and other capabilities
can be extended to all administrators of the tenant when the
object is shared. Use the robin object-share list-options
command to output a list of sharable objects, showing which
operations can be assigned when sharing with tenants and users.
A Tenant Administrator can share all objects bound to (owned by) their tenant with their tenant users without restriction. This includes objects that are sharable across tenants (application backups and storage repos).
User administration
Before a user can begin to use Robin Platform to manage their applications, they need to log into the Robin Platform cluster using the Robin Platform CLI utility. Before they can do that, they need a user account. Robin Platform user accounts are created by the cluster administrator (a user having the superadmin role). The following information needs to be supplied when creating a user account:
username (must be unique within the Robin Platform cluster)
role (
superadmin,tenantadmin, oruser)initial password
Robin Platform will generate a TLS certificate for each user added to the cluster. The certificate includes the user’s username. Robin Platform will pass this certificate to the Kubernetes API server any time it makes a call on the user’s behalf. Note that role bindings with adequate permissions to manage applications in the user’s assigned namespace (bound to the user’s Kubernetes username and/or group names) will automatically be created.
Before a user can make use of the Robin Platform CLI, they must first authenticate themselves to the Robin Platform cluster. They do this by issuing the following command:
# robin login <username>
which prompts the user to enter their password. Upon a successful login, a token is returned that identifies the user, the tenant they are currently logged into, and their current namespace. This token is stashed in the user’s home directory, to be used with each successive commands issued by the user.
8.2.1. Robin Password Management¶
Robin CNP provides robust password management features to ensure the security and integrity of user accounts. This section outlines the password rules and controls, as well as the mechanisms in place to enhance password security.
Password Rules and Controls
The configurable password rules applied to all users in a CNP cluster include:
Minimum length: Require a minimum number of characters (recommended is 12, default is 8).
Maximum length: Allow maximum number of characters (no limit by default).
Character requirements:
At least one lowercase character (a-z).
At least one uppercase character (A-Z).
At least one numeric character (0-9).
Optionally, at least one special character (!@#$%^&*, etc.).
Space restrictions: Passwords cannot begin or end with space (space is not considered a special character).
We have implemented a mechanism that requires a user to generate a new password on their first login or after a set number of days (disabled by default).
Password Lock and Auto-Unlock
Password lockout occurs after a configured number of successive incorrect password attempts (5 failed attempts is the default). A locked user account will auto-unlock after a set period (15 minutes is the default).
If the lockout_duration is set to ‘0’, the user’s account will remain locked until it’s unlocked by an admin user. The password auto-lockout feature is enabled by default (it can be disabled by setting the lockout_threshold to ‘0’).
Password Hashing and Security
Robin does not store user passwords as plain text. Instead, each user’s password is hashed, and the hash is stored as part of their user record in the cluster database. To enhance security and mitigate the risk of exploitation in the event of a data breach, the following measures are implemented:
Salting: A random salt string is added for each user when generating a hash of their password. This ensures that two users with the same password will have different password hashes.
Salt regeneration: A new salt string is generated for a user each time they change their password.
Note
Password rules and controls only apply to local CNP cluster users (e.g., not managed by an external identity provider, such as LDAP).
To view a list of password rules that have been applied currently, use the following command.
# robin password-rules list
Scope | TenantID | Tenant | MinChars | MaxChars | MinLower | MinUpper | MinNumeric | MinSpecial | SaltLen | ExpDays | AdminPasswdExp | LockoutThreshold | LockoutDuration
--------+----------+--------+----------+----------+----------+----------+------------+------------+---------+---------+----------------+------------------+-----------------
CLUSTER | | | 8 | | 1 | 1 | 1 | 0 | 16 | | False | 0 | 15
Let’s say you want to update the minimum number of characters required from 8 to 10. You can run the following command.
# robin password-rules update <optional argument> <value> <scope: 'CLUSTER' or 'TENANT'>
# robin password-rules update --min-chars 10 CLUSTER
Refer to the table below to understand what each argument or parameter does. Alternatively, you can use the robin password-rules -h command to view more details about them.
Argument |
Description |
|---|---|
scope |
Scope of password rules to list (valid values are ‘CLUSTER’ and ‘TENANT’) |
tenant_id |
Tenant Id (only relevant when scope is ‘TENANT’) |
–min-chars |
Minimum number of characters required |
–max-chars |
Maximum number of characters allowed (‘0’ means no limit) |
–min-lower |
Minimum number of lower-case characters allowed |
–min-upper |
Minimum number of upper-case characters allowed |
–min-numeric |
Minimum number of numeric characters allowed |
–min-special |
Minimum number of special characters allowed |
–salt-len |
Specifies the length of the salt string added to the user-supplied password before hashing. A longer salt string ensures unique password hashes and enhances security by making the hash harder to crack. |
–exp-days |
Number of days before a user’s password expires |
–enable-admin-password-exp |
Enable password expiration for admin users |
–disable-admin-password-exp |
Disable password expiration for admin users |
–lockout-threshold |
Number of failed login attempts before locking a user’s account (a value of ‘0’ disables user account lockout). |
–lockout-duration |
Number of minutes before automatically unlocking a user’s account (a value of ‘0’ disables auto unlocking). |
8.3. LDAP user authentication¶
A Robin user is required to provide their username and password when logging into a Robin cluster. The Robin Server uses this username and password to perform an authentication check. By default, user authentication is performed by Robin directly. For environments where user accounts are maintained on a centralized LDAP server, Robin allows users to be configured so that their authentication is handled by the LDAP server.
Robin Platform supports the following LDAP server types:
Active Directory
OpenLDAP
8.3.1. Adding an LDAP server to a Robin cluster¶
Before users can be configured for LDAP authentication, the LDAP server needs to be added to the Robin cluster.
The following information is required when adding an LDAP server:
name – The name that will identify the LDAP server within the Robin cluster
hostname – The IP address or hostname where the LDAP server is running
port – The port number to use when connecting to the server
server_type –
OPEN_LDAP,ACTIVE_DIRECTORYorGOOGLE_CLOUDusername – The username of an LDAP user that has full access rights
search_base – The search base defines the starting point for the search in the directory tree
netbios – Normally, the netbios is the domainname minus the suffix (e.g., domainname instead of domainname.com). Before adding the LDAP server to a Robin cluster, obtain the NETBIOS from the LDAP server. Note that netbios is only required when server_type is ACTIVE_DIRECTORY.
The following example shows how an Active Directory LDAP server is added to a Robin cluster:
# robin ldap add-server ad1 10.9.53.5 389 ACTIVE_DIRECTORY administrator mydomain.com --netbios mydomain
Note
An LDAP Directory Tree can be structured in multiple ways, which can effect where users and groups are located. Robin provides options for specifying the global search base, as well as search bases for users and groups, when adding an LDAP server. Additionally, each of the RobinLDAP commands allows for a custom search base to be specified.
In addition, the names of attribues in user and group entries can differ, depending on the type of LDAP server (
ACTIVE_DIRECTORYorOPEN_LDAP) and how it’s configured. Robin provides CLI commands for listing and updating the attribute names used internally when accessing a user’s username, first and last name, email address, or when accessing group members, etc.
8.3.2. Adding users with LDAP authentication¶
When adding a user to a Robin cluster, the user can be configured so
that authentication checks go through an external LDAP server. When
using the Robin CLI to add the user, include the --ldap and
--ldap-server <ldap_server_name> flags on the command line. The
command to add a user should look something like this:
# robin user add user1 tenant1 user --ldap --ldap-server ldap1
Note
If the user’s LDAP username contains characters that are not
allowed in a Robin cluster (valid characters include a-z,
A-Z, 0-9, ., -, and _) , then the user’s
distinguished name (DN) should be specified. When the user logs
into the Robin cluster, their DN will be sent to the LDAP server
for validation instead of their username.
8.3.3. Searching for LDAP users¶
The Robin CLI includes commands to get a listing of users and user groups from an LDAP server. The users returned from these queries can then be imported into the Robin cluster. When importing an LDAP user, an account for the user will be created in the Robin cluster.
# robin ldap list-users ldap1
Username | Email Address | User Principal Name | Object SID
---------+---------------+---------------------+--------------------------------------
user1 | None | None | 050ce4de-2f64-1033-8989-a53eb149a944
user2 | None | None | 29f6dc28-2f64-1033-898b-a53eb149a944
Note
There is no direct link between a user’s account in a Robin cluster and their account on the LDAP server. other than as a means for authenticating the user during login.
On a very large installation, user queries can take a long time when sending the request to an LDAP server with a large directory.
8.3.4. Importing LDAP users¶
Importing an LDAP user is similar to adding a Robin user. The tenant the user will be added to and their role in that tenant must be specified. When importing an LDAP user, a validation check will be performed, to ensure the user exists in the server’s directory.
# robin ldap import-users ldap1 user1 tenant1 user
8.3.5. Importing members of an LDAP group¶
All members of an LDAP group can be imported in a single operation. Note that all users will be added to the same tenant with the same tenant role and (optionally) custom user capabilities. Key user attributes, such as full name, email address, etc. will be imported along with the user’s username.
# robin ldap import-group ldap1 ldap_group tenant1 user
8.4. OpenShift user authentication¶
8.4.1. Listing OpenShift users¶
The Robin CLI includes commands to get a listing of users and user groups from an OpenShift cluster. The users returned from these queries can then be imported into the Robin cluster. When importing an OpenShift user, an account for the user will be created in the Robin cluster.
# robin openshift list-users [users]
|
Comma separated list of OpenShift users. If no users are provided then all OpenShift users will be displayed. |
Example:
# robin openshift list-users
Username | UID | Groups
---------+--------------------------------------+-------------
admin1 | ee29177c-b48b-42a9-b63c-e9cce6935219 | robin-users
admin2 | d613991f-1975-4225-8d67-2f23aac05215 | robin-users
robin | 881fdd9d-9270-4d1b-a853-ec767b3793cc | robin-users
user1 | 678a46ce-2c32-44ce-a88c-ca084d29c60c | robin-users
user2 | c9ba0e73-b90a-4285-86b6-479e3ddb91ed | robin-users
user3 | 883c0d99-0c4d-4f89-a7ac-79da198e9229 | robin-users
user4 | dee5d68c-ce27-4500-afdc-21d730fe7d23 | robin-users
user5 | e2660780-2a91-44a6-87c1-f9f30724c7de | robin-users
Note
This command is only supported when Robin is deployed on an OpenShift cluster.
There is no direct link between a user’s account in a Robin cluster and their account on an OpenShift cluster, other than as a means for authenticating the user during login to Robin.
8.4.2. Adding users with OpenShift authentication¶
When adding a user when Robin is deployed on an OpenShift cluster,
the user can be configured so that authentication checks go to
OpenShift for authentication. When using the Robin CLI to add the
user, include the --openshift flag on the command line. A command
to add a Robin user with OpenShift authentication will look something
like this:
# robin user add user1 tenant1 user --openshift
For more details on the options available for the robin user add command and an example of its usage, review the section detailed here.
Note
This operation is only supported when Robin is deployed on an OpenShift cluster.
8.4.3. Importing OpenShift users¶
Importing an OpenShift user is similar to adding a Robin user. The tenant the user will be added to and their role in that tenant must be specified. When importing an OpenShift user, a validation check will be performed, to ensure the user exists in the cluster.
# robin openshift import-users users tenant tenant_role [user_capabilities]
|
Comma separated list of OpenShift users to import |
|
Tenant that all imported users will be made a member of |
|
User role for the tenant assigned to each imported user |
|
Optional comma separated list of tenant specific capabilities to assign to the each user being added. Note that if no user_capabilities are specified, then full capabilities for the specified role will be assigned. If it’s desired that no capabilities be granted to the user then specify ‘NoCapabilities’ on the command line |
Note
To view a list of all user capabilities review the section detailed here.
Example:
# robin openshift import-users admin1 t1 tenantadmin
Successfully added one user: admin1
# robin user list admin1
ID | Username | Full Name | Email | Tenants | Current Tenant | Current Role | Current Namespace | Authentication
---+----------+-----------+-------+---------+----------------+--------------+-------------------+----------------
4 | admin1 | | | t1 | t1 | tenantadmin | t002-u000004 | openshift
Note
This command is only supported when Robin is deployed on an OpenShift cluster.
8.4.4. Listing OpenShift groups¶
Users from OpenShift groups can be imported into a Robin cluster. Use the following command to search for OpenShift groups and view group members:
# robin openshift list-groups [groups]
|
Comma separated list of OpenShift group names. If no group names are provided then all OpenShift groups will be displayed (note that a listing of all groups can take a long time to finish). |
Example:
# robin openshift list-groups
Name | UID | Users
------------+--------------------------------------+---------------------------------------------------
robin-users | abc53d88-ca7f-4634-b70f-7f51d538d9e4 | robin,user1,user2,user3,user4,user5,admin1,admin2
Note
This command is only supported when Robin is deployed on an OpenShift cluster.
8.4.5. Importing members of an OpenShift group¶
All members of an OpenShift group can be imported into a Robin cluster with a single operation. Note that all users will be added to the same tenant with the same tenant role and (optionally) custom user capabilities. Key user attributes, such as the user’s full name will be imported along with the user’s username. Issue the following command to import one or more members of an OpenShift group:
# robin openshift import-group tenant tenant_role [user_capabilities]
--exclude-users EXCLUDE_USERS
|
Name of the OpenShift group to import users from |
|
Tenant that all imported users will be made a member of |
|
User role for the tenant assigned to each imported user |
|
Optional comma separated list of tenant specific capabilities to assign to the each user being added. Note that if no user_capabilities are specified, then full capabilities for the specified role will be assigned. If it’s desired that no capabilities be granted to the user then specify ‘NoCapabilities’ on the command line |
|
Comma separated list of users to exclude from importation |
Note
To view a list of all user capabilities review the section detailed here.
Example:
# robin openshift import-group robin-users t2 user --exclude-users robin,admin1,admin2,user1,user2
Imported OpenShift users: 'user3, user4, user5'
# robin user list
ID | Username | Full Name | Email | Tenants | Current Tenant | Current Role | Current Namespace | Authentication
---+----------+---------------+-------+----------------+----------------+--------------+-------------------+----------------
3 | admin | Robin Systems | | Administrators | Administrators | superadmin | t001-u000003 | local
4 | admin1 | | | t1 | t1 | tenantadmin | t002-u000004 | openshift
5 | user3 | | | t2 | t2 | user | t003-u000005 | openshift
6 | user4 | | | t2 | t2 | user | t003-u000006 | openshift
7 | user5 | | | t2 | t2 | user | t003-u000007 | openshift
Note
This command is only supported when Robin is deployed on an OpenShift cluster.
It may not be practical to use this command to add users from an
OpenShift group to a Robin cluster. If the users in the group
will be assigned to multiple tenants and have different roles. It
might make more sense to use the robin openshift add-users
command to add the users in bunches.
8.5. User capabilities operations¶
8.5.1. List user capabilities¶
List user capabilities that can be assigned to users based on their tenant role:
# robin capabilities list [names]
--group <capability_group>
--all
--full
|
Comma separated list of user capabilities to list |
|
User capability group |
|
Show all user capabilities (including hidden ones). Note that hidden capabilities will be returned if specified on the command line. |
|
Show additional information about each user capability |
Example 1 (List non-hidden user capabilities):
# robin capabilities list
Group | Name | Hidden | Description
---------------+-----------------------------+--------+--------------------------------------------------------
Application | ManageApplications | False | Manage Applications
Application | ShareApplications | False | Share Applications with tenant users
Application | CreateApplications | False | Create Applications
Application | SnapshotApplications | False | Snapshot Applications
Application | UseNamespaces | False | Use Namespaces
Application | ManageNamespaces | False | Manage Namespaces
Application | ImportNamespaces | False | Import Kubernetes Namespaces
Infrastructure | ManageNetworkPolicies | False | Manage NetworkPolicies
Application | ShareNamespaces | False | Share Namespaces with other tenant users
Application | ManagePersistentVolumes | False | Manage Persistent Data Volumes
Application | SharePersistentVolumes | False | Share Persistent Data Volumes with other tenant users
Application | CreateBackups | False | Create Application Backups
Application | DeleteBackups | False | Delete Application Backups
Application | ImportBackups | False | Import Application Backups
Application | ExportBackups | False | Export Application Backups
Application | PurgeBackups | False | Purge Application Backups from Storage Repo
Application | TenantShareBackups | False | Share Application Backups with tenants
Application | UserShareBackups | False | Share Application Backups with tenant users
Application | BackupApplications | False | Backup Applications
Application | CloneApplications | False | Clone Applications
Application | DeleteApplications | False | Delete Applications
Application | CreatePrivelegedApps | False | Create Privileged Applications
Infrastructure | ViewSystem | False | View system attributes
Infrastructure | ManageSystem | False | Manage system attributes
Infrastructure | ManageApplicationResources | False | Manage Application resources
Application | ManageK8sApplications | False | Manage k8s Applications
Application | ShareK8sApplications | False | Share Application Backups
Application | ManageK8sBackups | False | Manage K8s Application Backups
Application | CreateImages | False | Create Application Images
Application | CreateBundles | False | Create Application Bundles
Application | ManageInstances | False | Manage Application Instances
Application | ManageVolumes | False | Manage Storage Volumes
Application | ManageVolumeBackups | False | Manage Storage Volume Backups
Application | ManageVolumeSnapshots | False | Manage Storage Volume Snapshots
Application | ManageDocker | False | Manage Docker Registries
Infrastructure | ManageNetworking | False | Manage Networking
Infrastructure | ManageResourcePools | False | Manage Resource Pools
Infrastructure | ManageTags | False | Manage Tags
Infrastructure | ManageResourceGroups | False | Manage Resource groups
Infrastructure | ManageConfig | False | Manage Configuration Information
Infrastructure | AccessConsole | False | Access a physical node's console
Infrastructure | AccessDashboard | False | Access a cluster's dashboard
Infrastructure | ViewLicense | False | View cluster license
Infrastructure | ManageLogCollections | False | Manage Log Collection Information
Infrastructure | ManageFileCollections | False | Manage File Collection Information
Infrastructure | ManageNodes | False | Manage Physical Nodes
Infrastructure | ManageEvents | False | Manage System Events and Alerts
Infrastructure | ManageJobs | False | Manage Jobs
Infrastructure | CancelJobs | False | Fail Jobs
Infrastructure | ManageZones | False | Manage Zones
Infrastructure | ManageWorkflow | False | Manage Workflows
Infrastructure | UpdateProtectionGroups | False | Update Protection Groups
Infrastructure | CreateProtectionGroups | False | Create Protection Groups
Infrastructure | DeleteProtectionGroups | False | Delete Protection Groups
Infrastructure | CreateStorageRepos | False | Create Storage Repos
Infrastructure | UseStorageRepos | False | Use Storage Repos
Infrastructure | ManageStorageRepos | False | Manage Storage Repos
Application | TenantShareRepos | False | Share Storage Repos with tenants
Application | UserShareRepos | False | Share Storage Repos with tenant users
Infrastructure | ManageNFSExports | False | Manage NFS exports
Infrastructure | GenerateReports | False | Generate reports
Infrastructure | ShareObjectsWithTenants | False | Share various objects with tenants
Infrastructure | ChangeOwner | False | Change the owner for various objects
Infrastructure | ManageTenantResources | False | Manage Tenants, Tenant users and their properties
User | ManageUsers | False | Manage Users and their properties
User | UpdateUserRole | False | Update roles for users
User | UpdateTenants | False | Update Tenants, Tenant users and their properties
User | ManageTenants | False | Manage Tenants, Tenant users and their properties
User | AddSelfToTenants | False | Ability to add yourself to a tenant
User | ManageSshKeys | False | Manage SSH Keys
User | ManageCapabilityEntries | False | Create, Update, and Delete User Capabilities
User | ManageAdministratorsTenant | False | Manage the Adminstrators Tenant
User | ManageTiller | False | Manage Tiller objects
User | ManageDirectoryServices | False | Manage LDAP/Active Directory services and their properties
User | ManageOpenShift | False | Manage OpenShift users/groups and their properties
User | ManageUserAudit | False | Manage user audit properties
User | ManagePasswordRules | False | Manage Password Rules and their properties
Infrastructure | ManageCerts | False | Manage Cluster Certificates
Infrastructure | ManageCertGroups | False | Manage Cluster Certificate Groups
Infrastructure | ViewPatroni | False | View Patroni Cluster
Infrastructure | ManagePatroni | False | Manage Patroni Cluster
Infrastructure | ManageK8s | False | Manage Kubernetes resources
Infrastructure | ManageK8sUsers | False | Manage Kubernetes resources
Infrastructure | ViewK8sStorage | False | View Kubernetes storage resources
Infrastructure | ManageK8sStorage | False | Manage Kubernetes storage resources
Administration | AllSuperAdminCapabilities | False | All Super Admin Capabilities
Administration | AllUserCapabilities | False | All User Capabilities
Administration | AllClusterUserCapabilities | False | All Cluster User Capabilities
Administration | AllClusterAdminCapabilities | False | All Cluster Admin Capabilities
Administration | AllTenantAdminCapabilities | False | All Tenant Admin Capabilities
Infrastructure | ManagePCIResource | False | Manage PCI Resources
Application | AbortBackupCreate | False | Abort Application Backup Creation
Application | AbortSnapshotImport | False | Abort Application Backup Import
Application | ViewHelmCharts | False | View Helm Charts
Application | ViewHelmRepos | False | View Helm Repos
Application | ManageHelmRepos | False | Manage Helm Repos
Application | ViewHelmRegistries | False | View Helm Regristries
Application | ManageHelmRegistries | False | Manage Helm Regristries
Application | ViewHelmReleases | False | View Helm Apps
Application | ManageHelmReleases | False | Manage Helm Apps
Example 2 (List all user capabilities in a capability group):
# robin capabilities list --group User
Group | Name | Hidden | Description
------+-------------------------+--------+------------------------------------------------------------
User | ViewUsers | True | View Users and their properties
User | ManageUsers | False | Manage Users and their properties
User | ViewUserAuth | True | View user auth information
User | UpdateUserRole | False | Update roles for users
User | ViewTenants | True | View Tenants and their properties
User | UpdateTenants | False | Update Tenants, Tenant users and their properties
User | ManageTenants | False | Manage Tenants, Tenant users and their properties
User | ViewUserCapabilities | True | View User Capabilities and their properties
User | ManageUserCapabilities | False | Manage User Capabilities and their properties
User | CreateUserCapabilities | False | Create, Update, and Delete User Capabilities
User | ViewTiller | True | View Tiller objects
User | ManageTiller | False | Manage Tiller objects
User | ViewDirectoryServices | True | View LDAP/Active Directory services and their properties
User | ManageDirectoryServices | False | Manage LDAP/Active Directory services and their properties
User | ViewOpenShift | True | View OpenShift users/groups and their properties
User | ManageOpenShift | False | Manage OpenShift users/groups and their properties
User | ViewUserAudit | True | View user audit properties
User | ManageUserAudit | False | Manage user audit properties
User | ViewK8sUserAuth | True | View Kubernetes user context information
Example 3 (Show details for a single user capability):
# robin capabilities list --full ManageApplications
Group | Name | Hidden | Description
------------+--------------------+--------+---------------------
Application | ManageApplications | False | Manage Applications
Tenant Roles:
superadmin
tenantadmin
user
Providers:
ViewApplications
ViewBackups
ViewInstances
ManageInstances
ViewDocker
ViewTags
ViewResourcePools
ViewBundles
ViewImages
ViewConfig
ViewEvents
ViewNetworking
ViewNodes
ViewJobs
ViewZones
ViewStorageArray
ViewNFSExports
Capability Entries:
APPLICATION add_repo
APPLICATION addkey
APPLICATION addtrigger
APPLICATION addvol
APPLICATION computeqos
APPLICATION config
APPLICATION deltrigger
APPLICATION delvol
APPLICATION expandvol
APPLICATION hydrate
APPLICATION moveresources
APPLICATION probe
APPLICATION redeploy
APPLICATION register
APPLICATION remove_repo
APPLICATION restart
APPLICATION rollback
APPLICATION run_hook
APPLICATION scale
APPLICATION setreslimits
APPLICATION start
APPLICATION stop
APPLICATION storageqos
APPLICATION unregister
APPLICATION update
APPLICATION update_hpa
APPLICATION upgrade
SNAPSHOT update
Returns a list of user capabilities that can be assigned to users based on their tenant role:.
End Point: /api/v3/robin_server/user-capabilities
Method: GET
URL Parameters: None
Data Parameters:
all_capabilities: true- Utilizing this parameter within the payload results in all user capabilities including hidden ones being returned.capability_group: <group_name>- Utilizing this parameter within the payload by specifying a valid group name results in only capabilities within that group being returned.
Port: RCM Port (default value is 29442)
Headers:
Authorization: <auth_token>: Authorization token to identify which user is sending the request. The token can be acquired from the login API.
Success Response Code: 200
Error Response Code: 500 (Internal Server Error), 401 (Unauthorized Error), 400 (Invalid API Usage Error)
Example Response:
Output
{
"items":[
{
"capability_group":"Application",
"id":3,
"description":"Manage Applications",
"providers":[
"ViewApplications",
"ViewBackups",
"ViewInstances",
"ManageInstances",
"ViewDocker",
"ViewTags",
"ViewResourcePools",
"ViewBundles",
"ViewImages",
"ViewConfig",
"ViewEvents",
"ViewNetworking",
"ViewNodes",
"ViewJobs",
"ViewZones",
"ViewStorageArray",
"ViewNFSExports"
],
"hidden":false,
"name":"ManageApplications",
"capability_entries":[
{
"operation":"add_repo",
"object_type":"APPLICATION"
},
{
"operation":"addkey",
"object_type":"APPLICATION"
},
{
"operation":"addtrigger",
"object_type":"APPLICATION"
},
{
"operation":"addvol",
"object_type":"APPLICATION"
},
{
"operation":"computeqos",
"object_type":"APPLICATION"
},
{
"operation":"config",
"object_type":"APPLICATION"
},
{
"operation":"deltrigger",
"object_type":"APPLICATION"
},
{
"operation":"delvol",
"object_type":"APPLICATION"
},
{
"operation":"expandvol",
"object_type":"APPLICATION"
},
{
"operation":"hydrate",
"object_type":"APPLICATION"
},
{
"operation":"moveresources",
"object_type":"APPLICATION"
},
{
"operation":"probe",
"object_type":"APPLICATION"
},
{
"operation":"redeploy",
"object_type":"APPLICATION"
},
{
"operation":"register",
"object_type":"APPLICATION"
},
{
"operation":"remove_repo",
"object_type":"APPLICATION"
},
{
"operation":"restart",
"object_type":"APPLICATION"
},
{
"operation":"rollback",
"object_type":"APPLICATION"
},
{
"operation":"run_hook",
"object_type":"APPLICATION"
},
{
"operation":"scale",
"object_type":"APPLICATION"
},
{
"operation":"setreslimits",
"object_type":"APPLICATION"
},
{
"operation":"start",
"object_type":"APPLICATION"
},
{
"operation":"stop",
"object_type":"APPLICATION"
},
{
"operation":"storageqos",
"object_type":"APPLICATION"
},
{
"operation":"unregister",
"object_type":"APPLICATION"
},
{
"operation":"update",
"object_type":"APPLICATION"
},
{
"operation":"update_hpa",
"object_type":"APPLICATION"
},
{
"operation":"upgrade",
"object_type":"APPLICATION"
},
{
"operation":"update",
"object_type":"SNAPSHOT"
}
],
"tenant_roles":[
"superadmin",
"tenantadmin",
"user"
]
},
{
"capability_group":"Application",
"id":4,
"description":"Share Application Backups",
"providers":[
"ViewApplications",
"ViewK8sApplications"
],
"hidden":false,
"name":"ShareApplications",
"capability_entries":[
{
"operation":"share",
"object_type":"APPLICATION"
},
{
"operation":"unshare",
"object_type":"APPLICATION"
},
{
"operation":"share",
"object_type":"K8S_APPLICATION"
},
{
"operation":"unshare",
"object_type":"K8S_APPLICATION"
},
{
"operation":"share",
"object_type":"SNAPSHOT"
},
{
"operation":"unshare",
"object_type":"SNAPSHOT"
}
],
"tenant_roles":[
"superadmin",
"tenantadmin"
]
},
{
"capability_group":"Application",
"id":5,
"description":"Create Applications",
"providers":[
"ManageApplications"
],
"hidden":false,
"name":"CreateApplications",
"capability_entries":[
{
"operation":"create",
"object_type":"APPLICATION"
}
],
"tenant_roles":[
"superadmin",
"tenantadmin",
"user"
]
},
{
"capability_group":"Application",
"id":6,
"description":"Snapshot Applications",
"providers":[
"ViewApplications"
],
"hidden":false,
"name":"SnapshotApplications",
"capability_entries":[
{
"operation":"setsnapback",
"object_type":"APPLICATION"
},
{
"operation":"snapshot",
"object_type":"APPLICATION"
}
],
"tenant_roles":[
"superadmin",
"tenantadmin",
"user"
]
},
{
"capability_group":"Application",
"id":8,
"description":"Use Namespaces",
"providers":[
],
"hidden":false,
"name":"UseNamespaces",
"capability_entries":[
{
"operation":"deploy_app",
"object_type":"NAMESPACE"
}
],
"tenant_roles":[
"superadmin",
"tenantadmin",
"user"
]
},
{
"capability_group":"Application",
"id":9,
"description":"Manage Namespaces",
"providers":[
"ViewNamespaces"
],
"hidden":false,
"name":"ManageNamespaces",
"capability_entries":[
{
"operation":"create",
"object_type":"NAMESPACE"
},
{
"operation":"delete",
"object_type":"NAMESPACE"
},
{
"operation":"update",
"object_type":"NAMESPACE"
}
],
"tenant_roles":[
"superadmin",
"tenantadmin",
"user"
]
},
{
"capability_group":"Application",
"id":10,
"description":"Share Namespaces with other tenant users",
"providers":[
"ViewNamespaces"
],
"hidden":false,
"name":"ShareNamespaces",
"capability_entries":[
{
"operation":"user_share",
"object_type":"NAMESPACE"
},
{
"operation":"user_unshare",
"object_type":"NAMESPACE"
}
],
"tenant_roles":[
"superadmin",
"tenantadmin"
]
},
{
"capability_group":"Application",
"id":12,
"description":"Create Application Backups",
"providers":[
"ViewBackups"
],
"hidden":false,
"name":"CreateBackups",
"capability_entries":[
{
"operation":"create",
"object_type":"BACKUP"
},
{
"operation":"update",
"object_type":"BACKUP"
},
{
"operation":"create",
"object_type":"K8S_BACKUP"
},
{
"operation":"update",
"object_type":"K8S_BACKUP"
}
],
"tenant_roles":[
"superadmin",
"tenantadmin",
"user"
]
},
{
"capability_group":"Application",
"id":13,
"description":"Delete Application Backups",
"providers":[
"ViewBackups"
],
"hidden":false,
"name":"DeleteBackups",
"capability_entries":[
{
"operation":"delete",
"object_type":"BACKUP"
},
{
"operation":"delete",
"object_type":"K8S_BACKUP"
}
],
"tenant_roles":[
"superadmin",
"tenantadmin",
"user"
]
},
{
"capability_group":"Application",
"id":14,
"description":"Import Application Backups",
"providers":[
"ViewBackups"
],
"hidden":false,
"name":"ImportBackups",
"capability_entries":[
{
"operation":"import",
"object_type":"BACKUP"
},
{
"operation":"import",
"object_type":"K8S_BACKUP"
}
],
"tenant_roles":[
"superadmin",
"tenantadmin"
]
},
{
"capability_group":"Application",
"id":15,
"description":"Export Application Backups",
"providers":[
"ViewBackups"
],
"hidden":false,
"name":"ExportBackups",
"capability_entries":[
{
"operation":"export",
"object_type":"BACKUP"
},
{
"operation":"export",
"object_type":"K8S_BACKUP"
}
],
"tenant_roles":[
"superadmin",
"tenantadmin"
]
},
{
"capability_group":"Application",
"id":16,
"description":"Purge Application Backups from Storage Repo",
"providers":[
"ViewBackups"
],
"hidden":false,
"name":"PurgeBackups",
"capability_entries":[
{
"operation":"purge",
"object_type":"BACKUP"
},
{
"operation":"purge",
"object_type":"K8S_BACKUP"
}
],
"tenant_roles":[
"superadmin",
"tenantadmin",
"user"
]
},
{
"capability_group":"Application",
"id":17,
"description":"Share Application Backups with tenants",
"providers":[
"ViewBackups"
],
"hidden":false,
"name":"TenantShareBackups",
"capability_entries":[
{
"operation":"tenant_share",
"object_type":"BACKUP"
},
{
"operation":"tenant_unshare",
"object_type":"BACKUP"
},
{
"operation":"tenant_share",
"object_type":"K8S_BACKUP"
},
{
"operation":"tenant_unshare",
"object_type":"K8S_BACKUP"
}
],
"tenant_roles":[
"superadmin"
]
},
{
"capability_group":"Application",
"id":18,
"description":"Share Application Backups with tenant users",
"providers":[
"ViewBackups"
],
"hidden":false,
"name":"UserShareBackups",
"capability_entries":[
{
"operation":"user_share",
"object_type":"BACKUP"
},
{
"operation":"user_unshare",
"object_type":"BACKUP"
},
{
"operation":"user_share",
"object_type":"K8S_BACKUP"
},
{
"operation":"user_unshare",
"object_type":"K8S_BACKUP"
}
],
"tenant_roles":[
"superadmin",
"tenantadmin"
]
},
{
"capability_group":"Application",
"id":19,
"description":"Backup Applications",
"providers":[
"ViewApplications"
],
"hidden":false,
"name":"BackupApplications",
"capability_entries":[
{
"operation":"backup",
"object_type":"APPLICATION"
},
{
"operation":"delete_backup",
"object_type":"APPLICATION"
},
{
"operation":"restore",
"object_type":"APPLICATION"
}
],
"tenant_roles":[
"superadmin",
"tenantadmin",
"user"
]
},
{
"capability_group":"Application",
"id":20,
"description":"Clone Applications",
"providers":[
"ManageApplications"
],
"hidden":false,
"name":"CloneApplications",
"capability_entries":[
{
"operation":"clone",
"object_type":"APPLICATION"
}
],
"tenant_roles":[
"superadmin",
"tenantadmin",
"user"
]
},
{
"capability_group":"Application",
"id":21,
"description":"Delete Applications",
"providers":[
"ManageApplications"
],
"hidden":false,
"name":"DeleteApplications",
"capability_entries":[
{
"operation":"delete",
"object_type":"APPLICATION"
}
],
"tenant_roles":[
"superadmin",
"tenantadmin",
"user"
]
},
{
"capability_group":"Application",
"id":22,
"description":"Create Privileged Applications",
"providers":[
],
"hidden":false,
"name":"CreatePrivelegedApps",
"capability_entries":[
{
"operation":"create",
"object_type":"PRIVILEGED_APP"
}
],
"tenant_roles":[
"superadmin",
"tenantadmin",
"user"
]
},
{
"capability_group":"Infrastructure",
"id":23,
"description":"View system attributes",
"providers":[
],
"hidden":false,
"name":"ViewSystem",
"capability_entries":[
{
"operation":"view",
"object_type":"METRICS"
},
{
"operation":"view",
"object_type":"SYSTEM"
}
],
"tenant_roles":[
"superadmin",
"tenantadmin",
"user"
]
},
{
"capability_group":"Infrastructure",
"id":24,
"description":"Manage system attributes",
"providers":[
],
"hidden":false,
"name":"ManageSystem",
"capability_entries":[
{
"operation":"create",
"object_type":"SYSTEM"
},
{
"operation":"update",
"object_type":"SYSTEM"
}
],
"tenant_roles":[
"superadmin"
]
},
{
"capability_group":"Infrastructure",
"id":25,
"description":"Manage Application resources",
"providers":[
],
"hidden":false,
"name":"ManageApplicationResources",
"capability_entries":[
{
"operation":"snapshot_limits",
"object_type":"APPLICATION"
}
],
"tenant_roles":[
"superadmin",
"tenantadmin"
]
},
{
"capability_group":"Application",
"id":27,
"description":"Manage k8s Applications",
"providers":[
"ViewK8sApplications"
],
"hidden":false,
"name":"ManageK8sApplications",
"capability_entries":[
{
"operation":"add_repo",
"object_type":"K8S_APPLICATION"
},
{
"operation":"backup",
"object_type":"K8S_APPLICATION"
},
{
"operation":"clone",
"object_type":"K8S_APPLICATION"
},
{
"operation":"config",
"object_type":"K8S_APPLICATION"
},
{
"operation":"create",
"object_type":"K8S_APPLICATION"
},
{
"operation":"delete",
"object_type":"K8S_APPLICATION"
},
{
"operation":"hydrate",
"object_type":"K8S_APPLICATION"
},
{
"operation":"probe",
"object_type":"K8S_APPLICATION"
},
{
"operation":"register",
"object_type":"K8S_APPLICATION"
},
{
"operation":"remove_repo",
"object_type":"K8S_APPLICATION"
},
{
"operation":"restart",
"object_type":"K8S_APPLICATION"
},
{
"operation":"restore",
"object_type":"K8S_APPLICATION"
},
{
"operation":"rollback",
"object_type":"K8S_APPLICATION"
},
{
"operation":"scale",
"object_type":"K8S_APPLICATION"
},
{
"operation":"setsnapback",
"object_type":"K8S_APPLICATION"
},
{
"operation":"snapshot",
"object_type":"K8S_APPLICATION"
},
{
"operation":"start",
"object_type":"K8S_APPLICATION"
},
{
"operation":"stop",
"object_type":"K8S_APPLICATION"
},
{
"operation":"unregister",
"object_type":"K8S_APPLICATION"
},
{
"operation":"update",
"object_type":"K8S_APPLICATION"
},
{
"operation":"view",
"object_type":"K8S_APPLICATION"
}
],
"tenant_roles":[
"superadmin",
"tenantadmin",
"user"
]
},
{
"capability_group":"Application",
"id":28,
"description":"Share Application Backups",
"providers":[
"ViewApplications",
"ViewK8sApplications"
],
"hidden":false,
"name":"ShareK8sApplications",
"capability_entries":[
{
"operation":"share",
"object_type":"K8S_APPLICATION"
},
{
"operation":"unshare",
"object_type":"K8S_APPLICATION"
}
],
"tenant_roles":[
"superadmin",
"tenantadmin"
]
},
{
"capability_group":"Application",
"id":30,
"description":"Manage K8s Application Backups",
"providers":[
"ViewK8sBackups"
],
"hidden":false,
"name":"ManageK8sBackups",
"capability_entries":[
{
"operation":"create",
"object_type":"K8S_BACKUP"
},
{
"operation":"delete",
"object_type":"K8S_BACKUP"
},
{
"operation":"share",
"object_type":"K8S_BACKUP"
},
{
"operation":"tenant_share",
"object_type":"K8S_BACKUP"
},
{
"operation":"tenant_unshare",
"object_type":"K8S_BACKUP"
},
{
"operation":"unshare",
"object_type":"K8S_BACKUP"
},
{
"operation":"update",
"object_type":"K8S_BACKUP"
},
{
"operation":"user_share",
"object_type":"K8S_BACKUP"
},
{
"operation":"user_unshare",
"object_type":"K8S_BACKUP"
}
],
"tenant_roles":[
"superadmin"
]
},
{
"capability_group":"Application",
"id":32,
"description":"Create Application Images",
"providers":[
"ViewImages"
],
"hidden":false,
"name":"CreateImages",
"capability_entries":[
{
"operation":"create",
"object_type":"IMAGE"
},
{
"operation":"delete",
"object_type":"IMAGE"
},
{
"operation":"rename",
"object_type":"IMAGE"
},
{
"operation":"update",
"object_type":"IMAGE"
}
],
"tenant_roles":[
"superadmin",
"tenantadmin",
"user"
]
},
{
"capability_group":"Application",
"id":34,
"description":"Create Application Bundles",
"providers":[
"ViewImages",
"ViewBundles"
],
"hidden":false,
"name":"CreateBundles",
"capability_entries":[
{
"operation":"create",
"object_type":"BUNDLE"
},
{
"operation":"delete",
"object_type":"BUNDLE"
},
{
"operation":"rename",
"object_type":"BUNDLE"
},
{
"operation":"update",
"object_type":"BUNDLE"
}
],
"tenant_roles":[
"superadmin",
"tenantadmin",
"user"
]
},
{
"capability_group":"Application",
"id":36,
"description":"Manage Application Instances",
"providers":[
"ViewInstances"
],
"hidden":false,
"name":"ManageInstances",
"capability_entries":[
{
"operation":"manage_instances",
"object_type":"APPLICATION"
},
{
"operation":"addvol",
"object_type":"INSTANCE"
},
{
"operation":"computeqos",
"object_type":"INSTANCE"
},
{
"operation":"delete",
"object_type":"INSTANCE"
},
{
"operation":"relocate",
"object_type":"INSTANCE"
},
{
"operation":"repair",
"object_type":"INSTANCE"
},
{
"operation":"restart",
"object_type":"INSTANCE"
},
{
"operation":"setstate",
"object_type":"INSTANCE"
},
{
"operation":"start",
"object_type":"INSTANCE"
},
{
"operation":"stop",
"object_type":"INSTANCE"
},
{
"operation":"update",
"object_type":"INSTANCE"
},
{
"operation":"upgrade",
"object_type":"INSTANCE"
}
],
"tenant_roles":[
"superadmin",
"tenantadmin",
"user"
]
},
{
"capability_group":"Application",
"id":38,
"description":"Manage Storage Volumes",
"providers":[
"ViewVolumes"
],
"hidden":false,
"name":"ManageVolumes",
"capability_entries":[
{
"operation":"create",
"object_type":"VOLUME"
},
{
"operation":"delete",
"object_type":"VOLUME"
},
{
"operation":"update",
"object_type":"VOLUME"
}
],
"tenant_roles":[
"superadmin"
]
},
{
"capability_group":"Application",
"id":40,
"description":"Manage Docker Registries",
"providers":[
"ViewDocker"
],
"hidden":false,
"name":"ManageDocker",
"capability_entries":[
{
"operation":"create",
"object_type":"DOCKER_REGISTRY"
},
{
"operation":"delete",
"object_type":"DOCKER_REGISTRY"
},
{
"operation":"update",
"object_type":"DOCKER_REGISTRY"
}
],
"tenant_roles":[
"superadmin",
"tenantadmin"
]
},
{
"capability_group":"Infrastructure",
"id":42,
"description":"Manage Networking",
"providers":[
"ViewNetworking"
],
"hidden":false,
"name":"ManageNetworking",
"capability_entries":[
{
"operation":"create",
"object_type":"IPPOOL"
},
{
"operation":"delete",
"object_type":"IPPOOL"
},
{
"operation":"update",
"object_type":"IPPOOL"
},
{
"operation":"create",
"object_type":"VLAN"
},
{
"operation":"delete",
"object_type":"VLAN"
},
{
"operation":"update",
"object_type":"VLAN"
}
],
"tenant_roles":[
"superadmin"
]
},
{
"capability_group":"Infrastructure",
"id":44,
"description":"Manage Resource Pools",
"providers":[
"ViewResourcePools"
],
"hidden":false,
"name":"ManageResourcePools",
"capability_entries":[
{
"operation":"create",
"object_type":"RESOURCEPOOL"
},
{
"operation":"delete",
"object_type":"RESOURCEPOOL"
},
{
"operation":"update",
"object_type":"RESOURCEPOOL"
}
],
"tenant_roles":[
"superadmin"
]
},
{
"capability_group":"Infrastructure",
"id":46,
"description":"Manage Tags",
"providers":[
"ViewTags"
],
"hidden":false,
"name":"ManageTags",
"capability_entries":[
{
"operation":"create",
"object_type":"TAG"
},
{
"operation":"delete",
"object_type":"TAG"
},
{
"operation":"update",
"object_type":"TAG"
}
],
"tenant_roles":[
"superadmin"
]
},
{
"capability_group":"Infrastructure",
"id":48,
"description":"Manage Resource groups",
"providers":[
"ViewResourceGroups"
],
"hidden":false,
"name":"ManageResourceGroups",
"capability_entries":[
{
"operation":"create",
"object_type":"RESOURCE_GROUP"
},
{
"operation":"delete",
"object_type":"RESOURCE_GROUP"
},
{
"operation":"update",
"object_type":"RESOURCE_GROUP"
}
],
"tenant_roles":[
"superadmin",
"tenantadmin"
]
},
{
"capability_group":"Infrastructure",
"id":51,
"description":"Manage Configuration Information",
"providers":[
"ViewConfig"
],
"hidden":false,
"name":"ManageConfig",
"capability_entries":[
{
"operation":"update",
"object_type":"CONFIG"
}
],
"tenant_roles":[
"superadmin"
]
},
{
"capability_group":"Infrastructure",
"id":52,
"description":"Access a physical node's console",
"providers":[
"ViewNodes"
],
"hidden":false,
"name":"AccessConsole",
"capability_entries":[
{
"operation":"view",
"object_type":"CONSOLE"
}
],
"tenant_roles":[
"superadmin",
"tenantadmin"
]
},
{
"capability_group":"Infrastructure",
"id":53,
"description":"Access a cluster's dashboard",
"providers":[
"ViewApplications",
"ViewBackups",
"ViewConfig",
"ViewNodes",
"ViewEvents"
],
"hidden":false,
"name":"AccessDashboard",
"capability_entries":[
{
"operation":"view",
"object_type":"DASHBOARD"
}
],
"tenant_roles":[
"superadmin",
"tenantadmin"
]
},
{
"capability_group":"Infrastructure",
"id":55,
"description":"Manage Log Collection Information",
"providers":[
"ViewLogCollections",
"ViewJobs"
],
"hidden":false,
"name":"ManageLogCollections",
"capability_entries":[
{
"operation":"create",
"object_type":"LOG_COLLECT"
},
{
"operation":"delete",
"object_type":"LOG_COLLECT"
},
{
"operation":"update",
"object_type":"LOG_COLLECT"
}
],
"tenant_roles":[
"superadmin"
]
},
{
"capability_group":"Infrastructure",
"id":57,
"description":"Manage File Collection Information",
"providers":[
"ViewFileCollections"
],
"hidden":false,
"name":"ManageFileCollections",
"capability_entries":[
{
"operation":"create",
"object_type":"FILE_COLLECTION"
},
{
"operation":"delete",
"object_type":"FILE_COLLECTION"
},
{
"operation":"update",
"object_type":"FILE_COLLECTION"
}
],
"tenant_roles":[
"superadmin"
]
},
{
"capability_group":"Infrastructure",
"id":59,
"description":"Manage Physical Nodes",
"providers":[
"ViewApplications",
"ViewNodes"
],
"hidden":false,
"name":"ManageNodes",
"capability_entries":[
{
"operation":"create",
"object_type":"NODE"
},
{
"operation":"delete",
"object_type":"NODE"
},
{
"operation":"pruneimage",
"object_type":"NODE"
},
{
"operation":"update",
"object_type":"NODE"
}
],
"tenant_roles":[
"superadmin"
]
},
{
"capability_group":"Infrastructure",
"id":61,
"description":"Manage System Events and Alerts",
"providers":[
"ViewEvents"
],
"hidden":false,
"name":"ManageEvents",
"capability_entries":[
{
"operation":"create",
"object_type":"EVENT"
},
{
"operation":"delete",
"object_type":"EVENT"
},
{
"operation":"update",
"object_type":"EVENT"
}
],
"tenant_roles":[
"superadmin"
]
},
{
"capability_group":"Infrastructure",
"id":63,
"description":"Manage Jobs",
"providers":[
"ViewJobs"
],
"hidden":false,
"name":"ManageJobs",
"capability_entries":[
{
"operation":"delete",
"object_type":"JOB"
},
{
"operation":"update",
"object_type":"JOB"
}
],
"tenant_roles":[
"superadmin"
]
},
{
"capability_group":"Infrastructure",
"id":65,
"description":"Manage Zones",
"providers":[
"ViewZones"
],
"hidden":false,
"name":"ManageZones",
"capability_entries":[
{
"operation":"create",
"object_type":"ZONE"
},
{
"operation":"delete",
"object_type":"ZONE"
},
{
"operation":"update",
"object_type":"ZONE"
}
],
"tenant_roles":[
"superadmin"
]
},
{
"capability_group":"Infrastructure",
"id":67,
"description":"Manage Workflows",
"providers":[
"ViewWorkflow"
],
"hidden":false,
"name":"ManageWorkflow",
"capability_entries":[
{
"operation":"create",
"object_type":"WORKFLOW"
},
{
"operation":"delete",
"object_type":"WORKFLOW"
},
{
"operation":"update",
"object_type":"WORKFLOW"
}
],
"tenant_roles":[
"superadmin",
"tenantadmin"
]
},
{
"capability_group":"Infrastructure",
"id":71,
"description":"Create Storage Repos",
"providers":[
"ViewStorageRepos"
],
"hidden":false,
"name":"CreateStorageRepos",
"capability_entries":[
{
"operation":"create",
"object_type":"REPO_CATALOG"
},
{
"operation":"delete",
"object_type":"REPO_CATALOG"
},
{
"operation":"create",
"object_type":"STORAGE_REPO"
},
{
"operation":"delete",
"object_type":"STORAGE_REPO"
}
],
"tenant_roles":[
"superadmin",
"tenantadmin",
"user"
]
},
{
"capability_group":"Infrastructure",
"id":72,
"description":"Use Storage Repos",
"providers":[
"ViewStorageRepos"
],
"hidden":false,
"name":"UseStorageRepos",
"capability_entries":[
{
"operation":"push",
"object_type":"STORAGE_REPO"
}
],
"tenant_roles":[
"superadmin",
"tenantadmin",
"user"
]
},
{
"capability_group":"Infrastructure",
"id":73,
"description":"Manage Storage Repos",
"providers":[
"ViewStorageRepos",
"UseStorageRepos"
],
"hidden":false,
"name":"ManageStorageRepos",
"capability_entries":[
{
"operation":"update",
"object_type":"REPO_CATALOG"
},
{
"operation":"purge",
"object_type":"STORAGE_REPO"
},
{
"operation":"reclaim",
"object_type":"STORAGE_REPO"
},
{
"operation":"scan",
"object_type":"STORAGE_REPO"
},
{
"operation":"update",
"object_type":"STORAGE_REPO"
}
],
"tenant_roles":[
"superadmin",
"tenantadmin",
"user"
]
},
{
"capability_group":"Application",
"id":74,
"description":"Share Storage Repos with tenants",
"providers":[
"ViewStorageRepos",
"UseStorageRepos"
],
"hidden":false,
"name":"TenantShareRepos",
"capability_entries":[
{
"operation":"tenant_share",
"object_type":"STORAGE_REPO"
},
{
"operation":"tenant_unshare",
"object_type":"STORAGE_REPO"
}
],
"tenant_roles":[
"superadmin"
]
},
{
"capability_group":"Application",
"id":75,
"description":"Share Storage Repos with tenant users",
"providers":[
"ViewStorageRepos",
"UseStorageRepos"
],
"hidden":false,
"name":"UserShareRepos",
"capability_entries":[
{
"operation":"user_share",
"object_type":"STORAGE_REPO"
},
{
"operation":"user_unshare",
"object_type":"STORAGE_REPO"
}
],
"tenant_roles":[
"superadmin",
"tenantadmin"
]
},
{
"capability_group":"Infrastructure",
"id":77,
"description":"Manage NFS exports",
"providers":[
"ViewNFSExports"
],
"hidden":false,
"name":"ManageNFSExports",
"capability_entries":[
{
"operation":"create",
"object_type":"NFS_EXPORTS"
},
{
"operation":"delete",
"object_type":"NFS_EXPORTS"
},
{
"operation":"update",
"object_type":"NFS_EXPORTS"
}
],
"tenant_roles":[
"superadmin"
]
},
{
"capability_group":"Infrastructure",
"id":78,
"description":"Generate reports",
"providers":[
],
"hidden":false,
"name":"GenerateReports",
"capability_entries":[
{
"operation":"view",
"object_type":"REPORT"
}
],
"tenant_roles":[
"superadmin"
]
},
{
"capability_group":"Infrastructure",
"id":79,
"description":"Share various objects with tenants",
"providers":[
],
"hidden":false,
"name":"ShareObjectsWithTenants",
"capability_entries":[
{
"operation":"tenant_share",
"object_type":"BUNDLE"
},
{
"operation":"tenant_share",
"object_type":"DOCKER_REGISTRY"
},
{
"operation":"tenant_share",
"object_type":"IMAGE"
}
],
"tenant_roles":[
"superadmin"
]
},
{
"capability_group":"Infrastructure",
"id":80,
"description":"Change the owner for various objects",
"providers":[
],
"hidden":false,
"name":"ChangeOwner",
"capability_entries":[
{
"operation":"change_owner",
"object_type":"APPLICATION"
},
{
"operation":"change_owner",
"object_type":"BUNDLE"
},
{
"operation":"change_owner",
"object_type":"DOCKER_REGISTRY"
},
{
"operation":"change_owner",
"object_type":"IMAGE"
},
{
"operation":"change_owner",
"object_type":"INSTANCE"
},
{
"operation":"change_owner",
"object_type":"K8S_APPLICATION"
},
{
"operation":"change_owner",
"object_type":"NAMESPACE"
}
],
"tenant_roles":[
"superadmin",
"tenantadmin"
]
},
{
"capability_group":"Infrastructure",
"id":81,
"description":"Manage Tenants, Tenant users and their properties",
"providers":[
],
"hidden":false,
"name":"ManageTenantResources",
"capability_entries":[
{
"operation":"manage_resources",
"object_type":"TENANT"
}
],
"tenant_roles":[
"superadmin"
]
},
{
"capability_group":"User",
"id":83,
"description":"Manage Users and their properties",
"providers":[
"ViewUsers",
"ManageUserCapabilities"
],
"hidden":false,
"name":"ManageUsers",
"capability_entries":[
{
"operation":"create",
"object_type":"USER"
},
{
"operation":"delete",
"object_type":"USER"
},
{
"operation":"update",
"object_type":"USER"
}
],
"tenant_roles":[
"superadmin"
]
},
{
"capability_group":"User",
"id":85,
"description":"Update roles for users",
"providers":[
],
"hidden":false,
"name":"UpdateUserRole",
"capability_entries":[
{
"operation":"update_role",
"object_type":"USER"
}
],
"tenant_roles":[
"superadmin",
"tenantadmin"
]
},
{
"capability_group":"User",
"id":87,
"description":"Update Tenants, Tenant users and their properties",
"providers":[
"ViewUsers",
"ViewTenants"
],
"hidden":false,
"name":"UpdateTenants",
"capability_entries":[
{
"operation":"update",
"object_type":"TENANT"
}
],
"tenant_roles":[
"tenantadmin"
]
},
{
"capability_group":"User",
"id":88,
"description":"Manage Tenants, Tenant users and their properties",
"providers":[
"ViewUsers",
"ViewTenants"
],
"hidden":false,
"name":"ManageTenants",
"capability_entries":[
{
"operation":"add_users",
"object_type":"TENANT"
},
{
"operation":"create",
"object_type":"TENANT"
},
{
"operation":"delete",
"object_type":"TENANT"
},
{
"operation":"update",
"object_type":"TENANT"
}
],
"tenant_roles":[
"superadmin"
]
},
{
"capability_group":"User",
"id":90,
"description":"Manage User Capabilities and their properties",
"providers":[
"ViewUserCapabilities"
],
"hidden":false,
"name":"ManageUserCapabilities",
"capability_entries":[
],
"tenant_roles":[
"superadmin",
"tenantadmin"
]
},
{
"capability_group":"User",
"id":91,
"description":"Create, Update, and Delete User Capabilities",
"providers":[
"ManageUserCapabilities"
],
"hidden":false,
"name":"CreateUserCapabilities",
"capability_entries":[
{
"operation":"create",
"object_type":"USER_CAPABILITY"
},
{
"operation":"delete",
"object_type":"USER_CAPABILITY"
},
{
"operation":"update",
"object_type":"USER_CAPABILITY"
}
],
"tenant_roles":[
"superadmin"
]
},
{
"capability_group":"User",
"id":93,
"description":"Manage Tiller objects",
"providers":[
"ViewTiller"
],
"hidden":false,
"name":"ManageTiller",
"capability_entries":[
{
"operation":"create",
"object_type":"K8S_TILLER"
},
{
"operation":"delete",
"object_type":"K8S_TILLER"
},
{
"operation":"update",
"object_type":"K8S_TILLER"
}
],
"tenant_roles":[
"superadmin",
"tenantadmin"
]
},
{
"capability_group":"User",
"id":95,
"description":"Manage LDAP\/Active Directory services and their properties",
"providers":[
"ViewDirectoryServices"
],
"hidden":false,
"name":"ManageDirectoryServices",
"capability_entries":[
{
"operation":"create",
"object_type":"LDAP"
},
{
"operation":"delete",
"object_type":"LDAP"
},
{
"operation":"update",
"object_type":"LDAP"
}
],
"tenant_roles":[
"superadmin"
]
},
{
"capability_group":"User",
"id":97,
"description":"Manage OpenShift users\/groups and their properties",
"providers":[
"ViewOpenShift"
],
"hidden":false,
"name":"ManageOpenShift",
"capability_entries":[
{
"operation":"create",
"object_type":"OPEN_SHIFT"
},
{
"operation":"delete",
"object_type":"OPEN_SHIFT"
},
{
"operation":"update",
"object_type":"OPEN_SHIFT"
}
],
"tenant_roles":[
"superadmin"
]
},
{
"capability_group":"User",
"id":99,
"description":"Manage user audit properties",
"providers":[
"ViewUserAudit"
],
"hidden":false,
"name":"ManageUserAudit",
"capability_entries":[
{
"operation":"create",
"object_type":"USER_AUDIT"
},
{
"operation":"delete",
"object_type":"USER_AUDIT"
},
{
"operation":"update",
"object_type":"USER_AUDIT"
}
],
"tenant_roles":[
"superadmin"
]
},
{
"capability_group":"Infrastructure",
"id":102,
"description":"Manage Kubernetes resources",
"providers":[
"ViewK8s"
],
"hidden":false,
"name":"ManageK8s",
"capability_entries":[
{
"operation":"create",
"object_type":"K8S_MASTER"
},
{
"operation":"delete",
"object_type":"K8S_MASTER"
},
{
"operation":"update",
"object_type":"K8S_MASTER"
},
{
"operation":"update",
"object_type":"K8S_NODE"
}
],
"tenant_roles":[
"superadmin"
]
},
{
"capability_group":"Infrastructure",
"id":103,
"description":"Manage Kubernetes resources",
"providers":[
],
"hidden":false,
"name":"ManageK8sUsers",
"capability_entries":[
{
"operation":"create",
"object_type":"K8S_USER_CONTEXT"
},
{
"operation":"delete",
"object_type":"K8S_USER_CONTEXT"
},
{
"operation":"update",
"object_type":"K8S_USER_CONTEXT"
},
{
"operation":"view",
"object_type":"K8S_USER_CONTEXT"
}
],
"tenant_roles":[
"superadmin"
]
},
{
"capability_group":"Administration",
"id":106,
"description":"All Super Admin Capabilities",
"providers":[
"AllCapabilities"
],
"hidden":false,
"name":"AllSuperAdminCapabilities",
"capability_entries":[
],
"tenant_roles":[
]
},
{
"capability_group":"Administration",
"id":107,
"description":"All User Capabilities",
"providers":[
"CloneApplications",
"CreateApplications",
"ViewNamespaces",
"UseNamespaces",
"ManageNamespaces",
"ViewBackups",
"CreateBackups",
"DeleteBackups",
"PurgeBackups",
"ViewUserAuth",
"CreateBundles",
"CreateImages",
"CreatePrivelegedApps",
"CreateStorageRepos",
"DeleteApplications",
"DownloadFiles",
"ManageInstances",
"ManageK8sApplications",
"ManageStorageRepos",
"SnapshotApplications",
"BackupApplications",
"ViewApplications",
"ViewBundles",
"ViewChargeback",
"ViewConfig",
"ViewDocker",
"ViewEvents",
"ViewFileCollections",
"ViewImages",
"ViewInstances",
"ViewJobs",
"ViewK8sApplications",
"ViewK8sUserAuth",
"ViewNetworking",
"ViewNFSExports",
"ViewNodes",
"ViewResourceGroups",
"ViewResourcePools",
"ViewStorageArray",
"ViewStorageRepos",
"UseStorageRepos",
"ViewSystem",
"ViewTags",
"ViewTiller",
"ViewZones",
"ViewWorkflow"
],
"hidden":false,
"name":"AllUserCapabilities",
"capability_entries":[
],
"tenant_roles":[
]
},
{
"capability_group":"Administration",
"id":108,
"description":"All Cluster User Capabilities",
"providers":[
"ManageK8sApplications",
"ManageK8sBackups",
"ViewJobs",
"CreateStorageRepos",
"ManageStorageRepos",
"ViewTiller",
"ViewK8sUserAuth"
],
"hidden":false,
"name":"AllClusterUserCapabilities",
"capability_entries":[
],
"tenant_roles":[
]
},
{
"capability_group":"Administration",
"id":109,
"description":"All Cluster Admin Capabilities",
"providers":[
"AllCapabilities"
],
"hidden":false,
"name":"AllClusterAdminCapabilities",
"capability_entries":[
],
"tenant_roles":[
]
},
{
"capability_group":"Administration",
"id":110,
"description":"All Tenant Admin Capabilities",
"providers":[
"ViewObjectShares",
"AccessConsole",
"AccessDashboard",
"ChangeOwner",
"CloneApplications",
"CreateApplications",
"ViewNamespaces",
"UseNamespaces",
"ManageNamespaces",
"ShareNamespaces",
"ViewBackups",
"CreateBackups",
"DeleteBackups",
"ImportBackups",
"ExportBackups",
"PurgeBackups",
"UserShareBackups",
"CreateBundles",
"CreateImages",
"CreatePrivelegedApps",
"CreateStorageRepos",
"DeleteApplications",
"DownloadFiles",
"ManageApplications",
"ShareApplications",
"ManageApplicationResources",
"ManageDocker",
"ManageInstances",
"ManageK8s",
"ManageK8sApplications",
"ShareK8sApplications",
"ManageResourceGroups",
"ManageStorageRepos",
"UserShareRepos",
"ManageTiller",
"ManageUserCapabilities",
"SnapshotApplications",
"BackupApplications",
"UpdateTenants",
"UpdateUserRole",
"UseStorageRepos",
"ViewApplications",
"ViewBundles",
"ViewChargeback",
"ViewConfig",
"ViewDocker",
"ViewEvents",
"ViewFileCollections",
"ViewImages",
"ViewInstances",
"ViewJobs",
"ViewK8sApplications",
"ViewK8sUserAuth",
"ViewNetworking",
"ViewNFSExports",
"ViewNodes",
"ViewResourceGroups",
"ViewResourcePools",
"ViewStorageArray",
"ViewStorageRepos",
"ViewSystem",
"ViewTags",
"ViewTenants",
"ViewTiller",
"ViewUsers",
"ViewUserAuth",
"ViewUserCapabilities",
"ViewZones",
"ViewWorkflow",
"ManageWorkflow"
],
"hidden":false,
"name":"AllTenantAdminCapabilities",
"capability_entries":[
],
"tenant_roles":[
]
},
{
"capability_group":"Custom",
"id":115,
"description":"Custom user capability",
"providers":[
"ManageApplications"
],
"hidden":false,
"name":"CustomUserCapability",
"capability_entries":[
{
"operation":"backup",
"object_type":"APPLICATION"
},
{
"operation":"restore",
"object_type":"APPLICATION"
}
],
"tenant_roles":[
"user",
"tenantadmin",
"superadmin"
]
}
]
}
8.5.2. Add a custom user capability¶
Issue the following command to add a custom user capability:
# robin capabilities add <name> <description> <tenant_roles>
--providers <providers>
--capability-entries <capability_entries>
--hidden
|
Name of custom user capability |
|
Description of User Capability |
|
Comma separated list of Tenant Roles. One or more of ‘superadmin’, ‘tenantadmin’, ‘user’ is required. |
|
Optional comma separated list of provider user capabilities. |
|
Optional comma separated list of capability entries in the following format: ‘<object_type>:<operation>’. |
|
Hide a user capability when listing (default is not hidden). |
Note
At least one of --providers or --capability-entries options must be specified.
Example:
# robin capabilities add CustomUserCapability "Custom user capability" user --providers ManageApplications
Custom User Capability 'CustomUserCapability' successfully added
# robin capabilities list CustomUserCapability --full
Group | Name | Hidden | Description
-------+----------------------+--------+------------------------
Custom | CustomUserCapability | False | Custom user capability
Tenant Roles:
user
Providers:
ManageApplications
Capability Entries:
Adds a custom user capability.
End Point: /api/v3/robin_server/user-capabilities
Method: POST
URL Parameters: None
Data Parameters:
name: <capability_name>- This mandatory field within the payload specifies the name of the capability to be created.description: <description>- Utilizing this parameter within the payload results in the new capability’s description being set to the specified string.tenant_roles: <tenant_roles>- Utilizing this parameter within the payload by specifying a comma seperated list of values results in the tenant roles the capability is applicable to being set to the given values. Valid values include: ‘superadmin’, ‘tenantadmin’ and ‘user’.providers: <providers>- Utilizing this parameter within the payload by specifying a comma seperated list of providers results in the capability’s providers being set to the values provided.hidden: true- Utilizing this parameter within the payload results in the capability not being shown when capability listing is performed. The default value is False.capability_entries: <list_of_capabilities>- Utilizing this parameter within the payload by specifying a list of arrays, each in the form of [<object_type>, <operation>] results in the capability’s entries being set to the values provided.
Note
At least one of providers or capability_entries fields must be specified within the payload.
Port: RCM Port (default value is 29442)
Headers:
Authorization: <auth_token>: Authorization token to identify which user is sending the request. The token can be acquired from the login API.
Success Response Code: 200
Error Response Code: 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error), 400 (Invalid API Usage), 409 (Duplicate Resource Error)
Example Response:
Output
{
"message":"Custom User Capability 'CustomUserCapability' successfully added"
}
8.5.3. Remove a custom user capability¶
Issue the following command to remove a custom user capability:
# robin capabilities remove <name>
|
Name of custom user capability to remove |
Example:
# robin capabilities remove CustomUserCapability
Deleted User Capability 'CustomUserCapability'
Removes a custom user capability.
End Point: /api/v3/robin_server/user-capabilities/<capability_name>
Method: DELETE
URL Parameters: None
Data Parameters: None
Port: RCM Port (default value is 29442)
Headers:
Authorization: <auth_token>: Authorization token to identify which user is sending the request. The token can be acquired from the login API.
Success Response Code: 200
Error Response Code: 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error)
Example Response:
Output
{
"message":"Deleted User Capability 'CustomUserCapability'"
}
8.5.4. Update a custom user capability¶
Issue the following command to update a custom user capability:
# robin capabilities update <name>
--description <description>
--tenant-roles <tenant_roles>
--providers <providers>
--capability-entries <capability_entries>
--hide
--expose
|
Name of custom user capability to update |
|
Description of User Capability |
|
A comma separated list of Tenant Roles. One or more of ‘superadmin’, ‘tenantadmin’, ‘user’ is required. |
|
Optional comma separated list of provider user capabilities. |
|
Optional comma separated list of capability entries in the following format: ‘<object_type>:<operation>’. |
|
Hide user capability when listing. |
|
Include user capability when listing. |
Example:
# robin capabilities update CustomUserCapability --capability-entries APPLICATION:backup,APPLICATION:restore --tenant-roles user,tenantadmin,superadmin
User Capability 'CustomUserCapability' has been updated
# robin capabilities list CustomUserCapability --full
Group | Name | Hidden | Description
-------+----------------------+--------+------------------------
Custom | CustomUserCapability | False | Custom user capability
Tenant Roles:
user
tenantadmin
superadmin
Providers:
ManageApplications
Capability Entries:
APPLICATION backup
APPLICATION restore
Note
When updating a custom user capability, the values provided for
providers and capability entries will replace the current
values. To add or remove one or more providers or capability
entries, use the add-capability-entries,
remove-capability-entries, add-providers, or
remove-providers sub-commands.
Updates a custom user capability.
End Point: /api/v3/robin_server/user-capabilities
Method: PUT
URL Parameters: None
Data Parameters:
action: update- This mandatory field within the payload specifies that the update operation is to be performed.name: <capability_name>- This mandatory field within the payload specifies the name of the capability to be updated.description: <description>- Utilizing this parameter within the payload by specifying a description results in the capability’s description being changed to the given string.tenant_roles: <tenant_roles>- Utilizing this parameter within the payload by specifying a comma seperated list of values results in the tenant roles the capability is applicable to being updated to the given list. Valid values include: ‘superadmin’, ‘tenantadmin’ and ‘user’.providers: <providers>- Utilizing this parameter within the payload by specifying a comma seperated list of providers results in the capability’s providers being set to the values provided.hidden: [true|false]- Utilizing this parameter within the payload determines whether or not the capability is shown when doing a capability listing.capability_entries: <list_of_dicts>– Utilizing this parameter within the payload by specifying a comma seperated list of dictionaries (with the keys given below) results in the capability’s entries being set to the values provided.object_type: <object_type>- This mandatory field within each dictionary specifies the object type the capability entry refers to.operation: <operation>- This mandatory field within each dictionary specifies the operation that applies to the object type specified previously.
Note
When updating a custom user capability, if values for providers and capability entries are provided they will replace the current values.
Port: RCM Port (default value is 29442)
Headers:
Authorization: <auth_token>: Authorization token to identify which user is sending the request. The token can be acquired from the login API.
Success Response Code: 200
Error Response Code: 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error)
Example Response:
Output
{
"message":"User Capability 'CustomUserCapability' has been updated"
}
8.5.5. Add capability entries to a custom user capability¶
Issue the following command to add one or more capability entries (permissions) to a custom user capability:
# robin capabilities add-capability-entries <name> <capability_entries>
|
Name of custom user capability to edit |
|
Comma separated list of capability entries in the following format: ‘<object_type>:<operation>’. |
Example:
# robin capabilities add-capability-entries CustomUserCapability BUNDLE:view,BUNDLE:create,BUNDLE:delete
One or more Capability Entries for User Capability 'CustomUserCapability' have been added
Adds additional capability entries to a custom user capability.
End Point: /api/v3/robin_server/user-capabilities
Method: PUT
URL Parameters: None
Data Parameters:
action: add_capability_entries- This mandatory field within the payload specifies that capability entries will be added.name: <capability_name>- This mandatory field within the payload specifies the name of the capability to be edited.capability_entries: <list_of_dicts>–object_type: <object_type>- This mandatory field within each dictionary specifies the object type the new capability entry refers to.operation: <operation>- This mandatory field within each dictionary specifies the operation that applies to the object type specified previously.
Port: RCM Port (default value is 29442)
Headers:
Authorization: <auth_token>: Authorization token to identify which user is sending the request. The token can be acquired from the login API.
Success Response Code: 200
Error Response Code: 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error)
Example Response:
Output
{
"message":"One or more Capability Entries for User Capability 'CustomUserCapability' have been added"
}
8.5.6. Remove capability entries from a custom user capability¶
Issue the following command to remove one or more capability entries (permissions) from a custom user capability:
# robin capabilities remove-capability-entries <name> <capability_entries>
|
Name of custom user capability to edit |
|
Comma separated list of capability entries in the following format: ‘<object_type>:<operation>’. |
Example:
# robin capabilities remove-capability-entries CustomUserCapability BUNDLE:view,BUNDLE:create,BUNDLE:delete
One or more Capability Entries for User Capability 'CustomUserCapability' have been removed
Removes capability entries from a custom user capability.
End Point: /api/v3/robin_server/user-capabilities
Method: PUT
URL Parameters: None
Data Parameters:
action: remove_capability_entries- This mandatory field within the payload specifies that capability entries will be removed.name: <capability_name>- This mandatory field within the payload specifies the name of the capability to be edited.capability_entries: <list_of_dicts>–object_type: <object_type>- This mandatory field within each dictionary specifies the object type the capability entry refers to.operation: <operation>- This mandatory field within each dictionary specifies the operation that applies to the aforementioned object type.
Port: RCM Port (default value is 29442)
Headers:
Authorization: <auth_token>: Authorization token to identify which user is sending the request. The token can be acquired from the login API.
Success Response Code: 200
Error Response Code: 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error), 400 (Invalid API Usage Error)
Example Response:
Output
{
"message":"One or more Capability Entries for User Capability 'CustomUserCapability' have been removed"
}
8.5.7. Add providers to a custom user capability¶
Issue the following command to add one or providers to a custom user capability:
# robin capabilities add-providers <name> <providers>
|
Name of custom user capability to edit |
|
Comma separated list of user capability providers to add |
Example:
# robin capabilities add-providers CustomUserCapability CreateImages,CreateBundles
One or more Providers for User Capability 'CustomUserCapability' have been added
# robin capabilities list --full CustomUserCapability
Group | Name | Hidden | Description
-------+----------------------+--------+------------------------
Custom | CustomUserCapability | False | Custom user capability
Tenant Roles:
user
tenantadmin
superadmin
Providers:
ManageApplications
CreateImages
CreateBundles
Capability Entries:
APPLICATION backup
APPLICATION restore
Adds additional provider(s) to a custom user capability.
End Point: /api/v3/robin_server/user-capabilities
Method: PUT
URL Parameters: None
Data Parameters:
action: add_providers- This mandatory field within the payload specifies that the add providers operation is to be performed.name: <capability_name>- This mandatory field within the payload specifies the name of the capability to be edited.providers: <list_of_providers>- This mandatory field within the payload specifies a comma seperated list of provider names that should be added to the capability.
Port: RCM Port (default value is 29442)
Headers:
Authorization: <auth_token>: Authorization token to identify which user is sending the request. The token can be acquired from the login API.
Success Response Code: 200
Error Response Code: 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error)
Example Response:
Output
{
"message":"One or more Providers for User Capability 'CustomUserCapability' have been added"
}
8.5.8. Remove providers from a custom user capability¶
Issue the following command to remove one or providers from a custom user capability:
# robin capabilities remove-providers <name> <providers>
|
Name of custom user capability to edit |
|
Comma separated list of user capability providers to add |
Example:
# robin capabilities remove-providers CustomUserCapability CreateImages,CreateBundles
One or more Providers for User Capability 'CustomUserCapability' have been removed
Removes provider(s) from a custom user capability.
End Point: /api/v3/robin_server/user-capabilities
Method: PUT
URL Parameters: None
Data Parameters:
action: remove_providers- This mandatory field within the payload specifies that the remove providers operation is to be performed.name: <capability_name>- This mandatory field within the payload specifies the name of the capability to be edited.providers: <list_of_providers>- This mandatory field within the payload specifies a comma seperated list of provider names that should be removed from the capability.
Port: RCM Port (default value is 29442)
Headers:
Authorization: <auth_token>: Authorization token to identify which user is sending the request. The token can be acquired from the login API.
Success Response Code: 200
Error Response Code: 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error)
Example Response:
Output
{
"message":"One or more Providers for User Capability 'CustomUserCapability' have been removed"
}
8.5.9. Superadmin with limited capabilities¶
A superadmin with limited capabilities is a default superadmin user type without some user capabilities.
You can create a superadmin user with limited capabilities if you need the superadmin user with most of the superadmin capabilities but want to limit the capabilities to perform actions that elevate their permissions or affect critical system resources. When you have such scenarios, you can create a superadmin user and restrict the user with the following capabilities.
Note
These user capabilities are by default enabled for the superadmin user. You must disable these capabilities if you need to create a superadmin user without these capabilities.
You can create a superadmin user with limited capabilities by disabling the following user capabilities:
ManageUserCapabilities:When this capability is disabled, the user cannot create, edit, or delete custom user capabilities.
ManageAdministratorsTenant:When this capability is disabled, the user cannot manage resources and users in the Administrators tenant.
AddSelfToTenants:When this capability is disabled, the user cannot add oneself as a member of other tenants in the cluster.
8.6. Object sharing operations¶
8.7. User management operations¶
8.7.1. Add a user¶
To add a new user to the Robin Platform cluster, issue the following command:
# robin user add <username> <tenant> <tenant_role> [<user_capabilities>]
--password <password>
--openshift
--ldap
--ldap-server <ldap_server>
--ldap-user-dn <ldap_user_dn>
--first-name <first_name>
--last-name <last_name>
--email <email_address>
--namespace <namespace>
--import-namespace
|
The user’s Robin Platform cluster username. Note that this username can only contain .-_ and alphanumeric characters |
|
Name of the tenant to add the user to |
|
Role to assign to the user (superadmin, tenantadmin, user) |
|
Optional comma-separated list of tenant specific capabilities to assign to the user. Note that if no capabilities are specified, then full capabilities for the specified role will be assigned. If no capabilities need to be granted to the user, then specify ‘NoCapabilities’ on the command line |
|
User password (for testing only) |
|
Authentication with the OpenShift auth provider |
|
Authentication with an LDAP server |
|
Name of LDAP server user will get authentication from |
|
The LDAP DN to use when authenticating the user (if the user is in a non-standard location in the tree or does not conform to normal user DN conventions) |
|
First name for user being added |
|
Last name for user being added |
|
Email address for user being added |
|
The primary namespace to assign to a user when adding them to a tenant. If no namespace is supplied for the user, then one will be created and assigned to them. If the namespace does not already exist, it will be created. If the namespace is already bound to the tenant, then its ownership will be transferred to the newly added user (along with any applications that have been deployed in this namespace) |
|
Import the specified Kubernetes namespace if it exists |
Note
To view a list of all user capabilities review the section detailed here.
Example 1 (Add a user to a tenant):
# robin user add user2 t1 user
Password: <user_password>
Retype password: <user_password>
Successfully added user 'user2'
Example 2 (Add a user and assign them a custom primary namespace name):
# robin user add user5 t3 user --namespace user5-ns
Password:
Retype password:
Successfully added user 'user5'
# robin user list user5
ID | Username | Full Name | Email | Tenants | Current Tenant | Current Role | Current Namespace | Authentication
---+----------+-----------+-------+---------+----------------+--------------+-------------------+----------------
10 | user5 | | | t3 | t3 | user | user5-ns | local
Note
The ability to add users is subject to Role Based Access Control (RBAC). By default, only Cluster Administrators (users having the superadmin role) have permission to do this.
Adds a new user to the Robin Platform cluster.
End Point: /api/v3/robin_server/users
Method: POST
URL Parameters: None
Data Parameters:
user_info: <dict_of_key_value_pairs>–username: <username>- This mandatory field within the dictionary specifies the name of the user to be created.authentication_type: <auth_type>- This mandatory field within the dictionary specifies the authentication provider for the user creation. Valid values include: 1 (Robin), 2 (LDAP), 3 (OpenShift).password: <password>- Utilizing this parameter within the dictionary by specifying a password string results in the aforementioned value being set as the user’s password. Note this parameter is mandatory when Robin is the authorization provider.first_name: <first_name>- Utilizing this parameter within the dictionary by specifying a first name results in the aforementioned string being set as the user’s first name.last_name: <last_name>- Utilizing this parameter within the dictionary by specifying a last name results in the aforementioned string being set as the user’s last name.email: <email>- Utilizing this parameter within the dictionary by specifying an email results in the aforementioned string being set as user’s email.setup_tiller: true- Utilizing this parameter results in all the Kubernetes objects needed for Helm2 application deployment being setup upon user addition. The default value is False.ldap_server: <ldap_server>- Utilizing this parameter results in the specified server being used as the LDAP server the created user will get authentication from. Note this parameter is mandatory when the authentication type is LDAP and only applies in this case too.ldap_user_dn: <ldap_user_dn>- Utilizing this parameter results in the specified DN being used as the LDAP DN to use when authenticating the user. Note this parameter only applies when the authentication type is LDAP.tenant_list: <dict_of_tenant_values>–tenant: <tenant_name>- This mandatory field within the dictionary specifies the name of the tenant the newly created user will be added to.tenant_role: <role_name>- This mandatory field within the dictionary specifies the role of the newly created user within the specified tenant. Valid values include: ‘superadmin’, ‘tenantadmin’, and ‘user’.user_capabilities: <list_of_capabilities>- Utilizing this parameter, by specifying a comma separated list of capabilities, results in the aforementioned capabilities being assigned to the newly created user. Note that if no capabilities are specified, then full capabilities for the specified role will be assigned. If no capabilities need to be granted to the user, then specify a list containing ‘NoCapabilities’.namespace_name: <namespace_name>- Utilizing this parameter, by specifying a namespace name, results in the respective namespace being assigned as the primary namespace for the newly created user. If no namespace is supplied for the user, then one will be created and assigned to them. If the namespace does not already exist, it will be created. If the namespace is already bound to the tenant, then its ownership will be transferred to the newly added user (along with any applications that have been deployed in this namespace).import_namespace: true- Utilizing this parameter results in the specified namespace being imported if it exists.
Note
To view a list of all user capabilities review the section detailed here.
Port: RCM Port (default value is 29442)
Headers:
Authorization: <auth_token>: Authorization token to identify which user is sending the request. The token can be acquired from the login API.
Success Response Code: 200
Error Response Code: 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error), 400 (Invalid API Usage Error), 409 (Duplicate Resource Error)
Example Response:
Output
{
"message":"Successfully added user 'user1'\n"
}
8.7.2. Update a user¶
To update a Robin Platform user’s attributes, issue the following command:
# robin user update <username>
--password, -p
--first-name <first_name>
--last-name <last_name>
--email <email_address>
|
The username for the Robin Platform user to update attributes for |
|
Change a user’s password |
|
First name for user being added |
|
Last name for user being added |
|
Email address for user being added |
Example:
# robin user update u1 --first-name demo-user
Successfully updated user u1
Note
The ability to update users is subject to Role Based Access Control (RBAC). By default, only Cluster Administrators (users having the superadmin role) have permission to do so.
Updates a Robin Platform user’s attributes.
End Point: /api/v3/robin_server/users/<username>
Method: PUT
URL Parameters: None
Data Parameters:
action: update- This mandatory field within the payload specifies that the update operation is to be performed.user_info: <dict_of_key_value_pairs>–password: <password>- Utilizing this parameter within the dictionary by specifying a new password results in the user’s password being changed to the given value.first_name: <first_name>- Utilizing this parameter within the dictionary by specifying a first name results in the user’s first name being changed to the given value.last_name: <last_name>- Utilizing this parameter within the dictionary by specifying a last name results in the user’s last name being changed to the given value.email: <email>- Utilizing this parameter within the dictionary by specifying an email results in the user’s email being changed to the given value.
Port: RCM Port (default value is 29442)
Headers:
Authorization: <auth_token>: Authorization token to identify which user is sending the request. The token can be acquired from the login API.
Success Response Code: 200
Error Response Code: 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error), 400 (Invalid API Usage Error)
Example Response:
Output
{
"message":"Successfully updated user robin\n"
}
8.7.3. Remove a user¶
To remove a Robin Platform user, issue the following command:
# robin user remove <username> [<replacement_users>]
--keep-k8s-namespaces
--yes, -y
|
Comma separated list of usernames for users being removed (can be a single username as well) |
|
Comma separated list of replacement users. Each replacement user consists of two elements, ‘tenant’ and ‘replacement_user’, in the following format <tenant>:<replacement_user>. Ownership of all namespaces and apps owned by a user being removed from a tenant will be assigned to the replacement user for that tenant (if supplied) |
|
Don’t delete a user’s Kubernetes namespaces when removing them |
|
Do not prompt for confirmation |
Example 1 (Remove a user):
# robin user remove user2
Are you sure you want to delete [y/n] ? y
Deleted user user2.
Example 2 (Remove a user and reassign ownership of their primary namespace to another user):
# robin user list user5
ID | Username | Full Name | Email | Tenants | Current Tenant | Current Role | Current Namespace | Authentication
---+----------+-----------+-------+---------+----------------+--------------+-------------------+----------------
10 | user5 | | | t3 | t3 | user | user5-ns | local
# robin user remove user5 t3:admin3 -y
Deleted user user5.
# robin namespace list --tenant t3
+--------------+--------------+-------------------+
| Name | Owner/Tenant | Primary Namespace |
+--------------+--------------+-------------------+
| t004-u000011 | admin3/t3 | True |
| user5-ns | admin3/t3 | False |
+--------------+--------------+-------------------+
Example 3: Remove a user and leave their Kubernetes namespaces in place
# robin namespace list --username user6
+-------------+--------------+-------------------+
| Name | Owner/Tenant | Primary Namespace |
+-------------+--------------+-------------------+
| user6-t3-ns | user6/t3 | True |
+-------------+--------------+-------------------+
# robin user remove user6 --keep-k8s-namespaces -y
Deleted user user6.
# kubectl get namespace user6-t3-ns
NAME STATUS AGE
user6-t2-ns Active 89m
Note
The ability to remove users is subject to Role Based Access Control (RBAC). By default, only Cluster Administrators (users having the superadmin role) have permission to do so.
The last local user assigned the superadmin role cannot be removed from the system.
Removes a Robin Platform user.
End Point: /api/v3/robin_server/users
Method: DELETE
URL Parameters: None
Data Parameters:
username: <username>- This mandatory field within the payload specifies the name of ther user to be deleted.delete_namespaces: false- Utilizing this paremeter within the payload results in the user’s Kubernetes namespace not being deleted even when they are removed. The default value is True.replacement_users: <list_of_dicts>–tenant: <tenant_name>- This mandatory field within the dictionary specifies the tenant in which to replace the user being removed. Note they have to be part of this tenant already.replacement_user: <replacement_username>- This mandatory field within the dictionary specifies the username of the user to replace the one being removed within the aforementioned tenant.
Note
The replacement_users field is not mandatory.
Port: RCM Port (default value is 29442)
Headers:
Authorization: <auth_token>: Authorization token to identify which user is sending the request. The token can be acquired from the login API.
Success Response Code: 200
Error Response Code: 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error), 400 (Invalid API Usage Error)
Example Response:
Output
{
"message":"Deleted user user2.\n\n"
}
8.7.4. List users¶
To list information about Robin Platform users, issue the following command:
# robin user list [<username>]
--all, -a
--full
--permissions
|
The username of the Robin Platform user to display information for |
|
List all users including hidden, disabled, and deleted users |
|
Display additional information about each user (e.g., access permissions) |
|
List individual user permissions |
Example:
# robin user list
ID | Username | Full Name | Email | Tenants | Current Tenant | Current Role | Current Namespace | Authentication
---+----------+---------------+-------+----------------+----------------+--------------+-------------------+----------------
3 | robin | Robin Systems | | Administrators | Administrators | superadmin | t001-u000003 | local
4 | admin1 | | | t1 | t1 | tenantadmin | t003-u000004 | local
5 | user1 | | | t1 | t1 | user | t003-u000005 | local
6 | user2 | | | t1 | t1 | user | t003-u000006 | local
Note
The ability to list users is subject to Role Based Access Control (RBAC). By default, only Cluster Administrators (users having the superadmin role) have permission to do so.
Returns information about all Robin Platform users including details such as the tenants they are associated with, current namespace and current role.
End Point: /api/v5/robin_server/users
Method: GET
URL Parameters:
disabled=true: Utilizing this parameter results in disabled users also being returned alongside normal users.hidden=true: Utilizing this parameter results in hidden users also being returned alongside normal users.deleted=true: Utilizing this parameter results in deleted users also being returned alongside normal users.
Data Parameters: None
Port: RCM Port (default value is 29442)
Headers:
Authorization: <auth_token>: Authorization token to identify which user is sending the request. The token can be acquired from the login API.
Success Response Code: 200
Error Response Code: 500 (Internal Server Error), 401 (Unauthorized Error)
Example Response:
Output
{
"items":[
{
"first_name":"Robin",
"user_context":"robin",
"tenant":"Administrators",
"username":"robin",
"user_context_id":3,
"tenant_id":1,
"permissions":{
},
"ldap_server_ref":null,
"tenants":[
{
"user_capabilities":[
"AllSuperAdminCapabilities"
],
"tenant_role":"superadmin",
"name":"Administrators"
}
],
"authentication":"local",
"hidden":false,
"user_id":3,
"email":null,
"last_name":"Systems",
"user_contexts":[
{
"user_credential_ref":3,
"tenant_ref":1,
"tenant":"Administrators",
"user_credential":"",
"name":"robin",
"user_ref":3,
"username":"robin",
"namespace":"t001-u000003",
"id":3,
"context_type":"ROBIN_CONTEXT"
}
],
"current_role":"superadmin",
"deleted":false
},
{
"first_name":null,
"user_context":"user3",
"tenant":"t3",
"username":"user3",
"user_context_id":5,
"tenant_id":3,
"permissions":{
},
"ldap_server_ref":null,
"tenants":[
{
"user_capabilities":[
"ViewApplications",
"CreateApplications",
"SnapshotApplications",
"BackupApplications",
"CloneApplications",
"DeleteApplications",
"ViewSystem",
"ViewK8sApplications",
"ManageK8sApplications",
"ViewImages",
"CreateImages",
"ViewBundles",
"CreateBundles",
"ViewInstances",
"ManageInstances",
"ViewDocker",
"ViewNetworking",
"ViewResourcePools",
"ViewTags",
"ViewResourceGroups",
"ViewChargeback",
"ViewConfig",
"ViewFileCollections",
"ViewNodes",
"ViewEvents",
"ViewJobs",
"ViewZones",
"ViewWorkflow",
"ViewStorageArray",
"ViewStorageRepos",
"UseStorageRepos",
"ViewNFSExports",
"ViewTiller",
"DownloadFiles",
"ViewK8sUserAuth",
"ViewNamespaces",
"UseNamespaces",
"ManageNamespaces",
"ViewUserAuth",
"CreateBackups",
"DeleteBackups",
"PurgeBackups",
"ManageApplications",
"ViewBackups"
],
"tenant_role":"user",
"name":"t3"
}
],
"authentication":"local",
"hidden":false,
"user_id":4,
"email":null,
"last_name":null,
"user_contexts":[
{
"user_credential_ref":5,
"tenant_ref":3,
"tenant":"t3",
"user_credential":"robin",
"name":"user3",
"user_ref":4,
"username":"user3",
"namespace":"t003-u000004",
"id":5,
"context_type":"ROBIN_CONTEXT"
}
],
"current_role":"user",
"deleted":false
},
{
"first_name":null,
"user_context":"user5",
"tenant":"t4",
"username":"user5",
"user_context_id":6,
"tenant_id":6,
"permissions":{
},
"ldap_server_ref":null,
"tenants":[
{
"user_capabilities":[
"ViewApplications",
"CreateApplications",
"SnapshotApplications",
"BackupApplications",
"CloneApplications",
"DeleteApplications",
"ViewSystem",
"ViewK8sApplications",
"ManageK8sApplications",
"ViewImages",
"CreateImages",
"ViewBundles",
"CreateBundles",
"ViewInstances",
"ManageInstances",
"ViewDocker",
"ViewNetworking",
"ViewResourcePools",
"ViewTags",
"ViewResourceGroups",
"ViewChargeback",
"ViewConfig",
"ViewFileCollections",
"ViewNodes",
"ViewEvents",
"ViewJobs",
"ViewZones",
"ViewWorkflow",
"ViewStorageArray",
"ViewStorageRepos",
"UseStorageRepos",
"ViewNFSExports",
"ViewTiller",
"DownloadFiles",
"ViewK8sUserAuth",
"ViewNamespaces",
"UseNamespaces",
"ManageNamespaces",
"ViewUserAuth",
"CreateBackups",
"DeleteBackups",
"PurgeBackups",
"ManageApplications",
"ViewBackups"
],
"tenant_role":"user",
"name":"t4"
}
],
"authentication":"local",
"hidden":false,
"user_id":5,
"email":null,
"last_name":null,
"user_contexts":[
{
"user_credential_ref":6,
"tenant_ref":6,
"tenant":"t4",
"user_credential":"user5",
"name":"user5",
"user_ref":5,
"username":"user5",
"namespace":"t006-u000005",
"id":6,
"context_type":"ROBIN_CONTEXT"
}
],
"current_role":"user",
"deleted":false
},
{
"first_name":null,
"user_context":"user6",
"tenant":"t5",
"username":"user6",
"user_context_id":7,
"tenant_id":7,
"permissions":{
},
"ldap_server_ref":null,
"tenants":[
{
"user_capabilities":[
"ViewApplications",
"CreateApplications",
"SnapshotApplications",
"BackupApplications",
"CloneApplications",
"DeleteApplications",
"ViewSystem",
"ViewK8sApplications",
"ManageK8sApplications",
"ViewImages",
"CreateImages",
"ViewBundles",
"CreateBundles",
"ViewInstances",
"ManageInstances",
"ViewDocker",
"ViewNetworking",
"ViewResourcePools",
"ViewTags",
"ViewResourceGroups",
"ViewChargeback",
"ViewConfig",
"ViewFileCollections",
"ViewNodes",
"ViewEvents",
"ViewJobs",
"ViewZones",
"ViewWorkflow",
"ViewStorageArray",
"ViewStorageRepos",
"UseStorageRepos",
"ViewNFSExports",
"ViewTiller",
"DownloadFiles",
"ViewK8sUserAuth",
"ViewNamespaces",
"UseNamespaces",
"ManageNamespaces",
"ViewUserAuth",
"CreateBackups",
"DeleteBackups",
"PurgeBackups",
"ManageApplications",
"ViewBackups"
],
"tenant_role":"user",
"name":"t5"
}
],
"authentication":"local",
"hidden":false,
"user_id":6,
"email":null,
"last_name":null,
"user_contexts":[
{
"user_credential_ref":7,
"tenant_ref":7,
"tenant":"t5",
"user_credential":"user6",
"name":"user6",
"user_ref":6,
"username":"user6",
"namespace":"t007-u000006",
"id":7,
"context_type":"ROBIN_CONTEXT"
}
],
"current_role":"user",
"deleted":false
}
]
}
8.7.5. User login¶
Run the following command to initiate a Robin Platform cluster login session:
# robin login <username>
--password <password>
--tenant <tenant>
--namespace <namespace>
|
The username for the user logging into the Robin Platform cluster |
|
User password (for testing only) |
|
Name of tenant the user will be logged into (default is the same tenant from previous login) |
|
Change the current namespace for the user who is logging in. Note that only the user’s assigned namespace for the tenant they are logging into will be accepted at this time |
Example:
# robin login robin --password Robin123 --tenant Administrators
User robin is logged into Administrators tenant
Logs a user into a tenant.
End Point: /api/v3/robin_server/login
Method: POST
URL Parameters: None
Data Parameters:
username: <username>- This mandatory field within the payload specifies the username of the user to login as.password: <password>- This mandatory field within the payload specifies the password of the user to login as.tenant: <tenant>- Utilizing this parameter by specifying a tenant name results in the user being logged into the aforementioned tenant. If not specified the tenant from the previous login will be used.namespace: <namespace>- Utilizing this parameter by specifying a namespace results in the user’s current namespace changing to the aforementioned namespace. Note that only the user’s assigned namespace for the tenant they are logging into will be accepted at this time.
Port: RCM Port (default value is 29442)
Headers: None
Success Response Code: 200
Error Response Code: 500 (Internal Server Error), 401 (Unauthorized Error)
Example Response:
Output
{
"token_timestamp":1599752493,
"tenant":"Administrators",
"staas":false,
"token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE1OTk3NTI0OTMsInVzZXJfaWQiOjMsInRlbmFudF9pZCI6MX0.vqxRGk-2ZHsXJH6Na9TSITP8qx2LklDWVcCBIyb5igY",
"zoneid":1595331866,
"role":"superadmin",
"tenants":[
"Administrators"
],
"namespace":"t001-u000003"
}
8.7.6. Change current user’s password¶
To change the password for the current Robin Platform user, issue the following command:
# robin password change
Example:
# robin password change
Password: <new_password>
Retype password: <new_password>
Password for current user has been updated
Changes the password for the current Robin Platform user.
End Point: /api/v3/robin_server/login
Method: PUT
URL Parameters: None
Data Parameters:
action: change_password- This mandatory field within the payload specifies that the change password operation is to be performed.password: <password>- This mandatory field within the payload specifies the new password for the current user.
Port: RCM Port (default value is 29442)
Headers: None
Success Response Code: 200
Error Response Code: 500 (Internal Server Error), 401 (Unauthorized Error), 400 (Invalid API Usage Error)
Example Response:
Output
{
"token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE1OTk3NTk1MTAsInVzZXJfaWQiOjMsInRlbmFudF9pZCI6MX0.t9jTYJgTnGYdedmL67ql9ETl-rcjmUFvK64bPE_Z5_g"
}
8.7.7. User Certificate Management¶
Robin CNP automatically generates a TLS certificate for all the users added to the Robin CNP cluster. It enables you to manage these user certificates using a scheduler for user certificates and configuration settings. The user certificate is by default valid for one year from the date of user addition, and it will automatically renew if the certificate is going to expire, depending on the set configuration and scheduler status.
You can modify the user certificate configuration as per your requirements. In the user certificate configuration, you can define the minimum and maximum validity of a certificate. The minimum validity is one day, and the maximum is one year. The default validity is one year. The configuration also checks the validity of the certificates and automatically renews them as per the scheduler and renewal offset.
Robin CNP has a scheduler to check the validity of the user certificates, and the scheduler runs as per the set intervals and enables the automatic renewal of user certificates. By default, the scheduler is enabled, and it runs once in every twenty four hours. You can stop the scheduler as per your requirements.
Note
When the scheduler is stopped, if any user certificates are due for renewal, they will not get renewed automatically. However, when you restart the scheduler, it will renew the expired certificates.
8.7.7.1. Checking Users Certificate Status¶
You can check the status of Robin users certificate by using the robin user-cert check command. The output provides the following details:
Cert Lifespan: User certificate lifespan as per configuration
Renewal Offset: User certificate renewal offset - Number of secs/minutes/hours/days/weeks/months/1year (configured and displayed in seconds) before which the scheduler reminds and automatically renews the certificate.
Check Interval: The duration when the scheduler runs automatically to check validity of the certificate
Schedule Enabled:: True/False
Run the following command to check status of users certificates:
# robin user-cert check
Example
# robin user-cert check
Cert Lifespan: 31536000 (1 year)
Renewal Offset: 1209600 (14 days)
Check Interval: 86400 (1 day)
Schedule Enabled: False
----------------------------------------------------------------------------------
NAME | USERNAME | VALID | EXPIRES
---------------------------------+-----------------+-------+-----------------------
user-credentials-csi | csi | True | Feb 28, 2025 07:05:54
user-credentials-einstein | einstein | True | Feb 28, 2025 07:06:00
user-credentials-euclid | euclid | True | Feb 28, 2025 07:06:06
user-credentials-euler | euler | True | Feb 28, 2025 07:06:11
user-credentials-galieleo | galieleo | True | Feb 28, 2025 07:06:17
user-credentials-gauss | gauss | True | Feb 28, 2025 07:06:23
You can renew a user certificate offset period, renew all certificates for all users when required, and perform a dry run to verify the renewal process.
8.7.7.2. Renewing User Certificate¶
When you need to renew user certificates for all users, you can use --renew-all-certs.
Using the renewal offset option, you can set a time for automatic renewal of the certificate before its expiration date. It can be in seconds, minutes, hours, days, or weeks. The minimum period of time you can set for automatic renewal is 7 days, and the maximum is one year.
Also, you can test the automatic renewal setting using the --dry-run.
Run the following command to renew user certificates:
# robin user-cert renew
--renew-all-certs
--renewal-offset <renewal_offset>
--dry-run
|
Force the renewal of all user certificates. |
|
Minimum number of seconds prior to actual certificate expiration when certificate renewal is triggered. The renewal_offset can be specified as seconds, minutes, hours, days, or weeks (e.g., ‘36000’, ‘600s’, ‘10m’, ‘24h’, ‘7d’. or ‘1w’). The minimum renewal_offset value allowed is 604800 seconds (7 days) and the maximum value allowed is 31536000 seconds (1 year). |
|
Perform a dry run without actually triggering a certificate renewal. |
Example: Renew all certificates
# robin user-cert renew --renew-all-certs
User cert renewal request sent. This might take a while...
Valid user certs: 0
Renewed user certs: 10
Messages:
Forced renewal of all user certs
- Renewing certificate 'user-credentials-csi'
- Renewing certificate 'user-credentials-einstein'
- Renewing certificate 'user-credentials-euclid'
- Renewing certificate 'user-credentials-euler'
- Renewing certificate 'user-credentials-galieleo'
- Renewing certificate 'user-credentials-gauss'
- Renewing certificate 'user-credentials-metrics-collect'
- Renewing certificate 'user-credentials-newton'
- Renewing certificate 'user-credentials-peer'
- Renewing certificate 'user-credentials-robin'
Example: Renew the user certificate renewal offset
# robin user-cert renew --renewal-offset 7d
User cert renewal request sent. This might take a while...
Valid user certs: 10
Renewed user certs: 0
Messages:
Renewing user certs with renewal_offset=604800
Cert 'user-credentials-csi' is valid
Cert 'user-credentials-einstein' is valid
Cert 'user-credentials-euclid' is valid
Cert 'user-credentials-euler' is valid
Cert 'user-credentials-galieleo' is valid
Cert 'user-credentials-gauss' is valid
Cert 'user-credentials-metrics-collect' is valid
Cert 'user-credentials-newton' is valid
Cert 'user-credentials-peer' is valid
Cert 'user-credentials-robin' is valid
Example: Dry run
# robin user-cert renew --dry-run
Valid user certs: 3
Renewed user certs: 4
Messages:
Renewing user certs with renewal_offset=1123200 (dry_run)
Cert 'user-credentials-csi' is valid
Cert 'user-credentials-metrics-collect' is valid
Cert 'user-credentials-peer' is valid
Cert 'user-credentials-robin' has a 'not_after' date that is before the current date (minus renewal_offset)
- Renewing certificate 'user-credentials-robin'
Cert 'user-credentials-sachin-1' has a 'not_after' date that is before the current date (minus renewal_offset)
- Renewing certificate 'user-credentials-sachin-1'
Cert 'user-credentials-sachin-10' has a 'not_after' date that is before the current date (minus renewal_offset)
- Renewing certificate 'user-credentials-sachin-10'
Cert 'user-credentials-sachin-11' has a 'not_after' date that is before the current date (minus renewal_offset)
- Renewing certificate 'user-credentials-sachin-11'
8.7.7.3. Modifying User Certificate Configuration¶
User certificate management settings are configurable using the update-config CLI option. You can configure the following parameters:
Cert Lifespan: Configure the life span of the user certificate. You can set life span in seconds, minutes, hours, days, and one year for which the user certificate will be valid. The minimum life span that you can set for one day in seconds is 86400 seconds (1 day).
Check-interval: Configure the time interval to check the validity of user certificate. The minimum
check-intervalvalue allowed is 60 seconds (60 seconds). The maximum check_interval value allowed is 2592000 seconds (30 days). It is the time interval between two checks. You can set the check interval in raw seconds, seconds, minutes, hours, or days.Renewal offset: Configure the minimum time prior to actual certificate expiration when certificate renewal will be triggered. You can specify renewal offset using the –renewal_offset option. You can be specify in seconds, minutes, hours, days, or weeks (e.g., ‘36000’, ‘600s’, ‘10m’, ‘24h’, ‘7d’. or ‘1w’). The minimum renewal_offset value allowed is 604800 seconds (7 days) and the maximum value allowed is 31536000 seconds (1 year).
# robin user-cert update-config
--defaults
--cert-lifespan <cert_lifespan>
--check-interval <check_interval>
--renewal-offset <renewal_offset>
|
Reset user certificate attributes to default values. |
|
Amount of time, in seconds, that a user certificate will be valid. The minimum lifespan value allowed is 86400 seconds (1 day). The maximum lifespan value allowed is 31536000 seconds (1 year) (the default value if not specified). The cert_lifespan value can be specified as raw seconds, seconds, minutes, hours, days, or years (e.g., ‘43200’, ‘43200s’, ‘1440m’, ‘24h’, ‘7d’, or ‘1y’). |
|
Number of seconds between each user cert renewal check. The minimum check_interval value allowed is 60 seconds (60 seconds). The maximum check_interval value allowed is 2592000 seconds (30 days). The check_interval value can be specified as raw seconds, seconds, minutes, hours, or days. |
|
Minimum number of seconds prior to actual certificate expiration when certificate renewal is triggered. The renewal_offset can be specified as seconds, minutes, hours, days, or weeks (e.g., ‘36000’, ‘600s’, ‘10m’, ‘24h’, ‘7d’. or ‘1w’). The minimum renewal_offset value allowed is 604800 seconds (7 days) and the maximum value allowed is 31536000 seconds (1 year). |
Example: Reset user certificate values to default
# robin user-cert update --defaults
Cert Lifespan: 31536000 (1 year)
Renewal Offset: 1209600 (14 days)
Check Interval: 86400 (1 day)
Schedule Enabled: True
Update Steps:
-- Updating user certificate attributes to default values
-- Using input cert_lifespan value (31536000)
-- Updating cert_lifespan config value to '31536000'
-- Using input check_interval value (86400)
-- Updating check_interval config value to '86400'
-- Using input renewal_offset value (1209600)
Example: Update lifespan of the certificate
# robin user-cert update --cert-lifespan 10d
Cert Lifespan: 864000 (10 days)
Renewal Offset: 1209600 (14 days)
Check Interval: 86400 (1 day)
Schedule Enabled: True
Update Steps:
-- Using input cert_lifespan value (864000)
-- Updating cert_lifespan config value to '864000'
-- Using current check_interval value (86400)
-- Using current renewal_offset value (1209600)
Example : Update renewal offset
# robin user-cert update --renewal-offset 13d
Cert Lifespan: 864000 (10 days)
Renewal Offset: 1123200 (13 days)
Check Interval: 172800 (2 days)
Schedule Enabled: True
Update Steps:
-- Using current cert_lifespan value (864000)
-- Using current check_interval value (172800)
-- Using input renewal_offset value (1123200)
-- Updating renewal_offset config value to '1123200'
8.7.7.4. Stopping User Certificate Schedule¶
You can stop the user certificate schedule when you need to stop the renewal of the certificates and you do not want CNP to check for the validity of the user certificate.
Note
When the scheduler is stopped, if any user certificates are due for renewal, they will not get renewed automatically. However, when you restart the scheduler, it will renew the expired certificates.
Run the following command to stop:
# robin user-cert stop-schedule
Example
# robin user-cert stop-schedule
User certificate renewal schedule stopped
# robin user-cert check | grep -A4 Life
Cert Lifespan: 259200 (3 days)
Renewal Offset: 6912000 (80 days)
Check Interval: 64800 (18 hours)
Schedule Enabled: False
8.7.7.5. Starting User Certificate Schedule¶
You can restart the stopped scheduler to restart the renewal of the validity of the user certificates.
Run the following command to start:
# robin user-cert start-schedule
Example
# robin user-cert start-schedule
User certificate renewal schedule started
# robin schedule list | grep UserCertificate
UserCertificate | renew_user_certs_cb | 64800 | 4s back | - | Yes | In 17h | - | - | 0.00s | 0.00s |
# robin user-cert check | grep -A4 Life
Cert Lifespan: 259200 (3 days)
Renewal Offset: 6912000 (80 days)
Check Interval: 64800 (18 hours)
Schedule Enabled: True
8.8. LDAP management operations¶
8.8.1. Add an LDAP server¶
Run the following command to add an LDAP server:
# robin ldap add-server <name> <hostname> <port> <server_type> <username> <search_base>
--user-base <user_base>
--group-base <group_base>
--netbios <netbios>
--password <password>
--use-ssl
--ca-cert <ca_cert>
--ca-cert-file <ca_cert_file>
--client-cert <client_cert>
--client-cert-file <client_cert_file>
--client-key <client_key>
--client-key-file <client_key_file>
|
Name to assign to the LDAP server |
|
Hostname of the LDAP server |
|
Port number of the LDAP server |
|
Type of LDAP server. Valid choices are |
|
Username of the user with LDAP server access rights (read permissions minimum) |
|
LDAP search base. For example, |
|
Base DN to use when searching for users and when constructing a user’s dn |
|
Base DN to use when searching for groups and when constructing a group’s dn |
|
NetBIOS name to use when authenticating users (required when server type is ACTIVE_DIRECTORY) |
|
Password for supplied username (for testing only) |
|
Configure server for secure (TLS) communication |
|
Base64 encoded CA certificate string for secure (TLS) communication |
|
Pathname for CA certificate file for secure (TLS) communication |
|
Base64 encoded client certificate string for secure (TLS) communication |
|
Pathname for client certificate file for secure (TLS) communication |
|
Base64 encoded client key string for secure (TLS) communication |
|
Pathname for client key string for secure (TLS) communication |
Example 1: Add an Active Directory LDAP server
To add an Active Directory LDAP server, use the following command:
# robin ldap add-server ad1 10.9.53.5 389 ACTIVE_DIRECTORY administrator mydomain.com --netbios mydomain
Password:
Retype password:
Successfully added ldap server 'ad1'
Example 2: Add an Open LDAP server
To add an Open LDAP server, use the following command:
# robin ldap add-server ldap1 ldap.forumsys.com 389 OPEN_LDAP cn=read-only-admin,dc=example,dc=com dc=example,dc=com
Password:
Retype password:
Successfully added ldap server 'ldap1'
Example 3: Add a Secure LDAP server (LDAPS)
To add a secure LDAP server, use the following command:
# robin ldap add-server ad3 10.9.53.6 636 ACTIVE_DIRECTORY administrator mydomain.com --netbios mydomain
Password:
Retype password:
Successfully added ldap server 'ad3'
In the above example, the port number is specified as 636 instead of the standard LDAP port 389 because a secure LDAP (LDAPS) server is being added.
Example 4: Add a Google Secure LDAP server
To add a Google Secure LDAP Server, use the following command:
# robin ldap add-server --use-ssl --client-cert-file "google-ldap.crt" --client-key-file "google-ldap.key" --ca-cert-file "ca-certificates.crt" "google-ldap-service" "ldap.google.com" 636 GOOGLE_CLOUD "uid=admin,ou=Users,dc=example,dc=com" "dc=example,dc=com"
Adds a LDAP server to the Robin cluster.
End Point: /api/v3/robin_server/ldap-servers/
Method: POST
URL Parameters: None
Data Parameters:
name: <ldap_name>- This mandatory field within the payload specifies the name to assign to the LDAP server.hostname: <hostname>- This mandatory field within the payload specifies the hostname of the LDAP server.port: <port>- This mandatory field within the payload specifies the integer value of the respective port for the LDAP server.server_type: <server_type>- This mandatory field within the payload specifies the type of LDAP server. Valid choices are ‘OPEN_LDAP’, ‘ACTIVE_DIRECTORY’, and ‘GOOGLE_CLOUD’.username: <username>- This mandatory field within the payload specifies the username of the user with LDAP server access rights. Note read permissions are needed at a minimum.password: <password>- This mandatory field within the payload specifies the password for the supplied username.search_base: <search_base>- This mandatory field within the payload specifies the LDAP search base. An example would be ‘dc=example,dc=com’. Note this value can also be specified as a domain name, such as ‘example.com’.user_base: <user_base>- Utilizing this parameter within the payload by specifying a string representing a Base DN, results in the aforementioned Base DN being used when searching for users and when constructing a user’s dn.group_base: <group_base>- Utilizing this parameter within the payload by specifying a string representing a Base DN, results in the aforementioned Base DN being used when searching for groups and when constructing a group’s dn.netbios: <netbios>- Utilizing this parameter within the payload by specifying the name of a NetBIOS, results in the aforementioned NetBIOS being used when authenticating users. Note this parameter is mandatory when the server type isACTIVE_DIRECTORY.
Port: RCM Port (default value is 29442)
Headers: None
Success Response Code: 200
Error Response Code: 500 (Internal Server Error), 401 (Unauthorized Error), 404 (Not Found Error), 400 (Invalid API Usage Error), 409 (Duplicate Resource Error)
Example Response:
Output
{
"message":"Successfully added ldap server 'ldap1'"
}
8.8.2. Remove an LDAP server¶
Run the following command to remove an LDAP server:
# robin ldap remove-server <name>
--yes
|
Name of LDAP server to remove |
|
Do not prompt for confirmation |
Example:
# robin ldap remove-server ldap1
Are you sure you want to delete [y/n] ? y
Successfully removed ldap server 'ldap1'
Removes a LDAP server from the Robin cluster.
End Point: /api/v3/robin_server/ldap-servers/<ldap_name>
Method: DELETE
URL Parameters: None
Data Parameters: None
Port: RCM Port (default value is 29442)
Headers: None
Success Response Code: 200
Error Response Code: 500 (Internal Server Error), 401 (Unauthorized Error), 404 (Not Found Error)
Example Response:
Output
{
"message":"Successfully removed ldap server 'ldap1'"
}
8.8.3. List LDAP servers¶
In order to list all the LDAP servers registered with the Robin cluster alongside details such as hostname, port and search base, issue the following command:
# robin ldap list-servers <name>
|
Name to use when referencing the LDAP server. If no name is provided then all LDAP servers will be displayed |
Example:
# robin ldap list-servers
Name | Server Type | Hostname | Port | Username | Search Base | User Base | Group Base | NetBIOS
------+------------------+-------------------+------+--------------------------------------+------------------------+-----------+------------+--------------
ad1 | ACTIVE_DIRECTORY | 10.9.53.5 | 389 | administrator | dc=robinsystems,dc=com | | | ROBINSYSTEMS
ldap1 | OPEN_LDAP | ldap.forumsys.com | 389 | cn=read-only-admin,dc=example,dc=com | dc=example,dc=com | | |
Lists all the LDAP servers registered with the Robin cluster alongside details such as hostname, port and search base.
End Point: /api/v3/robin_server/ldap-servers/
Method: GET
URL Parameters: None
Data Parameters: None
Port: RCM Port (default value is 29442)
Headers:
Authorization: <auth_token>: Authorization token to identify which user is sending the request. The token can be acquired from the login API.
Success Response Code: 200
Error Response Code: 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error)
Example Response:
Output
{
"items":[
{
"name":"ldap1",
"netbios":null,
"username":"cn=read-only-admin,dc=example,dc=com",
"port":389,
"hostname":"ldap.forumsys.com",
"password":"<REDACTED>",
"id":1,
"search_base":"dc=example,dc=com",
"user_base":null,
"group_base":null,
"server_type":"OPEN_LDAP"
}
]
}
8.8.4. List LDAP groups¶
In order to list groups within a LDAP server registered with the Robin cluster alongside the members it contains, issue the following command:
# robin ldap list-groups <ldap_server_name> [<groups>]
--search-base <search_base>
--ldap-filter <ldap_filter>
--raw
--json
|
Name of LDAP server to query for group info. |
|
Comma separated list of LDAP group names. If no group names are provided then all LDAP groups will be displayed. Note: listing of all groups can take a long time to complete |
|
Base DN for the LDAP group search |
|
LDAP filter that gets added to the base level group query filter. This option is not valid when group names are supplied on the command line |
|
Return records in raw LDAP format |
|
Output in JSON |
Example:
# robin ldap list-groups ldap1
Name | Members
---------------+-----------------------------------------------
Mathematicians | euclid,riemann,euler,gauss,test
Scientists | einstein,galileo,tesla,newton,training,jmacy
Italians | volta
Chemists | curie,boyle,nobel,pasteur
Lists groups within a LDAP server registered with the Robin cluster alongside the members it contains.
End Point: /api/v3/robin_server/ldap-groups/
Method: GET
URL Parameters: None
Data Parameters:
ldap_server_name: <ldap_name>- This mandatory field within the payload specifies the name of the LDAP server from which to retrieve groups.groups: <list_of_groups>- Utilizing this parameter within the payload by specifying a list of comma seperated group names, results in only information about the given groups being returned.ldap_filter: <ldap_filter>- Utilizing this parameter within the payload by specifying a string representing a LDAP filter, results in the aforementioned filter being added to the base level group query filter. Note this option is not valid if thegroupsis also utilized.search_base: <search_base>- Utilizing this parameter within the payload by specifying a string representing a Base DN, results in it being used as the Base DN for the LDAP group search.raw: true- Utilizing this parameter within the payload results in the user records being returned in raw LDAP format. The default value is False.
Port: RCM Port (default value is 29442)
Headers:
Authorization: <auth_token>: Authorization token to identify which user is sending the request. The token can be acquired from the login API.
Success Response Code: 200
Error Response Code: 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error), 400 (Invalid API Usage Error)
Example Response:
Output
{
"items":[
{
"name":"Mathematicians",
"members":[
[
"user",
{
"username":"euclid",
"distinguished_name":"uid=euclid,dc=example,dc=com",
"email_address":null,
"object_sid":"ac5dc692-2f67-1033-899a-a53eb149a944",
"last_name":"Euclid",
"first_name":null,
"user_principal_name":null,
"display_name":null
}
],
[
"user",
{
"username":"riemann",
"distinguished_name":"uid=riemann,dc=example,dc=com",
"email_address":null,
"object_sid":"8bd472ea-2f67-1033-8998-a53eb149a944",
"last_name":"Riemann",
"first_name":null,
"user_principal_name":null,
"display_name":null
}
],
[
"user",
{
"username":"euler",
"distinguished_name":"uid=euler,dc=example,dc=com",
"email_address":null,
"object_sid":"2bd3195a-2f67-1033-8994-a53eb149a944",
"last_name":"Euler",
"first_name":null,
"user_principal_name":null,
"display_name":null
}
],
[
"user",
{
"username":"gauss",
"distinguished_name":"uid=gauss,dc=example,dc=com",
"email_address":null,
"object_sid":"629ab718-2f67-1033-8996-a53eb149a944",
"last_name":"Gauss",
"first_name":null,
"user_principal_name":null,
"display_name":null
}
],
[
"user",
{
"username":"test",
"distinguished_name":"uid=test,dc=example,dc=com",
"email_address":null,
"object_sid":"1df9dada-bbe4-1033-8a53-8fb78330d80a",
"last_name":"Test",
"first_name":"Test",
"user_principal_name":null,
"display_name":"Test"
}
]
]
},
{
"name":"Scientists",
"members":[
[
"user",
{
"username":"einstein",
"distinguished_name":"uid=einstein,dc=example,dc=com",
"email_address":null,
"object_sid":"29f6dc28-2f64-1033-898b-a53eb149a944",
"last_name":"Einstein",
"first_name":null,
"user_principal_name":null,
"display_name":null
}
],
[
"user",
{
"username":"galieleo",
"distinguished_name":"uid=galieleo,dc=example,dc=com",
"email_address":null,
"object_sid":"b9c53cb4-2f64-1033-898f-a53eb149a944",
"last_name":"Galilei",
"first_name":null,
"user_principal_name":null,
"display_name":null
}
],
[
"user",
{
"username":"tesla",
"distinguished_name":"uid=tesla,dc=example,dc=com",
"email_address":null,
"object_sid":"751b0a76-2f64-1033-898d-a53eb149a944",
"last_name":"Tesla",
"first_name":null,
"user_principal_name":null,
"display_name":null
}
],
[
"user",
{
"username":"newton",
"distinguished_name":"uid=newton,dc=example,dc=com",
"email_address":null,
"object_sid":"050ce4de-2f64-1033-8989-a53eb149a944",
"last_name":"Newton",
"first_name":null,
"user_principal_name":null,
"display_name":null
}
],
[
"user",
{
"username":"training",
"distinguished_name":"uid=training,dc=example,dc=com",
"email_address":null,
"object_sid":"32a324bc-93e3-1036-80e6-176a7c6d2b5d",
"last_name":"training",
"first_name":null,
"user_principal_name":null,
"display_name":null
}
],
[
"user",
{
"username":"jmacy",
"distinguished_name":"uid=jmacy,dc=example,dc=com",
"email_address":null,
"object_sid":"e59260cc-05af-1037-8162-176a7c6d2b5d",
"last_name":"training",
"first_name":null,
"user_principal_name":null,
"display_name":null
}
]
]
},
{
"name":"Italians",
"members":[
[
"user",
{
"username":"tesla",
"distinguished_name":"uid=tesla,dc=example,dc=com",
"email_address":null,
"object_sid":"751b0a76-2f64-1033-898d-a53eb149a944",
"last_name":"Tesla",
"first_name":null,
"user_principal_name":null,
"display_name":null
}
]
]
},
{
"name":"Chemists",
"members":[
[
"user",
{
"username":"curie",
"distinguished_name":"uid=curie,dc=example,dc=com",
"email_address":null,
"object_sid":"2904419a-6b48-1034-8ad4-8fb78330d80a",
"last_name":"Curie",
"first_name":null,
"user_principal_name":null,
"display_name":null
}
],
[
"user",
{
"username":"boyle",
"distinguished_name":"uid=boyle,dc=example,dc=com",
"email_address":null,
"object_sid":"6f3a5bea-6b48-1034-8ad6-8fb78330d80a",
"last_name":"Boyle",
"first_name":null,
"user_principal_name":null,
"display_name":null
}
],
[
"user",
{
"username":"nobel",
"distinguished_name":"uid=nobel,dc=example,dc=com",
"email_address":null,
"object_sid":"4f351948-6b48-1034-8ad5-8fb78330d80a",
"last_name":"Nobel",
"first_name":null,
"user_principal_name":null,
"display_name":null
}
],
[
"user",
{
"username":"pasteur",
"distinguished_name":"uid=pasteur,dc=example,dc=com",
"email_address":null,
"object_sid":"a0aa9ed8-6b48-1034-8ad7-8fb78330d80a",
"last_name":"Pasteur",
"first_name":null,
"user_principal_name":null,
"display_name":null
}
]
]
}
]
}
8.8.5. List LDAP users¶
In order to list users within a LDAP server registered with the Robin cluster alongside details such as each users email address, principal name and Object SID, issue the following command:
# robin ldap list-users <ldap_server_name> [<users>]
--search-base <search_base>
--ldap-filter <ldap_filter>
--raw
--json
|
Name of LDAP server to query for user info. |
|
Comma-separated list of LDAP user names. If no user names are provided then all LDAP users will be displayed. Note: listing all users can take a long time to complete |
|
Base DN for the LDAP user search |
|
LDAP filter that gets added to the base level user query filter. Note: this option is not valid when user names are supplied on the command line |
|
Return records in raw LDAP format. |
|
Output in JSON |
Example:
Username | Email Address | User Principal Name | Object SID | DN
----------------+---------------+---------------------+--------------------------------------+--------------------------------------
newton | None | None | 050ce4de-2f64-1033-8989-a53eb149a944 | uid=newton,dc=example,dc=com
einstein | None | None | 29f6dc28-2f64-1033-898b-a53eb149a944 | uid=einstein,dc=example,dc=com
tesla | None | None | 751b0a76-2f64-1033-898d-a53eb149a944 | uid=tesla,dc=example,dc=com
galieleo | None | None | b9c53cb4-2f64-1033-898f-a53eb149a944 | uid=galieleo,dc=example,dc=com
euler | None | None | 2bd3195a-2f67-1033-8994-a53eb149a944 | uid=euler,dc=example,dc=com
gauss | None | None | 629ab718-2f67-1033-8996-a53eb149a944 | uid=gauss,dc=example,dc=com
riemann | None | None | 8bd472ea-2f67-1033-8998-a53eb149a944 | uid=riemann,dc=example,dc=com
euclid | None | None | ac5dc692-2f67-1033-899a-a53eb149a944 | uid=euclid,dc=example,dc=com
read-only-admin | None | None | 76117660-2f80-1033-899f-a53eb149a944 | cn=read-only-admin,dc=example,dc=com
test | None | None | 1df9dada-bbe4-1033-8a53-8fb78330d80a | uid=test,dc=example,dc=com
curie | None | None | 2904419a-6b48-1034-8ad4-8fb78330d80a | uid=curie,dc=example,dc=com
nobel | None | None | 4f351948-6b48-1034-8ad5-8fb78330d80a | uid=nobel,dc=example,dc=com
boyle | None | None | 6f3a5bea-6b48-1034-8ad6-8fb78330d80a | uid=boyle,dc=example,dc=com
pasteur | None | None | a0aa9ed8-6b48-1034-8ad7-8fb78330d80a | uid=pasteur,dc=example,dc=com
nogroup | None | None | 25229968-6b49-1034-8ad8-8fb78330d80a | uid=nogroup,dc=example,dc=com
training | None | None | 32a324bc-93e3-1036-80e6-176a7c6d2b5d | uid=training,dc=example,dc=com
jmacy | None | None | e59260cc-05af-1037-8162-176a7c6d2b5d | uid=jmacy,dc=example,dc=com
Lists users within a LDAP server registered with the Robin cluster alongside details such as each users email address, principal name and Object SID.
End Point: /api/v3/robin_server/ldap-users/
Method: GET
URL Parameters: None
Data Parameters:
ldap_server_name: <ldap_name>- This mandatory field within the payload specifies the name of the LDAP server from which to retrieve users.ldap_filter: <ldap_filter>- Utilizing this parameter within the payload by specifying a string representing a LDAP filter, results in the aforementioned filter being added to the base level user query filter.search_base: <search_base>- Utilizing this parameter within the payload by specifying a string representing a Base DN, results in it being used as the Base DN for the LDAP user search.raw: true- Utilizing this parameter within the payload results in the user records being returned in raw LDAP format. The default value is False.
Port: RCM Port (default value is 29442)
Headers:
Authorization: <auth_token>: Authorization token to identify which user is sending the request. The token can be acquired from the login API.
Success Response Code: 200
Error Response Code: 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error)
Example Response:
Output
{
"items":[
{
"username":"newton",
"distinguished_name":"uid=newton,dc=example,dc=com",
"email_address":null,
"object_sid":"050ce4de-2f64-1033-8989-a53eb149a944",
"last_name":"Newton",
"first_name":null,
"user_principal_name":null,
"display_name":null
},
{
"username":"einstein",
"distinguished_name":"uid=einstein,dc=example,dc=com",
"email_address":null,
"object_sid":"29f6dc28-2f64-1033-898b-a53eb149a944",
"last_name":"Einstein",
"first_name":null,
"user_principal_name":null,
"display_name":null
},
{
"username":"tesla",
"distinguished_name":"uid=tesla,dc=example,dc=com",
"email_address":null,
"object_sid":"751b0a76-2f64-1033-898d-a53eb149a944",
"last_name":"Tesla",
"first_name":null,
"user_principal_name":null,
"display_name":null
},
{
"username":"galieleo",
"distinguished_name":"uid=galieleo,dc=example,dc=com",
"email_address":null,
"object_sid":"b9c53cb4-2f64-1033-898f-a53eb149a944",
"last_name":"Galilei",
"first_name":null,
"user_principal_name":null,
"display_name":null
},
{
"username":"euler",
"distinguished_name":"uid=euler,dc=example,dc=com",
"email_address":null,
"object_sid":"2bd3195a-2f67-1033-8994-a53eb149a944",
"last_name":"Euler",
"first_name":null,
"user_principal_name":null,
"display_name":null
},
{
"username":"gauss",
"distinguished_name":"uid=gauss,dc=example,dc=com",
"email_address":null,
"object_sid":"629ab718-2f67-1033-8996-a53eb149a944",
"last_name":"Gauss",
"first_name":null,
"user_principal_name":null,
"display_name":null
},
{
"username":"riemann",
"distinguished_name":"uid=riemann,dc=example,dc=com",
"email_address":null,
"object_sid":"8bd472ea-2f67-1033-8998-a53eb149a944",
"last_name":"Riemann",
"first_name":null,
"user_principal_name":null,
"display_name":null
},
{
"username":"euclid",
"distinguished_name":"uid=euclid,dc=example,dc=com",
"email_address":null,
"object_sid":"ac5dc692-2f67-1033-899a-a53eb149a944",
"last_name":"Euclid",
"first_name":null,
"user_principal_name":null,
"display_name":null
},
{
"username":"read-only-admin",
"distinguished_name":"cn=read-only-admin,dc=example,dc=com",
"email_address":null,
"object_sid":"76117660-2f80-1033-899f-a53eb149a944",
"last_name":"Read Only Admin",
"first_name":null,
"user_principal_name":null,
"display_name":null
},
{
"username":"test",
"distinguished_name":"uid=test,dc=example,dc=com",
"email_address":null,
"object_sid":"1df9dada-bbe4-1033-8a53-8fb78330d80a",
"last_name":"Test",
"first_name":"Test",
"user_principal_name":null,
"display_name":"Test"
},
{
"username":"curie",
"distinguished_name":"uid=curie,dc=example,dc=com",
"email_address":null,
"object_sid":"2904419a-6b48-1034-8ad4-8fb78330d80a",
"last_name":"Curie",
"first_name":null,
"user_principal_name":null,
"display_name":null
},
{
"username":"nobel",
"distinguished_name":"uid=nobel,dc=example,dc=com",
"email_address":null,
"object_sid":"4f351948-6b48-1034-8ad5-8fb78330d80a",
"last_name":"Nobel",
"first_name":null,
"user_principal_name":null,
"display_name":null
},
{
"username":"boyle",
"distinguished_name":"uid=boyle,dc=example,dc=com",
"email_address":null,
"object_sid":"6f3a5bea-6b48-1034-8ad6-8fb78330d80a",
"last_name":"Boyle",
"first_name":null,
"user_principal_name":null,
"display_name":null
},
{
"username":"pasteur",
"distinguished_name":"uid=pasteur,dc=example,dc=com",
"email_address":null,
"object_sid":"a0aa9ed8-6b48-1034-8ad7-8fb78330d80a",
"last_name":"Pasteur",
"first_name":null,
"user_principal_name":null,
"display_name":null
},
{
"username":"nogroup",
"distinguished_name":"uid=nogroup,dc=example,dc=com",
"email_address":null,
"object_sid":"25229968-6b49-1034-8ad8-8fb78330d80a",
"last_name":"Group",
"first_name":null,
"user_principal_name":null,
"display_name":null
},
{
"username":"training",
"distinguished_name":"uid=training,dc=example,dc=com",
"email_address":null,
"object_sid":"32a324bc-93e3-1036-80e6-176a7c6d2b5d",
"last_name":"training",
"first_name":null,
"user_principal_name":null,
"display_name":null
},
{
"username":"jmacy",
"distinguished_name":"uid=jmacy,dc=example,dc=com",
"email_address":null,
"object_sid":"e59260cc-05af-1037-8162-176a7c6d2b5d",
"last_name":"training",
"first_name":null,
"user_principal_name":null,
"display_name":null
}
]
}
8.8.6. Import LDAP users¶
Run the following command to import one or more LDAP users:
# robin ldap import-users <ldap_server_name> <users> <tenant> <tenant_role> [<user_capabilities>]
--search-base <search_base>
|
Name of LDAP server to query for user info. |
|
Comma separated list of LDAP users to import. |
|
Tenant that all imported users will be made a member of |
|
User role for the tenant assigned to each imported user |
|
Optional comma separated list of tenant specific capabilities to assign to the each user being added. Note that if no capabilities are specified, then full capabilities for the specified role will be assigned. If it’s desired that no capabilities be granted to the user then specify ‘NoCapabilities’ on the command line |
|
Base DN for the LDAP user search |
Note
To view a list of all user capabilities review the section detailed here.
Example:
# robin ldap import-users ldap1 newton,einstein,tesla t1 user
Successfully added multiple users: newton,einstein,tesla
Imports one or more LDAP users into the Robin cluster.
End Point: /api/v3/robin_server/users/
Method: POST
URL Parameters: None
Data Parameters:
user_list: <list_of_dicts>– This mandatory parameter within the payload is a comma seperated list of dictionaries (with the keys given below) and results in the specified users being added.username: <username>- This mandatory field within each dictionary specifies the name of the user.authentication_type: 2- This mandatory field within each dictionary specifies that the authentication type is LDAP.ldap_server: <ldap_server>- This mandatory field within each dictionary specifies the name of LDAP server to query for user info.tenant_list: <list_with_dict>- This mandatory field within each dictionary is a list containing one dictionary with the keystenant(for the tenant to place the user in) andtenant_role(for the role the user should assume within the tenant).user_capabilities: <list_of_capabilities>- Utilizing this parameter within each dictionary, by specifying a comma seperated list of capabilities, results in the aforementioned capabilties being assigned to the newly added user. Note if this parameter is not used, then full capabilities for the specified role will be assigned to the user. If it’s desired that no capabilities be granted to the user then specify ‘NoCapabilities’ within the list.
search_base: <search_base>- Utilizing this parameter within the payload by specifying a string representing a Base DN, results in it being used as the Base DN for the LDAP user search.
Port: RCM Port (default value is 29442)
Headers:
Authorization: <auth_token>: Authorization token to identify which user is sending the request. The token can be acquired from the login API.
Success Response Code: 200
Error Response Code: 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error), 400 (Invalid API Usage Error)
Example Response:
Output
{
"message":"\nSuccessfully added multiple users: newton,einstein,tesla\n"
}
8.8.7. Import LDAP group¶
Run the following command to import all members of an LDAP group:
# robin ldap import-group <ldap_server_name> <group> <tenant> <tenant_role> [<user_capabilities>]
--exclude-users <excluded_users>
--search-base <search_base>
|
Name of LDAP server to query for group info. |
|
Name of the LDAP group to import users from |
|
Tenant that all imported users will be made a member of |
|
User role for the tenant assigned to each imported user |
|
Optional comma separated list of tenant specific capabilities to assign to the each user being added. Note that if no capabilities are specified, then full capabilities for the specified role will be assigned. If it’s desired that no capabilities be granted to the user then specify ‘NoCapabilities’ on the command line |
|
Comma separated list of users to exclude from importation |
|
Base DN for the LDAP group search |
Note
To view a list of all user capabilities review the section detailed here.
Example:
# robin ldap import-group ldap1 Italians t1 user
Imported LDAP users: volta
Imports all members of an LDAP group into the Robin cluster.
End Point: /api/v3/robin_server/ldap-groups/
Method: PUT
URL Parameters: None
Data Parameters:
action: import- This mandatory field within the payload specifies that the import action should be performed.group_name: <group_name>- This mandatory field within the payload specifies the name of the LDAP group to import users from.tenant: <tenant_name>- This mandatory field within the payload specifies the tenant that all imported users will be made a member of.tenant_role: <tenant_role>- This mandatory field within the payload specifies the user role for the tenant assigned to each imported user.ldap_server: ldap_server- This mandatory field within the payload specifies the name of LDAP server to query for group info.user_capabilities: <list_of_capabilities>- Utilizing this parameter within the payload, by specifying a comma seperated list of capabilities, results in the aforementioned capabilties being assigned to each newly added user. Note if this parameter is not used, then full capabilities for the specified role will be assigned to each user. If it’s desired that no capabilities be granted to each user then specify ‘NoCapabilities’ within the list.excluded_users: <excluded_users>- Utilizing this parameter within the payload, by specifying a comma seperated list of usernames, results in the aforementioned users not being imported.search_base: <search_base>- Utilizing this parameter within the payload by specifying a string representing a Base DN, results in it being used as the Base DN for the LDAP group search.
Port: RCM Port (default value is 29442)
Headers:
Authorization: <auth_token>: Authorization token to identify which user is sending the request. The token can be acquired from the login API.
Success Response Code: 200
Error Response Code: 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error), 400 (Invalid API Usage Error)
Example Response:
Output
{
"message":"Imported LDAP users: volta"
}
8.8.8. List LDAP Attributes¶
Run the following command to list LDAP attributes:
# robin ldap list-attributes --server-type <server_type>
--object-type <object_type>
|
Filter results based on LDAP server type. Valid choices are ‘OPEN_LDAP’, ‘ACTIVE_DIRECTORY’, and ‘GOOGLE_CLOUD’ |
|
Filter results based on LDAP object type. Valid choices are ‘user’ and ‘group’ |
Example 1 (List all attributes for server type OPEN_LDAP):
# robin ldap list-attributes --server-type OPEN_LDAP
Server Type | Object Type | Attribute Name | Custom | Value
------------+-------------+---------------------+--------+-----------------------------------------------------------
OPEN_LDAP | | distinguished_name | | entryDN
OPEN_LDAP | | object_class | | objectClass
OPEN_LDAP | group | class_list | | ['posixGroup', 'groupOfNames', 'groupOfUniqueNames']
OPEN_LDAP | group | distinguished_name | | entryDN
OPEN_LDAP | group | group_name | | cn
OPEN_LDAP | group | members | | ['uniqueMember', 'member']
OPEN_LDAP | group | object_class | | objectClass
OPEN_LDAP | group | object_sid | | objectSid
OPEN_LDAP | user | class_list | | ['posixAccount', 'inetOrgPerson', 'organizationalPerson']
OPEN_LDAP | user | display_name | | displayName
OPEN_LDAP | user | distinguished_name | | entryDN
OPEN_LDAP | user | email_address | | emailAddress
OPEN_LDAP | user | first_name | | givenName
OPEN_LDAP | user | last_name | | sn
OPEN_LDAP | user | object_class | | objectClass
OPEN_LDAP | user | object_sid | | entryUUID
OPEN_LDAP | user | user_principal_name | | userPrincipalName
OPEN_LDAP | user | username | | ['uid', 'cn']
Lists attributes for LDAP servers alongside their associated values, object type and server type.
End Point: /api/v3/robin_server/ldap-attributes/
Method: GET
URL Parameters: None
Data Parameters:
server_type: <server_type>- Utilizing this parameter within the payload by specifying a string representing a server type, results in the response being filtered by the given LDAP server type. Valid choices for this attribute include: ‘OPEN_LDAP’, ‘ACTIVE_DIRECTORY’, and ‘GOOGLE_CLOUD’.object_type: <object_type>- Utilizing this parameter within the payload by specifying a string representing a object type, results in the response being filtered by the given LDAP object type. Valid choices for this attribute include: ‘user’ and ‘group’.
Port: RCM Port (default value is 29442)
Headers:
Authorization: <auth_token>: Authorization token to identify which user is sending the request. The token can be acquired from the login API.
Success Response Code: 200
Error Response Code: 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error), 400 (Invalid API Usage Error)
Example Response:
Output
{
"items":[
{
"custom":false,
"attribute_name":"distinguished_name",
"value":"distinguishedName",
"object_type":"",
"server_type":"ACTIVE_DIRECTORY"
},
{
"custom":false,
"attribute_name":"object_class",
"value":"objectClass",
"object_type":"",
"server_type":"ACTIVE_DIRECTORY"
},
{
"custom":false,
"attribute_name":"class_list",
"value":[
"group",
"groupOfNames"
],
"object_type":"group",
"server_type":"ACTIVE_DIRECTORY"
},
{
"custom":false,
"attribute_name":"distinguished_name",
"value":"distinguishedName",
"object_type":"group",
"server_type":"ACTIVE_DIRECTORY"
},
{
"custom":false,
"attribute_name":"group_name",
"value":"name",
"object_type":"group",
"server_type":"ACTIVE_DIRECTORY"
},
{
"custom":false,
"attribute_name":"members",
"value":[
"member"
],
"object_type":"group",
"server_type":"ACTIVE_DIRECTORY"
},
{
"custom":false,
"attribute_name":"object_class",
"value":"objectClass",
"object_type":"group",
"server_type":"ACTIVE_DIRECTORY"
},
{
"custom":false,
"attribute_name":"object_sid",
"value":"objectSid",
"object_type":"group",
"server_type":"ACTIVE_DIRECTORY"
},
{
"custom":false,
"attribute_name":"class_list",
"value":[
"person",
"organizationalPerson",
"user"
],
"object_type":"user",
"server_type":"ACTIVE_DIRECTORY"
},
{
"custom":false,
"attribute_name":"display_name",
"value":"displayName",
"object_type":"user",
"server_type":"ACTIVE_DIRECTORY"
},
{
"custom":false,
"attribute_name":"distinguished_name",
"value":"distinguishedName",
"object_type":"user",
"server_type":"ACTIVE_DIRECTORY"
},
{
"custom":false,
"attribute_name":"email_address",
"value":"mail",
"object_type":"user",
"server_type":"ACTIVE_DIRECTORY"
},
{
"custom":false,
"attribute_name":"first_name",
"value":"givenName",
"object_type":"user",
"server_type":"ACTIVE_DIRECTORY"
},
{
"custom":false,
"attribute_name":"last_name",
"value":"sn",
"object_type":"user",
"server_type":"ACTIVE_DIRECTORY"
},
{
"custom":false,
"attribute_name":"object_class",
"value":"objectClass",
"object_type":"user",
"server_type":"ACTIVE_DIRECTORY"
},
{
"custom":false,
"attribute_name":"object_sid",
"value":"objectSid",
"object_type":"user",
"server_type":"ACTIVE_DIRECTORY"
},
{
"custom":false,
"attribute_name":"user_principal_name",
"value":"userPrincipalName",
"object_type":"user",
"server_type":"ACTIVE_DIRECTORY"
},
{
"custom":false,
"attribute_name":"username",
"value":[
"sAMAccountName"
],
"object_type":"user",
"server_type":"ACTIVE_DIRECTORY"
},
{
"custom":false,
"attribute_name":"distinguished_name",
"value":"entryDN",
"object_type":"",
"server_type":"OPEN_LDAP"
},
{
"custom":false,
"attribute_name":"object_class",
"value":"objectClass",
"object_type":"",
"server_type":"OPEN_LDAP"
},
{
"custom":false,
"attribute_name":"class_list",
"value":[
"posixGroup",
"groupOfNames",
"groupOfUniqueNames"
],
"object_type":"group",
"server_type":"OPEN_LDAP"
},
{
"custom":false,
"attribute_name":"distinguished_name",
"value":"entryDN",
"object_type":"group",
"server_type":"OPEN_LDAP"
},
{
"custom":false,
"attribute_name":"group_name",
"value":"cn",
"object_type":"group",
"server_type":"OPEN_LDAP"
},
{
"custom":false,
"attribute_name":"members",
"value":[
"uniqueMember",
"member"
],
"object_type":"group",
"server_type":"OPEN_LDAP"
},
{
"custom":false,
"attribute_name":"object_class",
"value":"objectClass",
"object_type":"group",
"server_type":"OPEN_LDAP"
},
{
"custom":false,
"attribute_name":"object_sid",
"value":"objectSid",
"object_type":"group",
"server_type":"OPEN_LDAP"
},
{
"custom":false,
"attribute_name":"class_list",
"value":[
"posixAccount",
"inetOrgPerson",
"organizationalPerson"
],
"object_type":"user",
"server_type":"OPEN_LDAP"
},
{
"custom":false,
"attribute_name":"display_name",
"value":"displayName",
"object_type":"user",
"server_type":"OPEN_LDAP"
},
{
"custom":false,
"attribute_name":"distinguished_name",
"value":"entryDN",
"object_type":"user",
"server_type":"OPEN_LDAP"
},
{
"custom":false,
"attribute_name":"email_address",
"value":"emailAddress",
"object_type":"user",
"server_type":"OPEN_LDAP"
},
{
"custom":false,
"attribute_name":"first_name",
"value":"givenName",
"object_type":"user",
"server_type":"OPEN_LDAP"
},
{
"custom":false,
"attribute_name":"last_name",
"value":"sn",
"object_type":"user",
"server_type":"OPEN_LDAP"
},
{
"custom":false,
"attribute_name":"object_class",
"value":"objectClass",
"object_type":"user",
"server_type":"OPEN_LDAP"
},
{
"custom":false,
"attribute_name":"object_sid",
"value":"entryUUID",
"object_type":"user",
"server_type":"OPEN_LDAP"
},
{
"custom":false,
"attribute_name":"user_principal_name",
"value":"userPrincipalName",
"object_type":"user",
"server_type":"OPEN_LDAP"
},
{
"custom":false,
"attribute_name":"username",
"value":[
"uid",
"cn"
],
"object_type":"user",
"server_type":"OPEN_LDAP"
}
]
}
8.8.9. Update LDAP Attribute¶
Run the following command to update an LDAP attribute:
# robin ldap update-attribute <server_type> <object_type> <attribute_name> <value>
|
LDAP server type. Valid choices are ‘ACTIVE_DIRECTORY’, ‘OPEN_LDAP’, and ‘GOOGLE_CLOUD’ |
|
LDAP object type. Valid choices are ‘user’, ‘group’, and ‘none’ |
|
LDAP attribute name |
|
LDAP attribute value |
Example:
# robin ldap update-attribute OPEN_LDAP group members member,uniqueMember
Successfully updated one or more LDAP attributes
Note
An LDAP attribute can apply globally (for a given server type) or it can
apply to a particular object type (user or group). When updating a
global attribute, specify none for object type.
Updates an LDAP attribute to a given value.
End Point: /api/v3/robin_server/ldap-attributes/
Method: POST
URL Parameters: None
Data Parameters:
server_type: <server_type>- This mandatory field within the payload specifies the type of LDAP server. Valid choices are ‘OPEN_LDAP’, ‘ACTIVE_DIRECTORY’, and ‘GOOGLE_CLOUD’.object_type: <object_type>- This mandatory field within the payload specifies the object type of the attribute to update. Valid choices are ‘user’, ‘group’, and ‘none’. Note, ‘none’ should be specified when updating a global attribute.attribute_name: <attribute_name>- This mandatory field within the payload specifies the name of the attribute to update.value: <value>- This mandatory field within the payload specifies the value to be set for the aforementioned attribute.
Port: RCM Port (default value is 29442)
Headers:
Authorization: <auth_token>: Authorization token to identify which user is sending the request. The token can be acquired from the login API.
Success Response Code: 200
Error Response Code: 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error), 400 (Invalid API Usage Error)
Example Response:
Output
{
"message":"Successfully updated one or more LDAP attributes\n"
}
8.8.10. Reset LDAP Attribute¶
Run the following command to reset an LDAP attribute to its default value:
# robin ldap reset-attribute <server_type> <object_type> <attribute_name>
|
LDAP server type. Valid choices are ‘ACTIVE_DIRECTORY’, ‘OPEN_LDAP’, and ‘GOOGLE_CLOUD’ |
|
LDAP object type. Valid choices are ‘user’, ‘group’, and ‘none’ |
|
LDAP attribute name |
Example:
# robin ldap reset-attribute OPEN_LDAP group members
Reset LDAP attribute 'OPEN_LDAP:group:members'
Note
An LDAP attribute can apply globally (for a given server type) or it can
apply to a particular object type (user or group). When resetting a
global attribute, specify none for object type.
Resets an LDAP attribute to its default value.
End Point: /api/v3/robin_server/ldap-attributes/
Method: DELETE
URL Parameters: None
Data Parameters:
server_type: <server_type>- This mandatory field within the payload specifies the type of LDAP server. Valid choices are ‘OPEN_LDAP’, ‘ACTIVE_DIRECTORY’, and ‘GOOGLE_CLOUD’.object_type: <object_type>- This mandatory field within the payload specifies the object type of the attribute to reset. Valid choices are ‘user’, ‘group’, and ‘none’. Note, ‘none’ should be specified when resetting a global attribute.attribute_name: <attribute_name>- This mandatory field within the payload specifies the name of the attribute to reset.
Port: RCM Port (default value is 29442)
Headers:
Authorization: <auth_token>: Authorization token to identify which user is sending the request. The token can be acquired from the login API.
Success Response Code: 200
Error Response Code: 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error), 400 (Invalid API Usage Error)
Example Response:
Output
{
"message":"Reset LDAP attribute 'OPEN_LDAP:group:members'\n"
}
8.9. OpenID Connect identity providers¶
Robin CNP supports external OpenID Connect (OIDC) identity providers, which enable single sign-on (SSO) across multiple web properties and applications. You can authenticate using Keycloak or any OAuth 2.0 device flow-compatible providers in addition to local, LDAP, and OpenShift authentication.
Administrators can register the following identity provider types:
Type |
Description |
|---|---|
|
Integrates a Keycloak server for user and group management, user import, and Tenant User Group (TUG) synchronization. |
|
Supports standard OAuth 2.0/OIDC flows, including Authorization Code Flow (browser-based) and Device Flow. |
|
A pre-configured provider type for Google OIDC services. |
|
Integrates with traditional LDAP directory services for authentication and user/group synchronization. |
8.9.1. Identity provider prerequisites¶
Before you register an external identity provider, ensure that you meet the following general and type-specific requirements.
8.9.1.1. General requirements¶
The following prerequisites apply to all OIDC provider types:
Client credentials: You must create a registered application or client within the identity provider to obtain a
client-idandclient-secret.Network connectivity: Robin master nodes must have outbound network connectivity to the provider’s endpoints such as the Keycloak base URL, Google OAuth endpoints, or custom generic URIs.
SSL/TLS trust: If the identity provider uses a certificate signed by a private or internal Certificate Authority (CA), you must provide the PEM-encoded CA certificate to the
--ca-certflag during registration.
8.9.1.2. Keycloak-specific requirements¶
Keycloak integration supports advanced features such as group browsing and Tenant User Group (TUG) synchronization. These features require the following additional configuration:
Keycloak server: A running Keycloak server (tested with Keycloak 24.0.5).
Realm: A specific Keycloak realm configured to manage the users and groups intended for Robin integration.
Admin client: To enable
list-groups,import-group, and TUG synchronization, you must create a dedicated admin client in the realm. This client requires administrative API access (typically therealm-managementroles) to allow Robin to query the Keycloak directory.Sync enabled: You must register the provider with the
--sync-enabled trueflag to use the admin client for background synchronization tasks.
8.9.1.3. Google and generic OAuth requirements¶
Google and generic OAuth providers are primarily used for authentication and login flows.
Device flow application type: If you use the Device Authorization Grant (used for Google authentication and ephemeral logins), you must configure the application created in the provider (such as the Google Cloud Console) as a TV and Limited Input devices application type. Standard Web or Desktop application types might not support the
device_codegrant required for the CLI login flow.IPv4 connectivity: For Google OIDC, the cluster must have IPv4 connectivity to reach
oauth2.googleapis.com.
Generic OAuth only
Endpoint mapping (generic only): For
generic_oauth_provider, you must identify the specific URIs for authorization, tokens, and user information. You can typically find these at the provider’s discovery endpoint:https://<IDP-HOST>/.well-known/openid-configuration.
Note
TUG synchronization and group browsing are supported only for keycloak_provider and ldap_provider. Generic and Google providers do not use an admin client and are intended for authentication-only or ephemeral login workflows.
8.9.2. Configuration matrix¶
The following table identifies the mandatory options for specific provider types.
Type |
Discovery / Required Endpoints |
|---|---|
|
Requires |
|
Requires manual configuration of endpoints: |
|
Endpoints are pre-configured by Robin. This typically requires only |
|
Requires |
Synchronization
For any identity provider, set --sync-enabled true to allow users and groups to be explicitly imported or synchronized from that provider. The default is false, which limits the provider to authentication.
8.9.3. Add an identity provider¶
To add an identity provider (IdP), use the robin identity-provider add command (alias: robin idp add). By default, providers are used for authentication only. To enable user/group imports, you must set --sync-enabled true.
Syntax
robin identity-provider add <name> <type> [options]
Arguments
Argument |
Description |
|---|---|
|
The name of the identity provider. |
|
The type of identity provider. Supported types include |
Common options
These options apply to most provider types or control general behavior.
Option |
Description |
Supported types |
|---|---|---|
|
Enables the explicit import or synchronization of users and groups. The default value is |
All |
|
Verifies the TLS certificate of identity provider (IdP) endpoints. The default value is |
All OIDC |
|
The PEM-encoded CA certificate used to trust IdP TLS connections. |
All OIDC |
|
A comma-separated list of email domains used to restrict authorization. |
All OIDC |
OAuth 2.0 and OIDC core options
These options are required for basic OIDC authentication.
Option |
Description |
Supported types |
|---|---|---|
|
The client ID for the identity provider. |
OIDC types |
|
The client secret for the identity provider. |
OIDC types |
|
The OAuth 2.0 scope, such as |
OIDC types |
|
The URL for the token endpoint. |
OIDC types |
|
The URL for the user information endpoint. |
OIDC types |
|
The user ID field, such as |
OIDC types |
Keycloak-specific options
These options are specific to the keycloak_provider type.
Option |
Description |
|---|---|
|
The name of the Keycloak realm. This option is required. |
|
The base URL for the Keycloak server. This option is required. |
|
The admin client ID required for listing groups and TUG synchronization. |
|
The admin client secret required for administrative API operations. |
Generic OAuth and Device Flow options
These options are used for manual endpoint mapping or specific grant types.
Option |
Description |
|---|---|
|
The OAuth grant type for the device flow, such as |
|
The URL for the device authorization endpoint. This option is for the Device Flow only. |
|
The URL for the authorization endpoint. This option is required for the Authorization Code Flow. |
|
The Robin callback URL. This option is required for the Authorization Code Flow. |
|
Enables PKCE for the Authorization Code Flow. The default value is |
mTLS and LDAP options
These options are for mutual TLS (mTLS) or traditional directory services.
Option |
Description |
|---|---|
|
The PEM-encoded client certificate for mTLS. Use this option with |
|
The PEM-encoded client private key for mTLS. Use this option with |
|
The name of the LDAP server. This option is required. |
Example: Register a Keycloak provider (full configuration)
robin identity-provider add mykeycloak keycloak_provider \
--realm robin-test \
--base-url http://10.0.8.195:8080 \
--client-id robin-user \
--client-secret usersecret123 \
--grant-type password \
--code-uri http://10.0.8.195:8080/realms/robin-test/protocol/openid-connect/auth \
--token-uri http://10.0.8.195:8080/realms/robin-test/protocol/openid-connect/token \
--userinfo-uri http://10.0.8.195:8080/realms/robin-test/protocol/openid-connect/userinfo \
--admin-client-id robin-admin \
--admin-client-secret robinsecret123
Identity provider 'mykeycloak' was added
Example: Keycloak with Sync enabled
robin identity-provider add mykeycloak keycloak_provider \
--client-id robin-client \
--client-secret secret123 \
--realm robin-test \
--base-url `http://10.0.8.195:8080?__atl_rovo=disable_public_resolution` \
--token-uri `http://10.0.8.195:8080/realms/robin-test/protocol/openid-connect/token?__atl_rovo=disable_public_resolution` \
--userinfo-uri `http://10.0.8.195:8080/realms/robin-test/protocol/openid-connect/userinfo?__atl_rovo=disable_public_resolution` \
--code-uri `http://10.0.8.195:8080/realms/robin-test/protocol/openid-connect/auth?__atl_rovo=disable_public_resolution` \
--sync-enabled true \
--admin-client-id robin-admin \
--admin-client-secret adminsecret123
Example: Generic OAuth (Authorization Code Flow)
robin identity-provider add okta generic_oauth_provider \
--client-id 0oa1abc2def3 \
--client-secret secret456 \
--authorization-uri https://dev-123.okta.com/oauth2/v1/authorize \
--token-uri https://dev-123.okta.com/oauth2/v1/token \
--redirect-uri https://robin.example.com/api/v3/robin_server/oauth/callback
Example: Register a generic oauth provider (Google)
robin identity-provider add google generic_oauth_provider \
--client-id "21412759982-m0jgdr5ul736gij1se8ft67auf2rgbm2.apps.googleusercontent.com" \
--client-secret "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" \
--scope "email profile" \
--grant-type "urn:ietf:params:oauth:grant-type:device_code" \
--code-uri "https://oauth2.googleapis.com/device/code" \
--token-uri "https://oauth2.googleapis.com/token" \
--userinfo-uri "https://www.googleapis.com/oauth2/v3/userinfo" \
--user-id-field sub \
--email-domains robin.io
For generic oauth provider prerequisites and ephemeral login workflow, see Ephemeral User Login.
8.9.4. List Identity Providers¶
To list identity providers, use the robin identity-provider list command.
Syntax
robin identity-provider list <name> [options]
Arguments
Argument |
Description |
|---|---|
|
The name of the identity provider. |
Options
Option |
Description |
|---|---|
|
The ID of the identity provider. |
|
The type of the identity provider. |
|
Displays additional details for the identity provider. |
|
Displays the output in JSON format. |
Example
robin identity-provider list
ID | Name | Type | Email Domains
---+------------+----------------------+---------------
5 | mykeycloak | keycloak_provider |
6 | google | generic_oauth_provider | robin.io
Use --json for detailed output including client IDs, URIs, and realm configuration.
8.9.5. Browse Groups in a Keycloak Provider¶
To list groups from an identity provider, use the robin identity-provider list-groups command.
Syntax
robin identity-provider list-groups <name> [group_name] [options]
Arguments
Argument |
Description |
|---|---|
|
The name of the identity provider. |
|
The exact group name to look up. This argument is optional. |
Options
Option |
Description |
|---|---|
|
A search filter for group names. |
|
Includes a list of group members in the output. |
|
Invalidates the provider browse cache before listing. This option applies to LDAP providers only. |
|
Displays the output in JSON format. |
Examples
List all groups:
robin identity-provider list-groups mykeycloak
Search for groups by name:
robin identity-provider list-groups mykeycloak --search dev
List members of a specific group:
robin identity-provider list-groups mykeycloak dev-team --members
8.9.6. Import Users from an Identity Provider¶
To import users from an identity provider and add them to a tenant, use the robin identity-provider import-users command. Users are authenticated through the identity provider (IdP), and their details, such as name and email, are fetched automatically.
Syntax
robin identity-provider import-users <provider> <users> <tenant> <role> <capabilities> [options]
Arguments
Argument |
Description |
|---|---|
|
The name of the identity provider. |
|
A comma-separated list of usernames to import. |
|
The tenant to which the imported users are added. |
|
The user role assigned to each imported user within the tenant. |
|
A comma-separated list of tenant-specific capabilities to assign to each user. This argument is optional. If you don’t specify this, the system assigns full capabilities for the specified role. |
Example
robin identity-provider import-users mykeycloak alice,bob keycloak-lab user --wait
Job: 123 Name: IdPUserImportMulti State: COMPLETED Error: 0
Successfully processed 2 user(s): 2 newly imported (alice, bob)
Verify the imported user:
robin user info alice
The user record will show Authentication: keycloak and Identity Provider: mykeycloak.
8.9.7. Import Users from a Group (Without TUG)¶
To fetch all members of an identity provider (IdP) group and import them as individual users, use the robin identity-provider import-group-users command.
Note
This command doesn’t create a Tenant User Group (TUG). To create a TUG, use the robin identity-provider import-group command with the --sync flag.
Syntax
robin identity-provider import-group-users <provider> <group_id> <tenant> <role> <capabilities> [options]
Arguments
Argument |
Description |
|---|---|
|
The name of the identity provider. |
|
The external ID or name of the group. |
|
The tenant to which the imported users are added. |
|
The user role assigned to each imported user within the tenant. |
|
A comma-separated list of tenant-specific capabilities to assign to each user. This argument is optional. If you don’t specify this, the system assigns full capabilities for the specified role. |
Options
Option |
Description |
|---|---|
|
A comma-separated list of usernames to exclude from the import. |
|
Waits for all import jobs to complete. |
Example
robin identity-provider import-group-users mykeycloak ops-team keycloak-lab user --wait
8.9.8. Authenticate via an Identity Provider¶
Imported users can log in using their identity provider credentials instead of a Robin password.
To log in to Robin CNP using an identity provider (IdP), use the robin login command with the --identity-provider (or --idp) flag.
Syntax
robin login <username> --identity-provider <provider-name>
The --idp flag is a supported alias:
robin login <username> --idp <provider-name>
Arguments
Argument |
Description |
|---|---|
|
Required. The name of the user. |
Options
Option |
Description |
|---|---|
|
The password for the user. |
|
Initiates a password reset for the user. |
|
The new password to set during a password reset. |
|
The name of the tenant to log in to. |
|
The namespace to use for the session. |
|
The user group to use for the session. |
|
The name of the identity provider to use for authentication. |
|
The request ID for the login attempt. |
Example
robin login alice --identity-provider mykeycloak
Behavior:
On first login, you will be prompted for your cluster password to link your external identity to your cluster account.
Subsequent logins bypass the password prompt.
Each external identity can only be linked to one cluster account.
For ephemeral user login via the device flow, see Ephemeral User Login.
8.9.9. Update an identity provider¶
To modify the configuration of an existing provider, use the robin identity-provider update command. This command lets you rotate client secrets, update endpoint URIs, or enable or disable synchronization features without re-registering the provider.
Syntax
robin identity-provider update <name> [options]
Arguments
Argument |
Description |
|---|---|
|
The name of the identity provider to update. |
Options
Option |
Description |
|---|---|
|
Updates the OAuth client ID. |
|
Updates the OAuth client secret. |
|
Enables or disables user and group synchronization ( |
|
Enables or disables TLS certificate verification ( |
|
Updates the comma-separated list of allowed email domains. |
Clear configuration values
To remove an existing configuration value, such as a CA certificate or admin credentials, pass an empty string ("") to the corresponding flag. You can use this method with the following flags:
--authorization-uri,--redirect-uri--ca-cert,--client-cert,--client-key--admin-client-id,--admin-client-secret--email-domains
Example: Enable synchronization and update admin credentials
robin identity-provider update mykeycloak \
--sync-enabled true \
--admin-client-id "robin-admin-v2" \
--admin-client-secret "newsecret789"
8.9.10. Remove an identity provider¶
To unregister an identity provider from the Robin cluster, use the robin identity-provider remove command (or the delete alias).
Syntax
robin identity-provider remove <name> [options]
Arguments
Argument |
Description |
|---|---|
|
The name of the identity provider. |
Options
Option |
Description |
|---|---|
|
The ID of the identity provider. |
|
Required. Confirms the deletion of the identity provider. If you omit this flag, Robin returns an audit report only and does not remove the provider. |
Example
robin identity-provider remove mykeycloak --force
8.9.11. List users from an identity provider¶
To browse users available in an external identity provider, use the robin identity-provider list-users command. Use this command to verify that a user exists and to retrieve their exact username or email address before you perform an import operation.
robin identity-provider list-users <name> [username] [options]
Arguments
Argument |
Description |
|---|---|
|
The name of the identity provider to query. |
|
The exact username of a specific user. This argument is optional. |
Options
Option |
Description |
|---|---|
|
A search filter for usernames or email addresses. |
|
Filters results by an exact email address. |
|
The maximum number of results to return. The default value is |
|
Displays the output in JSON format. |
Example: Search for a user by name
robin identity-provider list-users mykeycloak --search "anson" --max 5
8.10. Ephemeral users¶
Ephemeral users are external users who log in to a Robin CNP cluster for a limited period of time and perform operations as regular users. They are temporary users and do not have actual user accounts in the Robin CNP cluster; hence, no user records are stored in the users table of the cluster’s database.
Ephemeral users do not perform operations directly in a cluster. Instead, they map to a permanent cluster user who perform operations on their behalf. Before logging into the Robin CNP cluster, they must authenticate themselves through an external identity provider.
Points to consider for Ephemeral users
Ephemeral users exist only for the duration of their login session.
The roles and permissions of an ephemeral user are the same as the underlying permanent cluster user.
Operations are performed by the underlying cluster user on behalf of Ephemeral users.
Any objects created by an Ephemeral user are owned by the underlying cluster user.
8.10.1. Identity providers¶
An identity provider stores and manages digital identities for users. It verifies users’ identities and authenticates them when accessing applications. Ephemeral users authenticate themselves through external identity providers.
Robin CNP supports OAuth 2.0 Device Authorization Grant (Device Flow) that enables devices with no browser or limited input capability to obtain an access token. For more information, see OAuth 2.0 Device Authorization Grant.
Robin CNP supports Google as an identity provider. For more information, see Google OAuth 2.0 Device Flow.
8.10.1.1. Add an identity provider¶
You can add an identity provider such as Google. It stores digital identities for users and authenticates them using their identities.
Run the following command to add an identity provider:
# robin identity-provider add <name> <type>
--client-id <client_id>
--client-secret <client_secret>
--scope <scope>
--grant-type <grant_type>
--code-uri <code_uri>
--token-uri <token_uri>
--userinfo-uri <userinfo_uri>
--user-id-field <user_id_field>
--email-domains <email_domains>
Parameter |
Description |
|---|---|
|
Name of identity provider. |
|
Type of identity provider. A valid option is |
|
The unique identifier for the client application, issued by the authorization server during registration. It informs the authorization server which application is making the request. |
|
The client secret for authentication at the token endpoint if the client is confidential. For most devices, clients are public. |
|
A space-delimited string of the desired access scopes (for example, email profile, read_calendar, write_data). This informs the authorization server what kind of access the device application is requesting on behalf of the user. |
|
It must be set to |
|
The authorization server URL where device authorization requests are sent (for example, /device/code). |
|
The authorization server URL where the device application polls for the access token (for example, /oauth/token). |
|
The user verification URI. |
|
The name of the attribute containing a unique ID for the user (for example, subject or sub). |
|
Comma-separated list of email domains to restrict authorization to, if the identity provider hosts multiple accounts for users. |
Example
# robin identity-provider add google device_flow_provider --client-id "2141275-m0jgdr5ul736gij1se8f.apps.googleusercontent.com" --client-secret "GOC-q3Xcp-mwU_4tt-DstK3q8" --scope "email profile" --grant-type "urn:ietf:params:oauth:grant-type:device_code" --code-uri "https://oauth2.googleapis.com/device/code" --token-uri "https://oauth2.googleapis.com/token" --userinfo-uri "https://www.googleapis.com/oauth2/v3/userinfo" --user-id-field sub --email-domains google.com
Identity provider 'google' was added
8.10.1.2. View identity providers¶
You can view the list of identity providers available in your cluster.
To view identity provider details, run the following command:
# robin identity-provider list [<name>]
--id <identity_provider_id>
--type <provider_type>
--full
--json
Parameter |
Description |
|---|---|
|
Name of Identity Provider. |
|
ID of Identity Provider. |
|
Type of Identity Provider. |
|
Display additional details of the identity provider. |
|
Output in JSON format. |
Example
# robin identity-provider list
ID | Name | Type | Email Domains
---+--------+----------------------+---------------
1 | google | device_flow_provider | google.com
# robin identity-provider list --full
ID | Name | Type | Email Domains
---+--------+----------------------+---------------
1 | google | device_flow_provider | google.com
client_id: 2141275-m0jgdr5ul736gij1se8f.apps.googleusercontent.com
client_secret: <REDACTED>
scope: email profile
grant_type: urn:ietf:params:oauth:grant-type:device_code
code_uri: https://oauth2.googleapis.com/device/code
token_uri: https://oauth2.googleapis.com/token
userinfo_uri: https://www.googleapis.com/oauth2/v3/userinfo
user_id_field: sub
8.10.1.3. Remove an identity provider¶
You can remove the existing identity provider from your cluster.
To remove an identity provider, run the following command:
# robin identity-provider remove [<name>]
--id <identity_provider_ID>
--force
Parameter |
Description |
|---|---|
|
Name of Identity Provider. |
|
ID of Identity Provider. |
|
Delete the Identity Provider forcefully. |
Example
# robin identity-provider remove google
Identity provider 'google' was deleted
8.10.1.4. Cluster user for Ephemeral user group¶
A cluster user is a dedicated user in the Robin CNP cluster, which acts as a proxy for all users of the Ephemeral user group.
A cluster user has the following characteristics:
Is bound to a single ephemeral user group.
Can only be a member of one tenant, which is bound to the ephemeral user group.
Cannot be used as a regular user to log in to the Robin CNP cluster, as the login is disabled for it.
Has a namespace that can only be changed by a superadmin user through the ephemeral user group API.
8.10.2. Ephemeral user group¶
An Ephemeral user group is a group of external users that map to a single cluster user. Ephemeral user groups allow external users to log in to the cluster through an external identity provider. After authentication, users can perform cluster operations based on the capabilities of the cluster users bound to the group.
An Ephemeral user group has the following characteristics:
Links to one or more identity providers.
Is bound to a single tenant.
Has a dedicated cluster user that acts as a proxy for all users of a group.
All users of an Ephemeral user group share the same cluster user’s tenant role, capabilities, and access permissions.
When an Ephemeral user initiates an operation, the associated cluster user performs this operation. Hence, any objects created from this operation will be owned by the cluster user.
To create a cluster user for Ephemeral user group, run the following command:
# robin user add <username> <tenant> <tenant_role> --password <password>
Example
# robin user add google Administrators superadmin --password Abc123
Successfully added user 'google'
For more information about robin user add command, see Add a user.
8.10.2.1. Add an ephemeral user group¶
You can add an Ephemeral user group to your cluster.
Run the following command to add the Ephemeral user group:
# robin user-group add <name> <type> <tenant> <identity_provider>
--cluster-user <cluster_user>
Parameter |
Description |
|---|---|
|
Name of the user group. |
|
Type of the user group. Default value: ephemeral_user_group. |
|
Name of the tenant to which the Ephemeral user group is bound. |
|
Name of the identity provider. |
|
Name of the cluster user. |
Example
# robin user-group add google ephemeral_user_group Administrators google --cluster-user google
User group 'google' was added
8.10.2.2. View ephemeral user groups¶
You can view the list of the ephemeral user groups available in your cluster.
To view the list of the ephemeral user group, run the following command:
# robin user-group list [<name>]
--group-type <group_type>
--group-id <group_id>
--tenant <tenant>
--tenant-id <tenant_id>
--entity-provider <entity_provider>
--entity-provider-id <entity_provider_id>
--full
--json
Parameter |
Description |
|---|---|
|
Name of Ephemeral user group. |
|
Type of Ephemeral user group. |
|
ID of Ephemeral user group. |
|
Name of tenant the Ephemeral user group is bound to. |
|
ID of the tenant the Ephemeral user group is bound to. |
|
Name of entity provider the Ephemeral user group is bound to. |
|
ID of the entity provider the Ephemeral user group is bound to. |
|
Display additional details of Ephemeral user group. |
|
Output in JSON format. |
Example
# robin user-group list --full
ID | Name | Type | Tenant | Tenant ID | Identity Provider | Identity Provider ID | Identity Provider Type
---+--------+----------------------+----------------+-----------+-------------------+----------------------+------------------------
1 | google | ephemeral_user_group | Administrators | 1 | google | 1 | device_flow_provider
cluster_user: google
cluster_user_id: 12
8.10.2.3. Remove an ephemeral user group¶
You can remove the existing Ephemeral user group from your cluster.
To remove an existing Ephemeral user group, run the following command:
# robin user-group remove [<name>]
--id <group_id>
--force
Parameter |
Description |
|---|---|
|
Name of Ephemeral user group. |
|
ID of Ephemeral user group. |
|
Delete the Ephemeral user group forcefully. |
Example
# robin user-group remove google
User group 'google' was added
8.10.3. Auth sessions¶
Whenever a user initiates authentication using an identity provider, an Auth session is created. This auth session contains all of the attributes needed for authentication of the user by the identity provider. Auth sessions are created for users who are logging in as ephemeral users and cluster users who elect to authenticate through an external identity provider.
8.10.4. Steps to create ephemeral user group for ephemeral users¶
As an admin, you need to create an ephemeral user group for a user to log in as an ephemeral user.
Complete the following steps to create an ephemeral user group:
Add an identity provider:
# robin identity-provider add <name> <type> --client-id <client_id> --client-secret <client_secret> --scope <scope> --grant-type <grant_type> --code-uri <code_uri> --token-uri <token_uri> --userinfo-uri <userinfo_uri> --user-id-field <user_id_field> --email-domains <email_domains>Example
# robin identity-provider add google device_flow_provider --client-id "2141275-m0jgdr5ul736gij1se8f.apps.googleusercontent.com" --client-secret "GOC-q3Xcp-mwU_4tt-DstK3q8" --scope "email profile" --grant-type "urn:ietf:params:oauth:grant-type:device_code" --code-uri "https://oauth2.googleapis.com/device/code" --token-uri "https://oauth2.googleapis.com/token" --userinfo-uri "https://www.googleapis.com/oauth2/v3/userinfo" --user-id-field sub --email-domains google.com Identity provider 'google' was added
Create a cluster user for Ephemeral user group:
# robin user add <username> <tenant> <tenant_role> --password <password>Example
# robin user add google Administrators superadmin --password Abc123 Successfully added user 'google'
Create an Ephemeral user group:
# robin user-group add <name> <type> <tenant> <identity_provider> --cluster-user <cluster_user>Example
# robin user-group add google ephemeral_user_group Administrators google --cluster-user google User group 'google' was added
8.10.5. Log in as an ephemeral user¶
You can log in to your cluster as an ephemeral user. Ephemeral users are external users who log in to a cluster for a limited period of time and perform operations as regular users.
Prerequisites
An identity provider must be added.
A cluster user must be created for ephemeral user group.
An ephemeral user group must be created.
Once an admin creates a cluster user and an ephemeral user group, you can log in as an ephemeral user.
To log in as an ephemeral user, complete the following steps:
Run the following command to log in:
# robin login --user-group googleExample
# robin login --user-group google To authorize this login session, please access the following URL: https://www.google.com/device and enter the following user code: PMN-FBK-SPTX After authenticating and authorizing, issue the following command to complet the login: robin login --request-id 8089ca24-77c6-11f0-b0f7-25ffedd98723
Go to https://www.google.com/device and enter the user code displayed in the step 1 output.
After you authenticate, run the
robin logincommand displayed in step 1 to log in as an ephemeral user:# robin login --request-id <request-id>Example
# robin login --request-id 8089ca24-77c6-11f0-b0f7-25ffedd98723 Ephemeral user 'abc@google.com' is logged into tenant 'Administrators' as user 'google'
8.10.6. Verify login session¶
After you log in to your cluster, you can verify whether you logged in as an ephemeral user.
To verify the login session, run the following command:
# robin whoami
Example
# robin whoami
username: google
tenant: Administrators
tenants: ['Administrators']
namespace: t001-u000012
session_expires: 2025-08-13T14:55:11
ephemeral_user: abc@google.com
8.10.7. View ephemeral users¶
As an admin, you can view which ephemeral users have logged in to the cluster:
To view ephemeral users who logged in, run the following command:
# robin ephemeral-user list
--subject <subject>
--username <username>
--ephemeral-user-group <ephemeral_user_group>
--json
Parameter |
Description |
|---|---|
|
ID of ephemeral user. |
|
Username of ephemeral user. |
|
Name of ephemeral user group. |
|
Output in JSON format. |
Example
# robin ephemeral-user list
ID | Subject | Username | Ephemeral User Group | Session ID
---+-----------------------+--------------+----------------------+--------------------------------------
1 | 117716179804070531521 | abc@google.com | google | 00390110-77c7-11f0-8f1b-3d6c8b674ae6
8.10.8. View audit records¶
You can view the audit records for a user. This command shows an ephemeral user and the associated ephemeral user group values in user audit records.
To view audit records, run the following command:
# robin user-audit list
--exec-user <exec_user>
--exec-tenant <exec_tenant>
--owner-user <owner_user>
--owner-tenant <owner_tenant>
--ephemeral-user <ephemeral_user>
--ephemeral-user-group <ephemeral_user_group>
--id <record_id>
--object-type <object_type>
--operation <operation>
--result <result>
--full
--json
Parameter |
Description |
|---|---|
|
Filter based on the username for the user who initiated the operation. This option cannot be used with |
|
Filter based on the tenant name for the user who initiated the operation. This option cannot be used with |
|
Filter based on the username for the user who initiated the operation. This option cannot be used with |
|
Filter based on the tenant name for the user who initiated the operation. This option cannot be used with |
|
Filter based on the username of the ephemeral user who initiated the operation. |
|
Filter based on the name of the ephemeral user group. |
|
Filter based on a specific record ID. |
|
Filter based on type of object. |
|
Filter based on type of operations. |
|
Filter based on the result of operations. |
|
Display additional information about the audit records. |
|
Output in JSON format. |
Example
# robin user-audit list --id 132 --full
Id | Timestamp | IP Addr | Exec User | Exec Tenant | Owner User | Owner Tenant | Object Type | Operation | Result
----+--------------------------+-----------+-----------+----------------+------------+--------------+-------------+-----------+---------
132 | August 12, 2025 14:55:12 | 127.0.0.1 | google | Administrators | | | USER | login | success
ephemeral_user: abc@google.com
ephemeral_user_group: google
object_attributes: {'request_id': '8089ca24-77c6-11f0-b0f7-25ffedd9', 'auth_session_state': 'AUTHENTICATED', 'session_id': '00390110-77c7-11f0-8f1b-3d6c8b6'}
details:
8.11. Manage users login sessions¶
Robin CNP supports session management, allowing you to maintain secure, independent access across multiple devices. Each time a user logs in, CNP assigns a unique login session with a session ID to your environment. This ID is embedded in your JSON Web Token (JWT) to verify users identity and session status.
The login session management feature enables you to view all the login sessions at any point in time with the list of user names and the tenants the users belong to. You can revoke access to any user when required, even before the session expires. The feature also enables you to view any ephemeral users logged in to the cluster.
8.11.1. Important concepts to understand¶
Session ID: It is UUID linked to a specific user and device ID. A single
device_idcan host multiple login sessions. For example, if one user logs in, followed by another user, without the first user logging out.Session validity: Each session is valid for a defined period.
Device ID: A unique identifier for the specific environment you use to access the cluster, such as a CLI instance or a browser.
CLI login session: When a user logs in using CLI, each CLI login instance is treated as a separate device, whether it is running on a cluster node, within a control plane container, or on a remote laptop.
UI login session: When a user logs in using UI using a browser, each browser maintains its own
device_id. If you use multiple browsers on the same host, each is treated as a distinct device.
Note
Browser tabs under the same domain share the same local storage. Therefore, multiple tabs opened in the same browser will share the same device_id and be treated as a single session. To establish a completely separate session (a new device_id), you must use a different browser or open an “Incognito/Private” window.
Ephemeral user ID: When an ephemeral user logs in, CNP assigns a unique ID. An ephemeral user is a temporary external user (such as a Google account holder) who authenticates via an external identity provider to perform operations as an existing Robin user.
8.11.2. Session management based on roles¶
Based on the role of a user, the cluster superadmin, tenant admin, and user can view and revoke sessions. Revoking a session immediately invalidates the login token and requires the user to re-authenticate.
The following table provides the details of the cluster user role and session management scope:
Role |
Session management scope |
|---|---|
Super admin |
Can view and terminate all login sessions across the entire cluster. |
Tenant admin |
Can view and terminate login sessions for all users within their assigned tenant. |
User |
Can view and terminate only their own login sessions. |
8.11.3. View login session¶
Viewing login sessions depends on the role you hold. If you access the cluster as a superadmin, you can view all the login sessions across the cluster. If you access the cluster as a tenant admin, you can view login sessions of all users within the tenant, and if you access the cluster as a user, you can view only your session.
To view login sessions on your cluster, run the following command:
# robin login-session list <sessionID>
|
The session_id for a login session. |
Note
If you do not provide the optional session ID, the command output displays all the active sessions.
Example:
[root@vnode-103-152 ~]# robin login-session list
Session ID | Valid Until | Username | Tenant | Device ID | Ephemeral User Id
-------------------------------------+--------------------------+----------+----------------+--------------------------------------+-------------------
11603c63-9de7-11f1-9b56-1de94c725f58 | August 22, 2026 22:05:17 | admin | Administrators | 83407223-62fe-47fe-a54c-605d4a1de793 |
3a47ba11-9e26-11f1-b99e-5b1cabd14fea | August 23, 2026 05:37:24 | admin | Administrators | 858143ba-2acd-4051-8576-8c86ad48eb4b |
8.11.4. Delete a login session¶
Deleting a login session depends on the role you hold. You can delete all active sessions based on username or Device ID. For more information, see Session management based on roles.
Note
Deleting a session immediately ends the session for the users using the session.
# robin login-session delete
Option |
Description |
|---|---|
|
The |
|
Delete all login sessions for the given username |
|
Delete all login sessions for the given device ID |
Example
# robin login-session delete 7ae33914-7884-11f0-937e-c9d31777d7d2
Login session '7ae33914-7884-11f0-937e-c9d31777d7d2' deleted