Skip to main content

Security

PaletteAI is designed with a security-first principle. The following sections detail the security features and design decisions currently in place.

Security Components​

PaletteAI's security architecture is made up of the following components:

  • Kubernetes Role-Based Access Control (RBAC)
  • Dex
  • User Interface (UI) components, client-side and server-side
  • cert-manager
  • Hyper Text Transfer Protocol Secure (HTTPS)

The components work together to provide a secure and reliable authentication and authorization system. PaletteAI uses Kubernetes RBAC system to manage access control. The same actions a user can do in the Palette UI can be performed directly through the Kubernetes API server. Dex is used to support a number of different authentication mechanisms and to issue authentication tokens that can be used to authenticate with the Kubernetes API server the PaletteAI UI.

All internal PaletteAI components are assigned a unique SSL certificate through cert-manager. Cert-manager is deployed as part of the PaletteAI installation and setup process. You can customize cert-manager to use your own Certificate Authority (CA) to issue the certificates. Unless a different cert-manager issuer is configured, cert-manager will issue self-signed certificates to each of the PaletteAI components deployed inside the hub cluster. The certificate is required to enable HTTPS communication between the different PaletteAI components. All PaletteAI components are configured to use HTTPS by default.

The following sections cover in greater detail how authentication and authorization are handled in PaletteAI.

Authentication​

PaletteAI uses Dex for user authentication. Dex is an open-source identity service broker that supports a number of different authentication mechanisms. Through Dex, you can leverage your existing SAML, OIDC, or LDAP infrastructure to authenticate with PaletteAI and the hub cluster's Kubernetes API server without having to manage another set of credentials. Dex was chosen to enable you to integrate PaletteAI with your existing Identity Provider (IdP), or other authentication services your organization may already have in place.

warning

PaletteAI supports local users creation and management through Dex. Be aware that this is a limited capability and does not natively support RBAC. We recommend using an IdP for production usage. If you must use local users, enable user impersonation to map them to Kubernetes groups. Refer to the Local Dex Users section for more information.

By default, PaletteAI expects the hub cluster to be configured to trust Dex as an OIDC provider. By trusting Dex as an OIDC issuer, the hub cluster accepts authentication tokens issued by Dex for the Kubernetes API server. This also allows you to configure tools, such as kubectl, to authenticate with the Kubernetes API server using authentication tokens issued by Dex. This latter point is important for non-UI workflows, or GitOps workflows, as it enables you to authenticate with the Kubernetes API server using the same mechanism as the PaletteAI UI. You can configure Dex during the PaletteAI installation process to map OIDC groups to the PaletteAI RBAC roles. The OIDC group mapping is what bridges your IdP groups to the PaletteAI RBAC roles.

tip

You can learn more about how to configure Kubernetes to use an OIDC provider in the official Kubernetes documentation. The formal Dex documentation also has a page that explains how Kubernetes Authentication Through Dex operates.

The PaletteAI UI has a server-side component, Canvas, inside the hub cluster. Canvas is what communicates with Dex and the Kubernetes API server. The client-side component of PaletteAI is what you can observe and interact with in your browser. The client-side component only communicates with Canvas and Dex and does not communicate directly with the Kubernetes API server. This design decision provides PaletteAI with a better security posture by keeping credentials out of the browser and ensuring sensitive operations are performed on the server side rather than the client side. The PaletteAI UI has a cookie that maps the user to a session. The session cookie itself does not contain any credentials; it only points to the server-side session data. Canvas stores the actual authentication tokens inside that session entry and uses them to authenticate with the Kubernetes API server.

The following diagram provides a high-level overview of the authentication flow in PaletteAI. The yellow arrows represent information flow with credentials.

