Configure Access to Portworx Backup Web Console

Applicable to both Classic and Federated modes

Choose an access model for the Portworx Backup web console

You access the Portworx Backup web console through the px-backup-ui Kubernetes service. Its service type is configurable through the Portworx Backup Helm chart, or through the Select Admin UI Access Type field in Portworx Backup SpecGen (Internal Access Only (ClusterIP) or External Access (via Load Balancer)). The service type controls whether the console is reachable only from inside the cluster (ClusterIP) or through an external load balancer endpoint (LoadBalancer). Starting with Portworx Backup 3.1.0, the default service type is ClusterIP, so the console is private by default; you opt in to external exposure by setting LoadBalancer. Choose the exposure model that matches your security requirements before you install.

The installation also deploys a second service, px-central-ui, for the underlying PX-Central platform. To keep the console fully private, apply the same service type and annotations to both px-backup-ui and px-central-ui. The Helm values below cover both services.

caution

On managed cloud platforms, a LoadBalancer service can provision a public, internet-facing endpoint unless you explicitly request an internal (private) load balancer through the service annotations described below. If you want a private admin console, use ClusterIP or keep LoadBalancer with your cloud provider's internal load balancer annotation set.

The following Helm values under service: control UI network exposure:

service:
  ## Service type for the Portworx Backup UI (the console you browse to):
  ## "ClusterIP" (default) or "LoadBalancer".
  pxBackupUIServiceType: "ClusterIP"
  ## Annotations applied to the Portworx Backup UI service (for example, an
  ## internal load balancer annotation).
  pxBackupUIServiceAnnotations: {}
  ## Service type for the underlying PX-Central platform UI. Set this to the
  ## same value as pxBackupUIServiceType to keep the console fully private.
  pxCentralUIServiceType: "ClusterIP"
  ## Annotations applied to the PX-Central UI service.
  pxCentralUIServiceAnnotations: {}
  ## Optional CIDR allow-lists for the UI LoadBalancer services (defense-in-depth).
  pxBackupUILoadBalancerSourceRanges: []
  pxCentralUILoadBalancerSourceRanges: []

You set these values in your values-px-central.yaml file at install time. For where these fit in the installation flow, see Install Portworx Backup Using Portworx Central.

ClusterIP-based access (private)

When you set the UI service type to ClusterIP, the service is reachable only from within the cluster network. This keeps the admin console private and is the recommended option when you do not want to expose the console on an external network. Users reach the UI through one of the following:

• kubectl port-forward to the px-backup-ui service
• A private or internal ingress
• A VPN or bastion host

To use ClusterIP, set the service type values:

service:
  pxBackupUIServiceType: "ClusterIP"
  pxCentralUIServiceType: "ClusterIP"

For example, to reach the console with kubectl port-forward:

kubectl port-forward svc/px-backup-ui -n <pxb-namespace> 8080:80

You can then open http://localhost:8080 in your browser.

LoadBalancer-based access

When you set the UI service type to LoadBalancer, Kubernetes provisions a load balancer endpoint for the UI. On managed cloud platforms, this can create a public, internet-facing endpoint. To keep the console private while still using a load balancer, request an internal (private) load balancer by adding your cloud provider's internal load balancer annotation through pxBackupUIServiceAnnotations and pxCentralUIServiceAnnotations:

service:
  pxBackupUIServiceType: "LoadBalancer"
  pxBackupUIServiceAnnotations: {}
  pxCentralUIServiceType: "LoadBalancer"
  pxCentralUIServiceAnnotations: {}

If you use a LoadBalancer service, you can also use pxBackupUIServiceAnnotations and pxCentralUIServiceAnnotations to pass provider-specific configuration to the corresponding UI services.

Internal load balancer annotations by cloud provider

Add the following annotation to pxBackupUIServiceAnnotations and pxCentralUIServiceAnnotations to request an internal load balancer. The following table lists the internal load balancer annotations qualified with Portworx Backup in this release:

Cloud platform	Annotation
AWS / Amazon EKS / Red Hat OpenShift Service on AWS (ROSA)	service.beta.kubernetes.io/aws-load-balancer-scheme: internal (preferred over the older service.beta.kubernetes.io/aws-load-balancer-internal: "true")
IBM Cloud Kubernetes Service	service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: private

Other managed platforms, such as Azure Kubernetes Service (AKS) and Google Kubernetes Engine (GKE), also support internal load balancers through their own annotations, but those annotations are not qualified with Portworx Backup in this release. Always confirm the exact, current annotation against your cloud provider's documentation, as annotation names change between provider and load balancer versions.

