DocAuthentication

Authentication models

Approach 1 - User ID mapping

At this time, interoperation between sites is not possible. With relative ease, a UID translator can be placed at mount_slash endpoints which translates UIDs from the OS to the global SLASH2 UID when handling syscalls and vice versa when replying to syscalls.

Approach 2 - Host based authentication

However, even with root squashing, there is still the problem of compromised/untrusted mount_slash endpoints having full reign over all data in the SLASH2 file system. Host-based authentication solves some of these problems in that it can provide a mechanism to revoke access to the SLASH2 file system in cases of known compromised mount_slash endpoints.

Furthermore, restrictions can be placed on the certificates for mount_slash endpoints such that all accesses will only be granted to certain UIDs.

However, this model still does not solve the problem where an unknown compromised mount_slash with full reign privileges (that is, no UID restrictions; for example, on a large compute system) can wreak havoc on other users' files.

This solution entails deploying a PKI model to each host on the network. This means generating a certificate for each slashd, sliod, and mount_slash that wishes to participate on the SLASH2 network.

Approach 3 - Full Kerberos support

This approach alleviates all problems with the previous approaches at the cost of implementation and deployment complexity. But even in the case of unknown compromised full access mount_slash endpoints, only files owned by accounts with valid cached Kerberos tickets on the endpoint may be accessed.

Idea from Eric Barton: that encryption/uid mapping take place at or close to the router level or on the router.

slauthd

• runs on clients as part of mount_slash
• handles authentication using Kerberos
• user is who he says
• user is allowed to setup time limited grants for clients
• handles grant relay to SLASH2 server slauthd and/or SLASH2 MDS
• grant user@domain(s) access to SLASH2 UID for time period
• revoke grants
• possible vouches for user from hosts with grants. IOW, slaccd contacts a slauthd client for Kerberos verification.

slaccd

• runs as server on SLASH2 MDS or separate server
• maintains access grants
• is queried to determine if client reads/writes should be processed
• maintains keys for data encryption
• may be coupled with a SLASH2 Kerberos deployment

Example

• assume a kerb realm SITE.ORG
• assume a compute cluster cluster.org with nodes node1.cluster.org, node2.cluster.org, etc.
• assume a client machine client.org

Steps a user would take to use the file system:

1. user on client.org runs slauth_init (random example below)

$ slauth_init [email protected] --slashuser=rmbudden \
  --grant="node*.cluster.org" --time=24h

1. user enters their Kerberos password
2. Kerberos is contacted and user is given a ticket
3. the ticket is sent to slauthd which tells slauthd that the user is allowed to access the file system from the local client and that the user is allowed to setup grants for access
4. slauthd approves grants for user on node1.cluster.org, node2.cluster.org, etc.
5. grants are sent to slaccd (slaccd knows user is allowed file system access from node*.cluster.org for 24 hours using the username rmbudden [not necessarily the same Kerberos principle rbudden])
6. user submits computation job
7. computation job tries to write to slash
8. SLASH2 mount asks slaccd if it's permitted to write to the file system
9. slaccd looks up grants for user and approves I/O on the node for specified time (insert possible slauthd contact to obtain Kerberos credentials)
10. approval is cached on the client mount
11. I/O proceeds accordingly

Other ideas:

Having a way to request auth from a client, say in the job script, then revoke auth after the job has finished.

This might be for data encryption such as:

$ slauth request-key

• (slauthd approves grant, issues a new encryption key)
• ...
• job runs
• ...

$ slauth revoke-key

(slauthd revokes encryption key)

$ slauth revoke-grant

(slauthd revokes access grant from computational nodes since job is finished)