PKS – Getting Started Part 5 Granting PKS Access

/ vnuggets

Overview

In this part of my PKS Getting Started series I’m going to cover how to grant end users access into PKS to allow cluster operations to be initiated. I am using LDAP in my environment so I will concentrating on this method in this article.

User Privileges

Before I can grant access to my users I need to understand what the permissions options are for PKS users. Pivotal refers to these options as “scopes” which are attached to a users/groups. The two available scopes are as follows:

  • pks.clusters.manage – allows users to create and access their own cluster(s) but nobody elses
  • pks.clusters.admin – allows users to create and access everyone’s clusters

In my lab I am going to assign a group the pks.clusters.admin scope however first I need to cover the method for assigning these access rights.

User Account & Authentication Service (UAA)

Each of the components I have deployed so far (Ops Manager, BOSH and PKS) has a UAA service that runs within them that controls access to the related component (i.e. UAA on Ops Manager controls access to Ops Manager).

To allow users to perform PKS operations such as creating a cluster I need to configure the UAA within PKS to allow my users the correct level of access. I provided the LDAP base DN’s when I deployed PKS in the previous article (see screenshot below) so this should just be a case of mapping up groups. If you want to review the LDAP search configuration then you an view this by clicking onto the PKS tile in Ops Manager and going to “UAA”.

Accessing UAA

UAA has (unsurprisingly) a client application called UAAC which allows an admin to execute operations against the UAA service. This client is installed on the Ops Manager VM so I can either use that or install UAAC on another Linux VM. For simplicity I am going to use Ops Manager and simply SSH onto the Ops Manager VM using my private key for authentication.

Here I am using the UAA client (uaac) to target the PKS VM on the UAA port (8443) using the Ops Manager root CA certificate to validate the PKS certificate (note you can skip SSL validation using “–skip-ssl-validation” if so desired).

At this point I have not authenticated to UAA, only targeted the UAA service on PKS. Now I need the “PKS UAA Management Client Admin” secret value to use in order to get a secure token for UAA. The secret is obtained from the PKS Credentials tab in Ops Manager.

I can now use the secret value for my UAA connection.

At this point I am now authenticated to UAA as the admin user which gives me all the rights necessary to start granting local or external users access to PKS.

Mapping Users

UAA has no capability to map individual external users to scopes, only to create and delete local users (as well as manipulate passwords and other user attributes for the local users). For this reason mappings can only be done to LDAP groups in my environment.

Mapping Groups

At this point I can now either create local UAA users and map them to a scope (if using internal authentication) or map existing external groups to a scope. As I am using LDAP for UAA I will be mapping existing groups., using the group common name (i.e. the “cn” value).

Here I have mapped my “pks-admin” group to the “pks.clusters.admin” scope.

I can now validate the mapping by issuing a command to show all the current mappings between scopes and groups.

For a full list of client capabilities you can simply type “uaac” and reference the returned output.

In my next article I will be looking at how an external user can start to interact with PKS and consume its capabilities.