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, for example:

--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>

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.

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 the Set up Portworx Backup for Operations. 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

You can access Portworx Backup by directly navigating to one of your node's IP addresses.

1. Find the public/external IP (NODE_IP) of any node in your current Kubernetes cluster.

2. Find the node port (NODE_PORT) of the px-backup-ui service.

   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.

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

   • Host:

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

   • IP:

     kubectl get ingress --namespace <pxb-namespace> px-backup-ui-ingress -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/

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.