Parameters

The parent key for all of the following parameters is openshift4_console.

namespace

type

string

default

openshift-console

The namespace where the console is deployed.

It’s not recommended to change this parameter. Changing the parameter might break the components function.

namespace_annotations

type

dictionary

default
openshift.io/node-selector: node-role.kubernetes.io/master=

Annotations to add to the managed namespace. Annotations can be removed by setting the value to null.

route

type

dictionary

default

{"console": {}, "downloads": {}}

A dictionary holding the configuration for the console and download routes.

The component will look for keys hostname and servingCertKeyPairSecret in the values of keys console and downloads. The component expects that the value of servingCertKeyPairSecret is of the form {"name": "<secret_name>"} and refers to a secret in namespace openshift-config.

config

type

dictionary

default

CRD defaults.

A dictionary holding the .spec for the console config.

See the OpenShift docs for available parameters.

config.managementState

type

enum Managed, Unmanaged, Removed

default

Managed

Indicates whether and how the operator should manage the console.

config.plugins

type

list

default

[]

Add plugins to the console.

config.route

type

dictionary with hostname and secret keys

default

undefined

Create a custom route to access the console. If the route is part of the default apps domain, no TLS cert needs to be specified since the default wildcard cert will be used.

This configuration parameter is deprecated starting with OpenShift 4.8, see the upstream documentation.

The component provides support to use the new recommended configuration via the ingress.config.openshift.io/cluster object, see the documentation for parameters openshift_version and route.

If both this parameter and parameter route are present, parameter route has precedence over this parameter.

type

dictionary

default

{}

Each entry in parameter console_links is deployed onto the cluster as an OpenShift ConsoleLink. The value of the entry will be used as the ConsoleLink specification. Entries with null values are skipped. This allows users to remove links which were configured higher up in the hierarchy.

type

dictionary

default

{}

Add a custom logo to the console. Takes a single key with the filename and the value is the base64 encoded logo. The logo can be a file in any common image format, including GIF, JPG, PNG, or SVG, and is constrained to a max-height of 60px The filename needs to have a filename extension which matches the image format.

For SVG logos the file must not be base64 encoded, but inserted directly as a string.

By default, OCP won’t serve a favicon if a custom logo is configured for the console. This is an intentional design decision as documented in this bug report.

The component tries to ensure that a favicon is served even if a custom logo is configured. However, because the current workaround for the missing favicon requires an additional custom route for the console hostname, it can only be implemented for configurations which use a custom console hostname. Otherwise, the component is unable to correctly configure spec.hostname for the console.

secrets

type

dictionary

default

{}

Each entry in parameter secrets is deployed onto the cluster as a Kubernetes Secret with type=kubernetes.io/tls. Entries with null values are skipped. This allows users to remove secrets which were configured higher up in the hierarchy.

The component has basic validation to ensure the secret contents are a plausible Kubernetes TLS secret.

The dictionary keys are used as metadata.name for the resulting Secret resources. The dictionary values are directly merged into a Secret resource which only has type=kubernetes.io/tls set. The secrets are created in the namespace indicated by parameter namespace.

cert_manager_certs

type

dictionary

default

{}

Each entry in parameter cert_manager_certs is deployed onto the cluster as a cert-manager Certificate resource. Entries with null values are skipped. This allows users to remove certificates which were configured higher up in the hierarchy.

The dictionary keys are used as metadata.name and spec.secretName for the resulting Certificate resources. The dictionary values are then directly directly merged into the mostly empty Certificate resources.

OpenShift won’t admit the route for the HTTP01 solver pod unless the Certificate resources are deployed in the same namespace as the web console. This behavior is caused by a security feature in the OpenShift ingress controller operator to not allow malicious actors to abuse hostnames which are already in use in other namespaces.

However, since OpenShift requires that custom TLS secrets for the OpenShift console are stored in namespace openshift-config, we deploy a Kyverno policy to clone the TLS secret created by cert-manager into namespace openshift-config for each Certificate resource. Because of that, the component requires that Kyverno is installed on the cluster via the Commodore component kyverno, when Certificate resources are configured in the hierarchy.

Example: Custom hostname in cluster’s app domain

openshift4_console:
  route:
    console:
      hostname: console.apps.example.com

Example: Custom hostname outside cluster’s app domain

In this case we need to specify a custom certificate:

openshift4_console:
  route:
    console:
      hostname: console.cluster.example.com
      servingCertKeyPairSecret:
        name: console-cluster-example-com-tls (1)
  secrets:
    console-cluster-example-com-tls:
      stringData:
        tls.crt: ?{vaultkv:${cluster:tenant}/${cluster:name}/openshift4-console/certificates/cert} (2)
        tls.key: ?{vaultkv:${cluster:tenant}/${cluster:name}/openshift4-console/certificates/key} (3)
1 A secret with keys tls.crt and tls.key with this name must exist in namespace openshift-config.
2 Reference to the console hostname TLS certificate in Vault
3 Reference to the console hostname TLS private key in Vault

Example: Custom hostname outside cluster’s app domain with cert-manager certificate

This configuration assumes that the DNS record for console.cluster.example.com points to the cluster’s application LBs, ideally as a CNAME to the cluster’s application domain. This is required so that cert-manager can request the Let’s Encrypt certificate using a HTTP01 challenge.

openshift4_console:
  route:
    console:
      hostname: console.cluster.example.com
      servingCertKeyPairSecret:
        name: console-cluster-example-com-tls (1)
  cert_manager_certs:
    console-cluster-example-com-tls:
      spec:
        dnsNames:
          - console.cluster.example.com
        issuerRef:
          name: letsencrypt-production
          kind: ClusterIssuer
openshift4_console:
  console_links:
    homepage: (1)
      href: 'https://www.example.com/'
      location: ApplicationMenu
      text: Home
      applicationMenu:
        section: Company
        # image that is 24x24 in size
        imageURL: https://via.placeholder.com/24
    user-docs: (2)
      href: 'https://docs.example.com/'
      location: HelpMenu
      text: User Documentation
    project-link: (3)
      href: 'https://docs.example.com/organization/'
      location: HelpMenu
      text: User Documentation
      namespaceDashboard:
        matchExpressions:
         - key: organization
           operation: Exists
  custom_logo:
    logo.png: |- (4)
      <base64-encoded_logo>
1 Adds a link to an overflow menu at the top of every page
2 Adds a link to the help menu at the top of every page
3 Adds a link to the dashboard of every namespace with a label organization
4 Provide a single base64-encoded logo and the key needs to have the correct filename extension