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
skupperoptions 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 theconsole-userandconsole-passwordoptions. -
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 toadmin. --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
NoteAll 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
projectAofclusterAand link that site to a service network where thedatabaseservice is exposed, thedatabaseservice is available to pods inprojectBofclusterA.You can use the
--create-network-policyoption to restrict thedatabaseservice access toprojectAofclusterA.