Security Model

Overview¶

SlideRule Earth leverages GitHub authentication and account membership status within the GitHub SlideRuleEarth organization to authorize access to SlideRule services. Credentials are provided by users using a JSON Web Token (JWT) issued by the SlideRule Earth login service (login.slideruleearth.io). A user’s JWT contains claims used and verified by SlideRule services to allow access.

Model Components¶

Roles¶

• Owner - SlideRuleEarth owner with administrator access to all services

• Member - SlideRuleEarth member with nominal access to all services

• Affiliate - External affliate of the SlideRuleEarth team with access to designated services

• Guest - Authenticated user with access to public services

• Anonymous - Unauthenticated

Services¶

• Certbot - manages SSL certificates for the service domain.

• Authenticator at https://login.slideruleearth.io – delegates authentication to an external identity provider (IdP), and performs authorization based on the authenticated identity.

• Provisioner at https://provisioner.slideruleearth.io – manages cluster lifecycle operations, including deployment, status, and tear-down

• Cluster at https://{cluster}.slideruleearth.io - provides low-latency science data processing (the primary application under the SlideRuleEarth project)

• Runner at https://runner.slideruleearth.io – provides batch job processing orchestration and status

Requests¶

• Unauthenticated Requests - No credentials are supplied in the HTTP request

• Authenticated Requests - Bearer token provided in authorization header of HTTP request

  • Users must use one of the authorization flows provided at login.slideruleearth.io to obtain a JWT

  • The JWT must be provided as a bearer token in each request to a SlideRule service: Authorization: Bearer <JWT>

• Signed Requests - EdDSA signature provided in custom SlideRule header of HTTP request

  • Users must create an Ed25519 public/private key pair and store in a well-known file in their home directory: ssh-keygen -t ed25519 -f .sliderule_key.

  • The public key .sliderule_key.pub must be provided to the SlideRuleEarth development team

  • Each request must be signed using the .sliderule_key private key.

  • The signature is calculated over the canonical message {path_b64}:{timestamp}:{body_b64} where path_b64 is the base64 encoded string of the full path to the endpoint including the hostname of the service (e.g. provisioner.slideruleearth.io/info), timestamp is the unix system time expressed as seconds since epoch rounded to the nearest integer, and body_64 is the base64 encoded string of the body of the request.

  • The ASCII encoded string of the timestamp is provided in the x-sliderule-timestamp: {timestamp_str} header, and the base64 encoded string of the signature is provided in the x-sliderule-signature: {signature_b64} header.

Permissions¶

• Owner

  • sliderule:admin - administrative access to cluster services

• Member / Affiliate

  • provisioner:access - access to provisioner services

  • runner:access - access to runner services

• Guest

  • sliderule:access - nominal access to cluster services

  • monitor:access - access to cluster monitor

Authorization Flows¶

Security Rules¶

Expirations¶

At different stages of the authorization flows there are time limits imposed to reduce the risk of compromised credentials.

Cluster Access¶

Members of the SlideRuleEarth organization have permission to deploy, access, and destroy private clusters namespaced to the organization teams they belong to. Owners within the organization can deploy, access, and destroy any cluster with a valid namespace (obeying url rules and AWS cloud formation stack name restrictions). Both members and owners are restricted to node capacity and time-to-live constraints imposed by the the provisioner.

Web Client Restrictions¶

When logging into SlideRule using the SlideRule Web Client, the client restricts the user permission set to sliderule:access and provisioner:access. This prevents a leaked token from being used for administrator access or for access to any of the other services

Request Signing¶

The following services require request signing:

• All requests to the Provisioner when the user provides a JWT that identifies them as an Owner.

• All requests to the Runer regardless of the role of the user.

• Requests to the Cluster (public or private) that route to the Arbitrary Code Execution (ace) and Container Runtime Environment Execution (execre) endpoints.

Flow Diagrams¶

Basic Web Flow (OAuth 2.0 Authorization Code)¶