Chapter 9. Configure networking
Configure networking for OpenShift Dev Spaces to secure communications, enable custom routing, and support restricted environments through network policies, TLS certificates, custom hostnames, and proxy settings.
9.1. Configure network policies Copy linkLink copied to clipboard!
By default, all Pods in an OpenShift cluster can communicate across namespaces. Configure network policies to restrict traffic between workspace Pods in different user projects to improve security through multitenant isolation.
With multitenant isolation, NetworkPolicy objects restrict all incoming traffic to Pods in a user project. However, Pods in the OpenShift Dev Spaces project must still communicate with Pods in user projects.
Prerequisites
- You have an OpenShift cluster with network restrictions such as multitenant isolation.
Procedure
Create an
allow-from-openshift-devspaces.yamlfile. Theallow-from-openshift-devspacesNetworkPolicy allows incoming traffic from the OpenShift Dev Spaces namespace to all Pods in the user project.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-openshift-devspaces spec: ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: openshift-devspaces podSelector: {} policyTypes: - Ingresswhere:
kubernetes.io/metadata.name: openshift-devspaces-
Selects traffic from the OpenShift Dev Spaces namespace. The default namespace is
openshift-devspaces. podSelector: {}-
The empty
podSelectorselects all Pods in the project.
Apply the
allow-from-openshift-devspacesNetworkPolicy to each user project:oc apply -f allow-from-openshift-devspaces.yaml -n <user_namespace>Optional: If you configured multitenant isolation with network policy, create and apply the
allow-from-openshift-apiserverandallow-from-workspaces-namespacesNetworkPolicies toopenshift-devspaces. Theallow-from-openshift-apiserverNetworkPolicy allows incoming traffic from theopenshift-apiservernamespace to thedevworkspace-webhook-server, enabling webhooks. Theallow-from-workspaces-namespacesNetworkPolicy allows incoming traffic from each user project to theche-gatewaypod.Create an
allow-from-openshift-apiserver.yamlfile:apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-openshift-apiserver namespace: openshift-devspaces spec: podSelector: matchLabels: app.kubernetes.io/name: devworkspace-webhook-server ingress: - from: - podSelector: {} namespaceSelector: matchLabels: kubernetes.io/metadata.name: openshift-apiserver policyTypes: - Ingresswhere:
namespace: openshift-devspaces-
The OpenShift Dev Spaces namespace. The default is
openshift-devspaces. app.kubernetes.io/name: devworkspace-webhook-server-
The
podSelectoronly selects devworkspace-webhook-server pods.
Create an
allow-from-workspaces-namespaces.yamlfile:apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-workspaces-namespaces namespace: openshift-devspaces spec: podSelector: {} ingress: - from: - podSelector: {} namespaceSelector: matchLabels: app.kubernetes.io/component: workspaces-namespace policyTypes: - Ingresswhere:
namespace: openshift-devspaces-
The OpenShift Dev Spaces namespace. The default is
openshift-devspaces. podSelector: {}-
The empty
podSelectorselects all pods in the OpenShift Dev Spaces namespace.
Apply both NetworkPolicies:
oc apply -f allow-from-openshift-apiserver.yaml -n openshift-devspaces oc apply -f allow-from-workspaces-namespaces.yaml -n openshift-devspaces
Verification
Verify that the NetworkPolicy is applied in the user namespace:
oc get networkpolicy -n <user_namespace>- Start a workspace and verify that the workspace can communicate with the OpenShift Dev Spaces server.
9.2. Configure OpenShift Dev Spaces hostname Copy linkLink copied to clipboard!
Configure OpenShift Dev Spaces to use a custom hostname instead of the default cluster-assigned URL to align with corporate DNS standards and branding requirements.
Prerequisites
-
You have an active
ocsession with administrative permissions to the destination OpenShift cluster. See Getting started with the CLI. - You have the certificate and the private key files generated by the same certification authority (CA) used for other OpenShift Dev Spaces hosts.
- You have the custom hostname configured to point to the cluster ingress with your DNS provider.
Procedure
Pre-create a project for OpenShift Dev Spaces:
$ oc create project openshift-devspacesCreate a TLS secret:
$ oc create secret tls <tls_secret_name> \ --key <key_file> \ --cert <cert_file> \ -n openshift-devspaceswhere:
<tls_secret_name>- The TLS secret name.
--key- A file with the private key.
--cert- A file with the certificate.
Add the required labels to the secret:
$ oc label secret <tls_secret_name> \ app.kubernetes.io/part-of=che.eclipse.org -n openshift-devspaceswhere:
<tls_secret_name>- The TLS secret name.
Configure the
CheClusterCustom Resource:spec: networking: hostname: <hostname> tlsSecretName: <secret>where:
<hostname>- Custom Red Hat OpenShift Dev Spaces server hostname.
<secret>- The TLS secret name.
- If OpenShift Dev Spaces is already deployed, wait for the rollout of all OpenShift Dev Spaces components to complete.
Verification
- Verify that the OpenShift Dev Spaces Dashboard is accessible at the custom hostname.
9.3. Import untrusted TLS certificates to OpenShift Dev Spaces Copy linkLink copied to clipboard!
Import TLS certificate authority (CA) chains for external services into OpenShift Dev Spaces. This enables the server, dashboard, and workspaces to establish trusted encrypted connections to proxies, identity providers, and Git servers.
OpenShift Dev Spaces uses labeled ConfigMaps in OpenShift Dev Spaces project as sources for TLS certificates. The ConfigMaps can have an arbitrary amount of keys with an arbitrary amount of certificates each. All certificates are mounted into:
-
/public-certslocation of OpenShift Dev Spaces server and dashboard pods -
/etc/pki/ca-trust/extracted/pemlocations of workspaces pods
Configure the CheCluster Custom Resource to disable CA bundle mounting at /etc/pki/ca-trust/extracted/pem. The certificates are instead mounted at /public-certs to keep the behavior from the previous version.
Configure the CheCluster Custom Resource to disable the mounting of the CA bundle under the path /etc/pki/ca-trust/extracted/pem. Certificates are mounted under the path /public-certs in this case.
spec:
devEnvironments:
trustedCerts:
disableWorkspaceCaBundleMount: true
On an OpenShift cluster, OpenShift Dev Spaces operator automatically adds Red Hat Enterprise Linux CoreOS (RHCOS) trust bundle into mounted certificates.
Prerequisites
-
You have an active
ocsession with administrative permissions to the destination OpenShift cluster. See Getting started with the CLI. -
You have the
openshift-devspacesproject created. -
You have the root CA and intermediate certificates for each CA chain to import, in PEM format, in a
ca-cert-for-devspaces-<count>.pemfile.
Procedure
Concatenate all CA chains PEM files to import, into the
custom-ca-certificates.pemfile, and remove the return character that is incompatible with the Java truststore.$ cat ca-cert-for-devspaces-*.pem | tr -d '\r' > custom-ca-certificates.pemCreate the
custom-ca-certificatesConfigMap with the required TLS certificates:$ oc create configmap custom-ca-certificates \ --from-file=custom-ca-certificates.pem \ --namespace=openshift-devspacesLabel the
custom-ca-certificatesConfigMap:$ oc label configmap custom-ca-certificates \ app.kubernetes.io/component=ca-bundle \ app.kubernetes.io/part-of=che.eclipse.org \ --namespace=openshift-devspaces- Deploy OpenShift Dev Spaces if it has not been deployed before. Otherwise, wait until the rollout of OpenShift Dev Spaces components finishes.
- Restart running workspaces for the changes to take effect.
Verification
Verify that the ConfigMap contains your custom CA certificates. This command returns CA bundle certificates in PEM format:
oc get configmap \ --namespace=openshift-devspaces \ --output='jsonpath={.items[0:].data.custom-ca-certificates\.pem}' \ --selector=app.kubernetes.io/component=ca-bundle,app.kubernetes.io/part-of=che.eclipse.orgVerify in the OpenShift Dev Spaces server logs that the imported certificates count is not null:
oc logs deploy/devspaces --namespace=openshift-devspaces \ | grep tls-ca-bundle.pem- Start a workspace, get the project name in which it has been created: <workspace_namespace>, and wait for the workspace to be started.
Verify that the
ca-certs-mergedConfigMap contains your custom CA certificates. This command returns OpenShift Dev Spaces CA bundle certificates in PEM format:oc get configmap ca-certs-merged \ --namespace=<workspace_namespace> \ --output='jsonpath={.data.tls-ca-bundle\.pem}'Verify that the workspace pod mounts the
ca-certs-mergedConfigMap:oc get pod \ --namespace=<workspace_namespace> \ --selector='controller.devfile.io/devworkspace_name=<workspace_name>' \ --output='jsonpath={.items[0:].spec.volumes[0:].configMap.name}' \ | grep ca-certs-mergedGet the workspace pod name <workspace_pod_name>:
oc get pod \ --namespace=<workspace_namespace> \ --selector='controller.devfile.io/devworkspace_name=<workspace_name>' \ --output='jsonpath={.items[0:].metadata.name}'Verify that the workspace container has your custom CA certificates. This command returns OpenShift Dev Spaces CA bundle certificates in PEM format:
oc exec <workspace_pod_name> \ --namespace=<workspace_namespace> \ -- cat /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pemOr if
disableWorkspaceCaBundleMountset totrue:oc exec <workspace_pod_name> \ --namespace=<workspace_namespace> \ -- cat /public-certs/tls-ca-bundle.pem
9.4. Configure OpenShift Route to work with Router Sharding Copy linkLink copied to clipboard!
Configure labels, annotations, and domains for OpenShift Route to direct OpenShift Dev Spaces traffic to the correct ingress controller when using Router Sharding on an OpenShift cluster.
Prerequisites
-
You have an active
ocsession with administrative permissions to the OpenShift cluster. See Getting started with the OpenShift CLI. -
You have the
dscmanagement tool installed. See Installing the dsc management tool.
Procedure
Configure the
CheClusterCustom Resource. See Section 2.2, “Use the CLI to configure the CheCluster Custom Resource”.spec: networking: labels: <labels> domain: <domain> annotations: <annotations>where:
<labels>- An unstructured key value map of labels that the target ingress controller uses to filter the set of Routes to service.
<domain>- The DNS name serviced by the target ingress controller.
<annotations>- An unstructured key value map stored with a resource.
Verification
Verify that OpenShift Dev Spaces routes have the configured labels and annotations:
oc get routes -n openshift-devspaces -o yaml
9.5. Configure workspace endpoints base domain Copy linkLink copied to clipboard!
Configure a custom base domain for workspace endpoints to align URLs with your organization’s DNS naming conventions. By default, the OpenShift Dev Spaces Operator detects the base domain automatically.
Prerequisites
-
You have an active
ocsession with administrative permissions to the destination OpenShift cluster. See Getting started with the CLI.
Procedure
Set the
CHE_INFRA_OPENSHIFT_ROUTE_HOST_DOMAIN__SUFFIXfield in theCheClusterCustom Resource:spec: components: cheServer: extraProperties: CHE_INFRA_OPENSHIFT_ROUTE_HOST_DOMAIN__SUFFIX: "<base_domain>"1 - 1
- Workspace endpoints base domain, for example,
my-devspaces.example.com.
Apply the change:
oc patch checluster/devspaces \ --namespace openshift-devspaces \ --type='merge' -p \ '{"spec": {"components": {"cheServer": {"extraProperties": {"CHE_INFRA_OPENSHIFT_ROUTE_HOST_DOMAIN__SUFFIX": "my-devspaces.example.com"}}}}}'
Verification
Verify the
CHE_INFRA_OPENSHIFT_ROUTE_HOST_DOMAIN__SUFFIXvalue in theCheClusterCustom Resource:oc get checluster devspaces -n openshift-devspaces -o jsonpath='{.spec.components.cheServer.extraProperties.CHE_INFRA_OPENSHIFT_ROUTE_HOST_DOMAIN__SUFFIX}'
9.6. Configure proxy Copy linkLink copied to clipboard!
Configure a proxy for Red Hat OpenShift Dev Spaces by creating a Kubernetes Secret for proxy credentials and configuring the necessary proxy settings in the CheCluster custom resource. The proxy settings are propagated to the operands and workspaces through environment variables.
On an OpenShift cluster, you do not need to configure proxy settings. OpenShift Dev Spaces Operator automatically uses the OpenShift cluster-wide proxy configuration. However, you can override the proxy settings by specifying them in the CheCluster custom resource.
Prerequisites
-
You have an active
ocsession with administrative permissions to the destination OpenShift cluster. See Getting started with the CLI.
Procedure
Optional: Create a Secret in the openshift-devspaces namespace that contains a user and password for a proxy server. The secret must have the
app.kubernetes.io/part-of=che.eclipse.orglabel. Skip this step if the proxy server does not require authentication.oc apply -f - <<EOF kind: Secret apiVersion: v1 metadata: name: devspaces-proxy-credentials namespace: openshift-devspaces labels: app.kubernetes.io/part-of: che.eclipse.org type: Opaque stringData: user: <user> password: <password> EOFwhere:
<user>- The username for the proxy server.
<password>- The password for the proxy server.
Configure the proxy or override the cluster-wide proxy configuration for an OpenShift cluster by setting the following properties in the CheCluster custom resource:
oc patch checluster/devspaces \ --namespace openshift-devspaces \ --type='merge' -p \ '{"spec": {"components": {"cheServer": {"proxy": {"credentialsSecretName" : "<secretName>", "nonProxyHosts" : ["<host_1>"], "port" : "<port>", "url" : "<protocol>://<domain>"}}}}}'where:
<secretName>- The credentials secret name created in the previous step.
<host_1>-
The list of hosts that can be reached directly, without using the proxy. Use the following form
.<DOMAIN>to specify a wildcard domain. OpenShift Dev Spaces Operator automatically adds .svc and Kubernetes service host to the list of non-proxy hosts. In OpenShift, OpenShift Dev Spaces Operator combines the non-proxy host list from the cluster-wide proxy configuration with the custom resource. In some proxy configurations,localhostmay not translate to127.0.0.1. Bothlocalhostand127.0.0.1should be specified in this situation. <port>- The port of the proxy server.
<protocol>://<domain>- Protocol and domain of the proxy server.
Verification
- Start a workspace.
-
Verify that the workspace pod contains
HTTP_PROXY,HTTPS_PROXY,http_proxy, andhttps_proxyenvironment variables, each set to<protocol>://<user>:<password>@<domain>:<port>. -
Verify that the workspace pod contains
NO_PROXYandno_proxyenvironment variables, each set to a comma-separated list of non-proxy hosts.