Step 3: Preparing Kubeapps deployment ¶

Before Kubeapps is deployed to the TCE cluster, there are some decisions that need to be taken. This will shape the installation structure and functioning of the application.

Some relevant topics like routing traffic into Kubeapps, TLS, or which plugins need to be enabled, will be set up in a configuration values file. A configuration values file is a Yaml file that allows you to customize the deployment of Kubeapps. TCE makes use of Carvel for installing applications, and in the case of the Kubeapps package, the configuration file uses exactly the same parameters specified in the Bitnami Kubeapps Helm chart. It is highly recommended that you take a look at the possible parameters and get familiar with them.

The outcome of this tutorial step will be:

• A configuration values file that matches your desired setup for Kubeapps
• Required packages ready to make the configuration work (for example, installing the actual Ingress provider)

Option A: Getting traffic into Kubeapps using a LoadBalancer ¶

The simplest way to expose the Kubeapps Dashboard is to assign a LoadBalancer service type to the Kubeapps frontend Service. For example, you can use the following configuration value:

frontend:
  service:
    type: LoadBalancer

Option B: Getting traffic into Kubeapps using an ingress ¶

Using an ingress is one of the most common ways for getting access to Kubeapps.

In order to do so, you need to define a fully qualified domain name (FQDN), and preferably a TLS certificate available so that clients, like browsers, can safely navigate the UI.

In this tutorial we will use the FQDN kubeapps.foo.com to access Kubeapps as an example.

Add a TLS certificate with the following command:

kubectl -n kubeapps create secret tls kubeapps-host-tls \
    --key <YOUR_KEY>.pem \
    --cert <YOUR_CERTIFICATE>.pem

The public/private key pair must exist before hand. For more information, please check the Kubernetes documentation for TLS secrets .

This TLS certificate can be used by any type of ingress.

As an alternative, you can have certificates automatically managed using Cert-manager .

Please refer to the Kubeapps documentation covering external access with Ingress for additional information.

Option B1: Using Contour ingress ¶

Contour is an open source Kubernetes Ingress controller that acts as a control plane for the Envoy edge and service proxy.

Currently it is not possible to use Contour together with OIDC authentication in Kubeapps due to this limitation . It is possible, though, when using the demo-only, insecure, token authentication.

In order to use Contour with the token authentication, for example with a TCE unmanaged cluster, you can make use of an HTTPProxy to route the traffic to the Kubeapps frontend reverse proxy .

1. Install Contour

     tanzu package install contour \
       --package-name contour.community.tanzu.vmware.com \
       --version 1.20.1
   

2. Create an HTTPProxy. Please notice how it references both the secret holding the TLS certificate and the FQDN.

   cat <<EOF | kubectl apply -f -
   apiVersion: projectcontour.io/v1
   kind: HTTPProxy
   metadata:
     name: kubeapps-grpc
     namespace: kubeapps
   spec:
     virtualhost:
       fqdn: kubeapps.foo.com
       tls:
         secretName: kubeapps-host-tls
     routes:
       - conditions:
         - prefix: /apis/
         pathRewritePolicy:
           replacePrefix:
           - replacement: /
         services:
           - name: kubeapps-internal-kubeappsapis
             port: 8080
             protocol: h2c
       - services:
         - name: kubeapps
           port: 80
   EOF
   

3. Retrieve the external address of Contour’s Envoy load balancer

   kubectl get -n projectcontour service envoy -o wide
   

   Using the external address create a CNAME record (for example kubeapps.foo.com) in your DNS that maps to the load balancer’s address.

Option B2: Using Nginx ingress ¶

Nginx configuration comes shipped with the Kubeapps package out of the box. In order to enable it, add the following to the configuration values:

ingress:
  enabled: true
  ingressClassName: "nginx"
  hostname: kubeapps.foo.com
  tls: true
  extraTls:
    - hosts:
        - kubeapps.foo.com
      secretName: kubeapps-host-tls
  annotations:
    nginx.ingress.kubernetes.io/proxy-read-timeout: "600"

Please note how the configuration above references both the secret holding the TLS certificate and the FQDN.

As mentioned, Kubeapps provides the configuration handling for Nginx. But Nginx needs to be installed in the cluster. To install it use the official resources like:

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/kind/deploy.yaml

When using OauthProxy for OIDC authentication, there is an issue with the proxy buffers that needs some workaround.

You can use a modified resources file to install Nginx that Kubeapps provides. This is limited to the specific version shipped with Kubeapps.

Alternatively, you can make the change manually on top of your Nginx installation running kubectl -n ingress-nginx edit cm ingress-nginx-controller and adding the following to the data: section of the ConfigMap:

proxy-buffer-size: 8k
proxy-buffers: 4 8k

Configuring OIDC ¶

In case you selected OIDC as your authentication method, you will need to set some parameters in the configuration values file. This is needed so that the OAuth proxy used in Kubeapps can contact the OIDC provider and exchange the tokens.

Please retrieve the values obtained in the Setting up Google credentials client section and set them in your configuration values:

authProxy:
  enabled: true
  provider: oidc
  clientID: <YOUR_CLIENT_ID>
  clientSecret: <YOUR_CLIENT_SECRET>
  ## NOTE: cookieSecret must be a particular number of bytes. It's recommended using the following
  ## script to generate a cookieSecret:
  ##   openssl rand -base64 32 | tr -- '+/' '-_'
  ## ref: https://oauth2-proxy.github.io/oauth2-proxy/docs/configuration/overview#generating-a-cookie-secret
  cookieSecret: <COOKIE_SECRET>
  scope: "openid email groups"
  extraFlags:
    - --oidc-issuer-url=<YOUR_OIDC_ISSUER_URL>

Configuring selected plugins ¶

Kubeapps offers three plugins for managing packages and repositories: Helm , Carvel and Flux . You need to define in the configuration values which plugins you want have installed, for example:

packaging:
  helm:
    enabled: true
  carvel:
    enabled: true
  flux:
    enabled: false

At this point, you should have a proper Yaml file with configuration values.

Continue the tutorial by deploying Kubeapps .