Authentication

We offer a variety of different ways to secure access to K10:

Direct Access

When exposing the K10 dashboard externally, it is required that an authentication method is properly configured to secure access.

If accessing the K10 API directly or using kubectl, any authentication method configured for the cluster is acceptable. For more information, see Kubernetes authenication.

Basic Authentication

Basic Authentication allows you to protect access to the K10 dashboard with a user name and password. To enable Basic Authentication, you will first need to generate htpasswd credentials by either using an online tool or via the htpasswd binary found on most systems. Once generated, you need to supply the resulting string with the helm install or upgrade command using the following flags.

--set auth.basicAuth.enabled=true \
--set auth.basicAuth.htpasswd='example:$apr1$qrAVXu.v$Q8YVc50vtiS8KPmiyrkld0'

Alternatively, you can use an existing secret that contains a file created with htpasswd. The secret must be in the K10 namespace.

--set auth.basicAuth.enabled=true \
--set auth.basicAuth.secretName=my-basic-auth-secret

Token Authentication

To enable token authentication use the following flag as part of the initial Helm install or subsequent Helm upgrade command.

--set auth.tokenAuth.enabled=true

Once the dashboard is configured, you will be prompted to provide a bearer token that will be used when accessing the dashboard.

../_images/token_login.png

Obtaining Token

Token authentication allows using any token that can be verified by the Kubernetes server. For details on the supported token types see Authentication Strategies.

The most common token type that you can use is a service account bearer token.

You can use kubectl to extract such a token from a service account that you know has the proper permissions.

# Assume K10 is installed in the 'kasten-io' namespace
# Extracting token from SA 'my-kasten-sa'

# get the SA secret
sa_secret=$(kubectl get serviceaccount my-kasten-sa -o jsonpath="{.secrets[0].name}" --namespace kasten-io)

# extract token
kubectl get secret $sa_secret --namespace kasten-io -ojsonpath="{.data.token}{'\n'}" | base64 --decode

Alternatively, you can create a new service account from which to extract the token.

kubectl create serviceaccount my-new-kasten-sa

In this case, you will need to create a role binding or cluster role binding for the account to ensure that it has the appropriate permissions for K10.

To learn more about the necessary K10 permissions, see Authorization.

OpenID Connect Authentication

For clusters that have been properly configured to use OpenID Connect (OIDC) Tokens, K10 supports the ability to obtain a token from an OIDC provider and then use that token for authentication.

Cluster Setup

Before enabling OIDC Authentication for K10, it is required that the Kubernetes API server on your cluster is properly configured to validate OIDC tokens from your desired provider.

For more information on the Kubernetes API configuration options, see Configuring the API Server.

When working with a hosted Kubernetes offering (e.g. GKE, AKS, IKS) there will usually be specific instruction on how to enable this since you may not be able to explicitly configure the Kubernetes API server.

Overall, this portion of the configuration is beyond the scope of the K10 product and is part of the base setup of your Kubernetes cluster.

K10 Setup

After the server side setup is completed, you will need to make sure that K10 is configured to obtain OIDC token from the OIDC provider that your cluster expects.

Provider Redirect URI Authorizations

As part of the exchange with the OIDC provider, K10 will include a redirect URL in its request to the provider. The provider will return the user to that endpoint after the user has been authenticated. If the OIDC provider that you are using requires that redirects are specifically authorized, you will need to whitelist the following:

  • For a K10 instance exposed externally use https://<URL to k10 gateway service>/<k10 release name>/auth-svc/v0/oidc/redirect

  • For a K10 instance exposed through kubectl port-forward use http://127.0.0.1:<forwarding port>/<k10 release name>/auth-svc/v0/oidc/redirect

K10 Configuration

The final step is providing K10 with the settings needed to initiate the OIDC workflow and obtain a token.

  • OIDC Provider

    This is a URL for OIDC provider. Use the same URL that was used when configuring the --oidc-issuer-url option of the Kubernetes API server.

    Use the following Helm option:

    --set auth.oidcAuth.providerURL=<provider URL>
    
  • Redirect URL

    This is the URL to the K10 gateway service.

    Use https://<URL to k10 gateway service> for K10 exposed externally or http://127.0.0.1:<forwarding port> for K10 exposed through kubectl port-forward.

    Use the following Helm option:

    --set auth.oidcAuth.redirectURL=<gateway URL>
    
  • OIDC Scopes

    This option defines the scopes that should be requested from the OIDC provider. Use the same claims that were requested when configuring the --oidc-username-claim option of the Kubernetes API server.

    Use the following Helm option:

    --set auth.oidcAuth.scopes=<space separated scopes. Quoted if multiple>
    
  • OIDC Client ID

    This option defines the Client ID that is registered with the OIDC Provider. Use the same client ID specified when configuring the --oidc-client-id option of the Kubernetes API server.

    Use the following Helm option:

    --set auth.oidcAuth.clientID=<client id string>
    
  • OIDC Client Secret

    This option defines the Client Secret that corresponds to the Client ID registered. You should have received this value from the OIDC provider when registering the Client ID.

    Use the following Helm option:

    --set auth.oidcAuth.clientSecret=<secret string>
    

Below you have a summary of all the options together. These options can be included as part of the initial install command or alternatively can be used with a helm upgrade (see more about upgrade at Installing and Upgrading K10) command to modify an already existing installation.

--set auth.oidcAuth.providerURL=<provider URL> \
--set auth.oidcAuth.redirectURL=<gateway URL> \
--set auth.oidcAuth.scopes=<space separated scopes, use quotes for multiple scopes> \
--set auth.oidcAuth.clientID=<client id string> \
--set auth.oidcAuth.clientSecret=<secret string>