Example (AWS or ROSA) that requests an internal load balancer for both UI services:

service:
  pxBackupUIServiceType: "LoadBalancer"
  pxBackupUIServiceAnnotations:
    service.beta.kubernetes.io/aws-load-balancer-scheme: internal
  pxCentralUIServiceType: "LoadBalancer"
  pxCentralUIServiceAnnotations:
    service.beta.kubernetes.io/aws-load-balancer-scheme: internal

AWS internal Network Load Balancer (NLB) annotations

On AWS and ROSA, you can provision an internal NLB for the UI services. There are two paths depending on which controller manages the load balancer. Apply the same annotations to both pxBackupUIServiceAnnotations and pxCentralUIServiceAnnotations. The aws-load-balancer-subnets annotation is optional — include it (with your private subnets) only when you need to pin the load balancer to specific subnets; otherwise omit it and let the load balancer controller auto-select subnets.

AWS Load Balancer Controller path (recommended if the AWS Load Balancer Controller is installed):

service:
  pxBackupUIServiceType: "LoadBalancer"
  pxBackupUIServiceAnnotations:
    service.beta.kubernetes.io/aws-load-balancer-type: external
    service.beta.kubernetes.io/aws-load-balancer-scheme: internal
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: instance
    service.beta.kubernetes.io/aws-load-balancer-subnets: <subnet-1,subnet-2,subnet-3>   # optional; omit to let the load balancer controller auto-select subnets
  pxCentralUIServiceType: "LoadBalancer"
  pxCentralUIServiceAnnotations:
    service.beta.kubernetes.io/aws-load-balancer-type: external
    service.beta.kubernetes.io/aws-load-balancer-scheme: internal
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: instance
    service.beta.kubernetes.io/aws-load-balancer-subnets: <subnet-1,subnet-2,subnet-3>   # optional; omit to let the load balancer controller auto-select subnets

Legacy / compatibility path (in-tree AWS cloud provider, when the AWS Load Balancer Controller is not used):

service:
  pxBackupUIServiceType: "LoadBalancer"
  pxBackupUIServiceAnnotations:
    service.beta.kubernetes.io/aws-load-balancer-type: nlb
    service.beta.kubernetes.io/aws-load-balancer-internal: "true"
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
    service.beta.kubernetes.io/aws-load-balancer-subnets: <subnet-1,subnet-2,subnet-3>   # optional; omit to let the load balancer controller auto-select subnets
  pxCentralUIServiceType: "LoadBalancer"
  pxCentralUIServiceAnnotations:
    service.beta.kubernetes.io/aws-load-balancer-type: nlb
    service.beta.kubernetes.io/aws-load-balancer-internal: "true"
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
    service.beta.kubernetes.io/aws-load-balancer-subnets: <subnet-1,subnet-2,subnet-3>   # optional; omit to let the load balancer controller auto-select subnets

You can also set the legacy-path annotations directly on the Helm command line. To keep the console fully private, apply the annotations to both pxBackupUIServiceAnnotations and pxCentralUIServiceAnnotations (and set both service types to LoadBalancer), for example:

--set service.pxBackupUIServiceType=LoadBalancer \
--set service.pxCentralUIServiceType=LoadBalancer \
--set service.pxBackupUIServiceAnnotations."service\.beta\.kubernetes\.io/aws-load-balancer-type"=nlb \
--set service.pxBackupUIServiceAnnotations."service\.beta\.kubernetes\.io/aws-load-balancer-internal"=true \
--set service.pxBackupUIServiceAnnotations."service\.beta\.kubernetes\.io/aws-load-balancer-nlb-target-type"=ip \
--set service.pxBackupUIServiceAnnotations."service\.beta\.kubernetes\.io/aws-load-balancer-subnets"=<subnet-1\,subnet-2\,subnet-3> \
--set service.pxCentralUIServiceAnnotations."service\.beta\.kubernetes\.io/aws-load-balancer-type"=nlb \
--set service.pxCentralUIServiceAnnotations."service\.beta\.kubernetes\.io/aws-load-balancer-internal"=true \
--set service.pxCentralUIServiceAnnotations."service\.beta\.kubernetes\.io/aws-load-balancer-nlb-target-type"=ip \
--set service.pxCentralUIServiceAnnotations."service\.beta\.kubernetes\.io/aws-load-balancer-subnets"=<subnet-1\,subnet-2\,subnet-3>

Restrict access with load balancer source ranges