"An overview of the authentication flow in PaletteAI"

  1. A user navigates to the PaletteAI UI and is presented with a login page. The user selects the authentication flow they want to use: SSO or email/password.
  2. The user is redirected to the Dex authentication page. Dex handles all authentication flows. If an IdP is used, the user is redirected to the IdP's login page. If an email/password flow is used, skip to step 4.
  3. The IdP authentication page is loaded in the browser. The user enters their credentials, which are directly sent to the IdP from the user's browser.
  4. Upon successful authentication with the IdP or Dex, the user is redirected back to the PaletteAI UI. In the case of an IdP authentication flow, Dex receives an authentication token, a JSON Web Token (JWT), from the IdP.
  5. Dex sends the JWT authentication token to Canvas. Canvas validates the token using Dex's JSON Web Key Set.
  6. Canvas creates a session cookie that maps the user to a session. The session cookie is, by default, configured with the same expiration time as the JWT authentication token.
  7. Canvas injects the authentication token when making API requests to the Kubernetes API server.
Preventing Cross-Site Request Forgery and Replay Attacks

In addition to PaletteAI's session cookie that maps the user to a session, PaletteAI also creates a temporary cookie during the sign-in process that uses a unique state parameter to prevent Cross-Site Request Forgery and replay attacks. The state parameter value is generated by PaletteAI UI's client-side and included in the authentication request. The unique state value is propagated to the IdP. The IdP will insert the state parameter in the redirect to the callback route. The callback route has logic that compares the received state token with the original value created by the client-side and stored as a cookie. If the two values do not match, the authentication flow is canceled. The temporary cookie is deleted after the authentication flow is completed. This process occurs in all sign-in requests to ensure that the request originated from the client-side component of PaletteAI. The state cookie also has a maximum age of five minutes. If the authentication flow is not completed within five minutes, the state cookie is deleted automatically by the browser.

This is an additional security measure to ensure that requests come from the PaletteAI UI, not from a malicious source. You can learn more about the benefit of unique state parameters in authentication flows in the article Prevent Attacks and Redirect Users with OAuth 2.0 State Parameters from Auth0.

All communication between the PaletteAI UI client side component and Canvas is done over HTTPS. By design, all PaletteAI UI requests that interact with the Kubernetes API server are proxied through Canvas. This ensures that all requests are authenticated before being sent to the Kubernetes API server. The authorization is delegated to the Kubernetes API server, which determines if the request is allowed based on the user's RBAC permissions.

Authorization​

PaletteAI uses Kubernetes RBAC to manage access control. The access that you have in PaletteAI is dictated by the PaletteAI role you have access to. This access spans the PaletteAI UI and when interacting directly with the Kubernetes API server in the hub cluster through GitOps workflows. The IdP group you are assigned to is mapped to a PaletteAI role during the installation and setup process. The PaletteAI roles have access to the various Custom Resources (CR) that PaletteAI creates and manages. You can find a complete list of all the PaletteAI CRs on the Custom Resources page.

Local Dex Users​

PaletteAI supports local users creation and management through Dex. You can configure local Dex users to be mapped to Kubernetes groups and Kubernetes users if user impersonation is enabled. Check out the User Impersonation page to learn more about how to configure local Dex users to be mapped to Kubernetes groups and Kubernetes users.

The local users are stored inside the cluster by default using Dex's Kubernetes storage method. If the hub cluster is deleted or the Dex storage is lost, the local users will also be lost. You can configure Dex's storage to use a different storage backend, such as a database, to persist the local users. However, by using an IdP, you can ensure that the users are managed outside of the hub cluster and are not lost in the event of a cluster failure.

If user impersonation is disabled, then no RBAC capability is available for local Dex users. This is a limitation from Dex as local users do not have the ability to have groups assigned to them. All local Dex users will inherit the same permissions as the PaletteAI UI service account. However, if user impersonation is enabled, you can use the dexGroupMap configuration to map local user emails to Kubernetes groups, providing RBAC capabilities for local users. If you have configured your Kubernetes cluster to trust Dex as an OIDC provider, use OIDC to manage users and groups. We strongly recommend using an IdP for production usage to enforce the least privilege principle.