SAS Viya 3.2 Some Kerberos Principles

[#1]

As a follow-on from my last post, looking at the authentication options for SAS Viya 3.2, in this post I want to set out some clear principles for how the current release of SAS Viya will interoperate with Kerberos. My aim here is just to present some overview concepts for how we can use Kerberos with the SAS Viya 3.2 release. In future posts we’ll examine each these use cases in more detail.

With SAS Viya 3.2 we have different models or use cases for how we can use Kerberos with the environment. In the first case we use Kerberos with the full deployment from the visual interfaces.

Use Case 1

The diagram below illustrates this use case where Kerberos is used on both ends of the environment.

In this diagram we show the end-user relying on Kerberos or Integrated Windows Authentication to log onto the SAS Logon Manager as part of their access to the visual interfaces. This initial authentication of the end-user does not have to use Kerberos, this could use any of the authentication options we covered in the last post.

The key part of this use case is that the end-user is accessing the visual interfaces and connecting from there to SAS Cloud Analytic Services and onto a Secured Hadoop environment. For the connection between the visual interfaces and the SAS Cloud Analytic Services we rely on internal OAuth authentication of the end-user. The end-user obtains an OAuth token from the SAS Logon Manager as part of their initial authentication and they use this token to authenticate to SAS Cloud Analytic Services. The OAuth token provides some user and group information that enables SAS Cloud Analytic Services to provide integration with the authorization information stored in the SAS microservices.

Since the end-user only used an OAuth token to connect to SAS Cloud Analytic Services there are no operating system credentials provided to SAS Cloud Analytic Services. This means that the CAS Controller cannot authenticate the end-user and launch a Session Controller running as the end-user, since no credentials were forwarded. Hence the CAS Session Controller, and CAS Session Workers in the distributed case, all run as the service account that launched the SAS Cloud Analytic Services operating system service. This will be the cas account in a default setup.

If our end-users accessing the visual interfaces need to access a secured Hadoop cluster; where they need to provide Kerberos Service Tickets to be able to access the data, we need to give the SAS Cloud Analytic Services controller some Kerberos credentials. We provide the credentials in the form of a Kerberos keytab. This keytab enables the CAS Controller to initialize a set of Kerberos credentials at start-up. This set of Kerberos credentials does not have to be for the cas user. The credentials in the keytab could be for any user, but all access from CAS to Hadoop will use this single shared credential. In the diagram above we have listed this as the "CAS Hadoop Account".

Use Case 2

Our second use case covers those user entering the environment via the programming interfaces, for example SAS Studio. In this case the end-users have entered a username and password, a credential set, into SAS Studio. This credential set is used to start their individual SAS Workspace Session and to connect to SAS Cloud Analytic Services from the SAS Workspace Server. This is illustrated in the following figure.

Since the end-users are providing their username and password to SAS Cloud Analytic Services it behaves differently. SAS Cloud Analytic Services uses its own Pluggable Authentication Modules (PAM) configuration to validate the end-user’s credentials and hence launch the CAS Session process running as the end-user. However, in addition the CAS Controller also uses the username and password to obtain an OAuth token from SAS Logon Manager and then is able to obtain any access control information from the SAS Viya 3.2 microservices. Obtaining the OAuth token from the SAS Logon Manager ensures any restrictions or global caslibs defined in the visual interfaces are observed in the programming interfaces.

With the CAS Session running as the end-user and any access controls validated; the SAS Cloud Analytic Services session can access the Secured Hadoop cluster. Now since the CAS session was launched using the PAM configuration the Kerberos credentials used to access Hadoop will be those of the end-user. This means the PAM configuration on the machines hosting SAS Cloud Analytic Services must be linked to Kerberos. This PAM configuration then ensures the Kerberos Ticket-Granting Ticket is available to the CAS Session as is it launched.

We can see that an end-user accessing both the programming interfaces and the visual interfaces will see different permissions in the Secured Hadoop environment depending upon which interface they were using. With programming interfaces they access Hadoop with their own account; whilst with visual interfaces they access Hadoop with a shared credential set.

Use Case 3

There is a way for the users of the visual interfaces to have an experience closer to the programming users when launching the SAS Cloud Analytic Services session. If we create a custom group with an ID of "CASHostAccountRequired" in SAS Environment Manager and place users into this group SAS Cloud Analytic Services will process the start-up of their sessions in a different way. If the users are members of the group "CASHostAccountRequired" then SAS Cloud Analytic Services will look for sufficient information in the OAuth token to launch a valid operating system process as the end-user. This is shown in the following figure.

In this case the CAS Server Controller directly launches the CAS Session Controller using the user name from the OAuth token rather than passing any credentials to the PAM stack on the host. Therefore, the username from the OAuth token must be "known" to the operating system where the CAS Session Controller and CAS Session Workers will be running. This means the process is running as the end-user on the host but that the end-user was never authenticated on the host. Since the PAM stack was not used to authenticate the end-user and launch their CAS Session their Kerberos credentials were never initialized.

In addition, since the CAS session is now running as the end-user it is unable to access the Kerberos credentials cache initialized by the CAS Server Controller on start-up from the Kerberos keytab. This means that in this use case the end-user will not be able to access the Secured Hadoop cluster.

Summary

SAS Viya 3.2, presents different ways in which Kerberos can be leveraged by SAS Cloud Analytic Services to authenticate to a Secured Hadoop cluster. When end-users access the visual interfaces, SAS Cloud Analytic Services must be configured to use a Kerberos keytab and a shared account. While when using the programming interfaces access to Secured Hadoop will be based on the Kerberos credentials obtained during the PAM authentication of the end-user. Finally, adding an end-user to the custom group "CASHostAccountRequired" will, in most cases, prevent that user from obtaining any valid Kerberos credentials and hence prevent that user from accessing the secured Hadoop cluster.

 Stuart Rogers