SAS Viya 3.5 introduces support for using service accounts with the SAS Compute Server. This enables the administrator to configure a SAS Compute Server context to be associated with a service account. Then all SAS Compute Server sessions for that context will run as the specified service account. This removes the need for end-users to have operating system accounts on the hosts where the SAS Compute Server is running. In this article we’ll examine some considerations for using service accounts and how this is configured.
The SAS Compute Server is used by several components within the SAS Viya 3.5 environment. Some of the components using the SAS Compute Server are:
- SAS Studio 5.2 (Enterprise)
- SAS Job Execution
- SAS Visual Data Mining and Machine Learning
- SAS Model Manager
- SAS Visual Forecasting
- CAS Formats service
- Import 9 service
On Linux, in the default configuration, the SAS Launcher service uses the end-user’s internal OAuth token, generated by SAS Logon Manager, to authenticate to the SAS Launcher Server and launch the SAS Compute Server session. Since the internal OAuth token only contains the end-user’s username no actual operating system authentication of the end-user is possible. This username is just used to launch the SAS Compute Server.
With SAS Viya 3.4 on Linux the alternatives to the default approach are to configure Kerberos unconstrained delegation or use a stored credential. With SAS Viya 3.5, in addition to these two approaches, administrators can use Kerberos constrained delegation or a service account.
Consideration for using Service Accounts
The use of a service account with the SAS Compute Server makes sense when the end-users do not have operating system accounts on the host(s) where the SAS Compute Server is running. This enables end-user, perhaps authenticated via third-party SAML or OpenID Connect providers, access to the SAS Compute Server.
Associating a service account with a SAS Compute Server context ensures all session will run on the operating system as that service account. However, the SAS Compute Server session will still have access to the end-user’s internal OAuth token generated by SAS Logon Manager. This means that any connections leveraging the SAS Viya service layer will be made as the end-user and not as the service account. But all operating system access will be as the service account and not the end-user.
A single SAS Compute Server context can only be associated with a single service account. Some applications, such as SAS Studio 5.2 (Enterprise) only function with a single SAS Compute Server context. This means that all users of SAS Studio 5.2 (Enterprise) will use the same service account. If the aim is to have different groups of end-users run the SAS Compute Server sessions as different host accounts, then using service accounts is not the correct approach. Instead a stored group credential should be used instead. This stored group credential is stored within the defaultAuth authentication domain.
The service account credential is stored with the Credentials microservice. The SAS Administration CLI is used to store the service account username and password. These credentials are stored in a new randomly generated credential domain. This domain is not visible within SAS Environment Manager. The SAS Administration CLI is the only mechanism to interact with the stored service account. The credentials for the service account are encrypted by the Credentials microservice and stored in the SAS Infrastructure Data Server. Only the SAS Compute Service can access the stored credentials via the Credentials microservice.
The service account credentials are passed through the Pluggable Authentication Module (PAM) stack when launching the SAS Compute Server. This means that if the PAM stack is integrated with Kerberos, then Kerberos credentials for the service account will be available to the SAS Compute Server session. These Kerberos credentials could then be used to access data sources from the SAS Compute Server session.
Configuring Service Accounts
There are two stages to configuring the use of service accounts. The first stage is storing the credentials for the service account and must be completed in the SAS Administration CLI. The second stage is updating the SAS Compute Server context and must be completed in SAS Environment Manager.
To store the service account credentials using the SAS Administration CLI you need to first authenticate to the SAS Viya 3.5 environment. This requires a SAS Administration CLI profile. This could be created manually as a text file using the following commands:
cat <<'EOF' > ~/.sas/config.json
{
"Default": {
"ansi-colors-enabled": "true",
"output": "text",
"sas-endpoint": "https://<<viya_http.customer.com>>"
}
}
EOF
chmod 600 ~/.sas/config.json
Or by using the SAS Administration CLI as described in the Tools for Administrators documentation.
Note: do not create the ~/.sas/config.json as the root user in the root user's home directory.
With the profile created you can log into the SAS Viya 3.5 environment with a user who is a member of the SAS Administrators group:
source /opt/sas/viya/config/consul.conf;
/opt/sas/viya/home/bin/sas-admin auth login -u <<username>> -p "<<password>>"
Use the following command to store the credentials for the service account:
/opt/sas/viya/home/bin/sas-admin compute credentials create
You will then be prompted for the Userid, password, and a description. Once the credentials have been stored the following message will be displayed:
2019/11/11 05:17:12 The shared service account credential for <<service_account>> was created successfully.
The SAS Administration CLI can also be used to list the stored credentials for the service accounts:
/opt/sas/viya/home/bin/sas-admin compute credentials list
You will see the following:
Shared Service Account Credentials:
1. <<service_account>> - <<Your description>>
Once you have finished with the SAS Administration CLI you should logout:
/opt/sas/viya/home/bin/sas-admin auth logout
The second stage is completed in SAS Environment Manager where the SAS Compute Server context is updated. You must log into SAS Environment Manager as a member of SAS Administrators and assume the SASAdministrators role. Then complete the following:
- Select Contexts
- Select Compute contexts from the drop down
- Select SAS Studio compute context
- Select Edit
- Select Add against Attributes
- Enter runServerAs as the Attribute
- Enter <<service_account>> as the Value
- Select Save
- Select Save
This completes the changes required in SAS Environment Manager. With both the credential stored and the context updated the Launcher Server can be restarted with the following command:
sudo systemctl restart sas-viya-runlauncher-default
Validate Service Accounts
To validate the use of the service account you can both confirm that the credential has been stored correctly with the Credentials microservice and confirm it is used correctly by SAS Studio 5.2 (Enterprise). To validate the new credential domain log into SAS Environment Manager as a member of the SAS Administrators group and assume the SASAdministrators role. Open the following URL in a new tab:
https://<<viya_http.customer.com>>/credentials/domains?start=10&limit=10
Scroll down the returned JSON and you will see the new credential domain with the following properties:
- id = a UUID such as 6801a691-1589-4c8b-a98c-de5ed5f1ff46
- type = compute-password
- label = <<service_account>>
To validate SAS Studio 5.2 (Enterprise) log in with an end-user and then examine the operating system processes on the host(s) where the SAS Compute Server is deployed. For example, the following command will display the SAS Compute Server processes:
ps axo user:20,pid,pcpu,pmem,vsz,rss,tty,stat,start,time,comm |grep compsrv
You should see the following:
<<service_account>> 14845 0.0 0.0 113316 1644 ? Ss 09:37:06 00:00:00 compsrv_start.s
<<service_account>> 14866 13.4 0.1 1710648 53052 ? Sl 09:37:06 00:00:01 compsrv
Conclusion
The option of using a service account with the SAS Compute Server in SAS Viya 3.5 adds a simplifying option when end-users of SAS Viya 3.5 do not have host operating system accounts. As we’ve shown it is straight-forward to configure the use of a service account and behaves as you would expect. This option is not going to be a good fit for all deployment types, but certainly makes administration simpler for this use-case.
