Types

Octelium currently has 2 types of Users:

1. HUMAN Users which are used by humans. HUMAN Users usually authenticate themselves via the web portal of the Auth Server using identity provider IdentityProviders such as GitHub OAuth2 or any identity provider that supports OpenID Connect or SAML 2.0 (read more about IdentityProviders here).

Here is an example of a HUMAN User:

1
kind: User
2
metadata:
3
  name: alice
4
spec:
5
  type: HUMAN

2. WORKLOAD which are used by non-human entities such as containers, servers, programmable environments, etc.... By default, WORKLOAD Users have 2 options to authenticate themselves to the Cluster:
   1. Authentication token Credentials
   2. OpenID Connect-based assertion by an external identity provider (reade more here).

Here is an example of a WORKLOAD User:

1
kind: User
2
metadata:
3
  name: k8s-1
4
spec:
5
  type: WORKLOAD

Groups

A User may belong to one or more Groups (read more about Groups here). Here is an example:

1
kind: User
2
metadata:
3
  name: usr-1
4
spec:
5
  type: WORKLOAD
6
  groups: ["group-1", "group-2"]

Authentication

A User can have one or more identities that can be used to authenticate the User by an identity provider IdentityProvider (read more about IdentityProviders here) such as OpenID Connect, SAML 2.0, GitHub OAuth 2 for HUMAN Users as well as OpenID Connect assertions for WORKLOAD Users.

Here is an example of a User that has multiple identities that can be used for authentication:

1
kind: User
2
metadata:
3
  name: usr-1
4
spec:
5
  type: HUMAN
6
  authentication:
7
    identities:
8
    - identityProvider: github
9
      identifier: linus
10
    - identityProvider: okta-oidc
11
      identifier: [email protected]
12
    - identityProvider: saml-idp1
13
      identifier: [email protected]

The identityProvider field of the identity is the IdentityProvider name. The identifier is the value that is to be verified against when obtaining the User information from the identity provider during the authentication flow. Such information could be the OIDC identity token in the case of an OpenID Connect IdentityProvider or a SAML assertion in the case of SAML 2.0 IdentityProviders. It's important to note that the identifier's default value depends on the IdentityProvider type:

• For GitHub OAuth2-based IdentityProviders, the identifier is the username (read more here).
• For OpenID Connect IdentityProviders, the identifier by default is the value of the email claim in the identity token (read more here).
• For SAML 2.0 IdentityProviders, the identifier by default is the value of the http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress attribute. The Cluster administrators can override the default identifier claim in the case of OIDC or identifier attribute in the case SAML 2.0 (read more here).

Email

As seen above, a User can have one or more explicit identities, each identity has an identifier whose value authenticates the User during the authentication flow of a certain IdentityProvider. However, for HUMAN Users, it's generally more practical to just use the email address as the main identifier against most OpenID Connect and SAML 2.0-based IdentityProviders. Here is an example of setting the email for a HUMAN User:

1
kind: User
2
metadata:
3
  name: alice
4
spec:
5
  type: HUMAN
6
  email: [email protected]

Note that if Octelium will always attempt to first find an explicit identity to authenticate a User. If it doesn't find a match or if the identities list is empty then it will use the email as the fallback identifier.

In order to prevent Users from abusing this feature to authenticate themselves using an IdentityProvider that requires a less strict authentication (e.g. one IdentityProvider might only require a password while the other requires additional MFA such as WebAuthn or TOTP), the IdentityProvider can explicitly prevent using the User email as an identifier (read more here).

Privileged Users

Octelium intentionally has no notion whatsoever of an "admin" or "superuser" User by default. All access to any Service including to the Cluster API Servers (not that the API Servers are deployed as typical Octelium Services) has to be explicitly allowed by a Policy (read more about access control here). It should be noted that Octelium's API Server itself is exposed to Users as an ordinary gRPC Service.

Session

Users can interact with the Cluster and access its Services as long as their Sessions are valid. You can set a per-User Session duration value, after which the Session is deemed expired and is automatically deleted by the Cluster (namely by Nocturne). This per-User Session options override the Cluster-wide values set in the ClusterConfig (read more here). Here is an example:

1
kind: User
2
metadata:
3
  name: usr-1
4
spec:
5
  type: HUMAN
6
  session:
7
    clientDuration:
8
      days: 1
9
    clientlessDuration:
10
      hours: 10
11
    maxPerUser: 100
12
    accessTokenDuration:
13
      hours: 4
14
    refreshTokenDuration:
15
      days: 1

Disabling Users

You can disable/deactivate a User and immediately disable the User ability from interacting with the Cluster or accessing its Services. Here is an example:

1
kind: User
2
metadata:
3
  name: usr-1
4
spec:
5
  type: HUMAN
6
  isDisabled: true

To re-activate the User, you simply set the isDisabled field back to false.

Policies

Policies (read more about Policies and access control here) can be created and/or attached to User where they can act as principal-based policies for a specific User. Here is an example:

1
kind: User
2
metadata:
3
  name: john
4
spec:
5
  type: HUMAN
6
  authorization:
7
    policies: ["policy-1", "policy-2"]
8
    inlinePolicies:
9
      - spec:
10
          rules:
11
            - effect: DENY
12
              condition:
13
                match: 'ctx.service.metadata.namespace == "production"'

Attributes

You can extend a User resource by feeding it additional information including dynamically from external sources (e.g. IAM platforms, SIEM tools, threat intelligence tools, incident alerting and on-call management tools, etc...) via the APIs (read more here). Such additional information can be especially useful for extending access control and making it as fine-grained and dynamic as you wish (read more here). Here is an example:

1
kind: User
2
metadata:
3
  name: john
4
spec:
5
  type: HUMAN
6
  email: [email protected]
7
  attrs:
8
    pagerDuty:
9
      onCall: true
10
    azureAD:
11
      isAdmin: true
12
    isFriend: true
13
    age: 27
14
    anotherTool:
15
      key1: val1
16
      key2: 100
17
      key3: true
18
      key4:
19
        subKey1: subVal1