Web applications¶
KubePortal can be used to manage the access to web applications, which typically run in the cluster itself. A typical example is Kubernetes Dashboard, which can be used as graphical frontend for cluster management.
The current list of configured web applications is accessible in the backend. When creating a new web application entry, you have a set of options for the integration in the portal described below.
Frontend link¶
A web application can be presented as link on the landing page for users. Both the name shown and the URL are customizable. The target URL can use placeholders, so that customized URLs are possible:
- {{namespace}}: Inserts the configured Kubernetes namespace name for the portal user in the URL.
- {{serviceaccount}}: Inserts the configured Kubernetes service account for the portal user in the URL.
A simply example where this becomes handy is a link to the K8S dashboard page of the user accessing the portal:
https://dashboard.example.com/#!/overview?namespace={{namespace}}
A link to the web application is only shown when the user has access permissions (see User groups).
Login through portal (OIDC)¶
KubePortal operates as OpenID Connect (OIDC) provider, so web application such as Grafana can use the portal for authentication. For users already logged into the portal with the same browser, the web application then just works. Anonymous users are redirected by the web application to the portal for login.
To allow OIDC-enabled web applications to use the portal, you need to create an OpenID Connect client in the web application settings:
Please note that the client secret is generated automatically and can be seen in the web application overview list. The redirect URIs depend on the particular web application you are trying to integrate.
The web application also needs some settings:
- Client ID and client secret are shown in the web application overview page.
- The recommended authentication scopes are openid, profile, and email.
- The link <KubePortal URL>/oidc/authorize provides the authorization endpoint.
- The link <KubePortal URL>/oidc/token provides the token information endpoint.
- The link <KubePortal URL>/oidc/userinfo provides the API endpoint for fetching user information.
- The returned JSON with user information contains the keys ‘nickname’ (aka username), ‘given_name’, ‘family_name’, ‘name’, and ‘email’.
The login through OIDC is only possible if the user has access permissions for this web application (see User groups).
Example configuration for Grafana:
Login through portal (sub-auth)¶
When you operate your web applications in the cluster itself, and rely on the NGINX Ingress Controller, it is possible to use another portal authentication method called ‘sub-authentication’. One use case for this is the Kubernetes Dashboard.
Sub-authentication can be separately enabled per web application. This generates a special sub-authentication URL that is only valid for this app. This URL can be seen on the web application overview page.
The URL must be added to the Ingress definition of the application about to be protected. The details are described in the NginX ingress documentation.
Example:
Please note that KUBEPORTAL_SESSION_COOKIE_DOMAIN (see Configuration options) must be set to a value that matches both to your portal and web application DNS name, e.g. .example.com, otherwise the login check will always fail. This means that all web application URLs using this mechanism must live in the same DNS zone as your portal installation.
The login through sub-authentication is only possible if the user has access permissions for this web application (see User groups).