You can further restrict which clients can reach the UI LoadBalancer services by using the pxBackupUILoadBalancerSourceRanges and pxCentralUILoadBalancerSourceRanges values (default []). Each value is an allow-list of client source IP CIDR ranges: when the list is non-empty, the load balancer accepts traffic only from those ranges and drops all other traffic.

Replace the CIDR ranges below with the networks you want to allow (for example, your corporate or VPN egress ranges):

service:
  # Allow only these client networks to reach the Portworx Backup UI:
  pxBackupUILoadBalancerSourceRanges:
    - 203.0.x.x/24   # example: corporate office network
    - 198.51.x.x/32 # example: a single admin workstation
  # Apply the same restriction to the underlying PX-Central platform UI:
  pxCentralUILoadBalancerSourceRanges:
    - 203.0.x.x/24

These lists are rendered as spec.loadBalancerSourceRanges only when the matching service type is LoadBalancer and the list is non-empty.

caution

loadBalancerSourceRanges is a defense-in-depth measure only. Support varies by cloud provider and load balancer implementation, and it is not a substitute for an internal load balancer.

note

The pxBackupUILoadBalancerSourceRanges and pxCentralUILoadBalancerSourceRanges parameters are supported in Portworx Backup 3.1.0 and later.

Configure access to the UI on Kubernetes

This section shows you how you can configure access to the Portworx Backup UI on Kubernetes.

Portworx Backup exposes the UI at two different network layers. The px-backup-ui pods serve the console over HTTP internally, so the layer you choose determines whether external traffic is encrypted and which object you retrieve the endpoint from. Pick the method that matches the access model you set in Choose an access model:

• Layer 7 (Ingress) — HTTPS. An ingress controller (for example, NGINX) sits in front of a ClusterIP px-backup-ui service and terminates TLS on port 443. Keep pxBackupUIServiceType: ClusterIP (the default) — you do not set LoadBalancer for this method — and retrieve the endpoint from the ingress object. Use Expose the UI on ingress and configure access using HTTPS. This is the recommended way to serve the console over HTTPS.
• Layer 4 (Service) — HTTP. A LoadBalancer or NodePort service routes external traffic directly to the px-backup-ui pods, bypassing any ingress controller. Retrieve the endpoint from the service (not from an ingress object); it is plain HTTP unless you terminate TLS at the load balancer. Use Access the load balancer endpoint for a LoadBalancer service, or Access using a node IP for a NodePort service.

Expose the UI on ingress and configure access using HTTPS

You can configure access to Portworx Backup through HTTPS by creating an ingress rule.

1. Modify and paste the following spec into one of your Portworx Backup nodes, entering your own values for the following:

   • spec.rules.host: specify the name of the host on which you've installed Portworx Backup

   • spec.tls.hosts specify the name of the host on which you've installed Portworx Backup

   • spec.tls.hosts.secretName: specify the name of the secret that holds your Kubernetes TLS certificates
     

     cat <<< '
     apiVersion: networking.k8s.io/v1
     kind: Ingress
     metadata:
       annotations:
         ingress.bluemix.net/redirect-to-https: "True"
         kubernetes.io/ingress.class: nginx
         nginx.ingress.kubernetes.io/x-forwarded-port: "443"
       name: px-backup-ui-ingress
       namespace: px-backup
     spec:
       rules:
       - host: <px-backup-host>
         http:
           paths:
           - backend:
               service:
                 name: px-backup-ui
                 port:
                   number: 80
             path: /
             pathType: Prefix
       tls:
       - hosts:
         - <px-backup-host>
         secretName: <TLS-backup-secret>
     ' > /tmp/px-backup-ui-ingress.yaml

     note

     The secretName field is only required when you want to terminate TLS on the host/domain. See your cloud provider for specific examples:

     • AKS
     • EKS

2. Apply the spec:

   kubectl apply -f /tmp/px-backup-ui-ingress.yaml

3. Retrieve the INGRESS_ENDPOINT using the kubectl get ingress command:

   kubectl get ingress px-backup-ui-ingress --namespace <pxb-namespace> -o jsonpath="{.status.loadBalancer.ingress[0].hostname}"

   Once you have retrieved the INGRESS_ENDPOINT, you can use it to access the Portworx Backup web console with the HTTPS scheme. Fetch the random password for the admin user as described in Retrieve admin credentials and sign in. Use the retrieved credentials to log in:

   https://INGRESS_ENDPOINT

   Additionally, you can access the Keycloak UI at the /auth/ path:

   https://INGRESS_ENDPOINT/auth/

Access the Portworx Backup UI using a node IP

