Chapter 3. Custom sites

The default skupper init creates sites that satisfy typical requirements.

If you require a custom configuration, note the following options:

  • Creating a site without a console:

    $ skupper init --enable-console false
  • Configuring console authentication. There are a number of skupper options regarding authentication for the console:

    --console-auth <authentication-mode>

    Set the authentication mode for the console:

    • openshift - Use OpenShift authentication, so that users who have permission to log into OpenShift and view the Project (namespace) can view the console.
    • internal - Use Application Interconnect authentication, see the console-user and console-password options.
    • unsecured - No authentication, anyone with the URL can view the console.
    --console-user <username>
    Username for the console user when authentication mode is set to internal. Defaults to admin.
    --console-password <password>
    Password for the console user when authentication mode is set to internal. If not specified, a random passwords is generated.
  • Configuring service access

    $ skupper init --create-network-policy
    Note

    All sites are associated with a namespace, called the active namespace in this procedure.

    Services in the active namespace may be accessible to pods in other namespaces on that cluster by default, depending on your cluster network policies. As a result, you can expose services to pods in namespaces not directly connected to the service network. This setting applies a network policy to restrict access to services to those pods in the active namespace.

    For example, if you create a site in the namespace projectA of clusterA and link that site to a service network where the database service is exposed, the database service is available to pods in projectB of clusterA.

    You can use the --create-network-policy option to restrict the database service access to projectA of clusterA.