As a fallback for restricted scenarios, such as a lab or an isolated air-gapped cluster where an ingress or load balancer is not available, you can reach Portworx Backup directly through a node's IP address. This is not the recommended method for production; prefer the ingress (HTTPS) or an internal LoadBalancer method. Review the following note and caution before you use it.

note

This method requires the px-backup-ui service to use the NodePort service type. The supported access models on this page configure pxBackupUIServiceType as ClusterIP (default) or LoadBalancer, neither of which allocates a node port. Unless you have explicitly configured the px-backup-ui service as type: NodePort, a NODE_PORT is not available and you cannot use this method. Instead, use the LoadBalancer endpoint or ingress method.

caution

A node's public/external IP exposes the administrative console directly on the node network, bypassing cluster ingress controls, private-subnet designs, and load-balancer source-range allow-lists. Prefer an internal LoadBalancer (with pxBackupUILoadBalancerSourceRanges) or an ingress with TLS. If you must use a node IP, use a private/internal node address and restrict access with firewall or security-group rules.

1. Find the IP (NODE_IP) of a node in your current Kubernetes cluster. Use a private/internal node address wherever possible.

2. Find the node port (NODE_PORT) of the px-backup-ui service (available only when the service is of type NodePort).

   Once you have found the node IP and port, you can combine them to access the Portworx Backup UI:

   http://NODE_IP:NODE_PORT

   Additionally, you can access the Keycloak UI at the /auth/ path:

   http://NODE_IP:NODE_PORT/auth/

   note

   You can access Portworx Backup web console with node IP in both internet-connected and air-gapped environments.

Access the Portworx Backup UI using the load balancer endpoint

You can also access the Portworx Backup UI by navigating to the load balancer using either its host name or IP address.

This method applies when the UI is exposed with pxBackupUIServiceType: LoadBalancer. The endpoint is provisioned on the px-backup-ui Service (not on an ingress object), so retrieve it from the service.

1. Get the loadbalancer endpoint (LB_ENDPOINT) using one of the following commands:

   • Host:

     kubectl get svc --namespace <pxb-namespace> px-backup-ui -o jsonpath="{.status.loadBalancer.ingress[0].hostname}"

   • IP:

     kubectl get svc --namespace <pxb-namespace> px-backup-ui -o jsonpath="{.status.loadBalancer.ingress[0].ip}"

     • Once you have retrieved the load balancer endpoint, you can use it to access the Portworx Backup web console:

       http://LB_ENDPOINT

     • You can access the Keycloak UI at the /auth/ path:

       http://LB_ENDPOINT/auth/

     caution

     A plain LoadBalancer service exposes the console over unencrypted HTTP and, on managed cloud platforms, can provision a public, internet-facing endpoint. To serve the console over HTTPS, terminate TLS at the load balancer or use the ingress method. To keep the endpoint private, use your cloud provider's internal load balancer annotation and restrict clients with pxBackupUILoadBalancerSourceRanges.

Configure access to the Portworx Backup on OpenShift

This section shows how you can configure access to the Portworx Backup web console on OpenShift Container Platform using its web console.

Access the Portworx Backup UI using a route

1. Open the OpenShift Container Platform web console, go to Networking > Routes, and then select the Create Route button.

2. On the Create Route page, configure your route by populating the following fields in Form view:

   • Name: enter a descriptive name
   • Hostname: specify a public hostname. If you leave this field empty, OpenShift will generate a hostname.
   • Path: leave this field unchanged.
   • Service: choose px-backup-ui from the dropdown list.
   • Target Port: choose 80 -> 8080

3. Switch to the YAML view and add the following annotation under the metadata.annotations section of the route to increase the OpenShift Container Platform (OCP) route timeout. The recommended timeout value is 5 minutes. For more information, see Configuring Route Timeouts.

   metadata:
     annotations:
       haproxy.router.openshift.io/timeout: 5m

   note

   You can add or update this annotation after the route is created, under the details of the route in the Annotations section or by editing route specification under YAML tab.

4. When you have finished configuring your route, select the Create button.

5. OpenShift now displays a link to the Portworx Backup UI on the Routes page. To access Portworx Backup web console, select that link.

   note

   If the customer is using AVI load balancer, disable HTTP-only cookies in the AVI web-console to resolve Keycloak access error. To disable, HTTP-only Cookies option, from the AVI home page, navigate to Virtual Services > edit ingress service > Settings > Profiles > Application Profile > choose System-Secure-HTTP from the drop down and then click edit icon > navigate to Security tab > deselect HTTP-only Cookies option.