To configure X.509 authentication on the same endpoint as regular authentication in PingFederate on GCP using Helm charts, you'll need to customize the configuration a bit since the default Helm charts do not include annotations or variables for X.509 configuration.

• Ensure that PingFederate has access to the correct certificates (server and client) and that the certificates are properly mounted and referenced.
• Be mindful of security concerns, such as securing the private keys for the X.509 authentication.
• Make sure to properly test this setup in a development environment before rolling it out to production.

Brandon Alexander You are right about customizing the helm chart. Some annotations are missing. We had tried updating the ingress end-points in yaml file, but it is not working on same end-point. Have you tried this before? If yes, would it possible to share the updating yaml portion please?

Really appreciate your response.

I can help you with updating the ingress endpoints in a Kubernetes YAML file.

When you're updating the ingress endpoints, you generally modify the Ingress resource, which controls the routing of external HTTP and HTTPS traffic to services in your Kubernetes cluster. If updating the endpoints isn't working, it might be an issue with the annotations or the configuration of the ingress resource.

Here is a typical example of how you might modify an Ingress YAML file to update the ingress endpoint:

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

name: my-ingress

annotations:

# Update the ingress annotations if needed (e.g., for ingress controllers like NGINX or Traefik)

nginx.ingress.kubernetes.io/rewrite-target: /

nginx.ingress.kubernetes.io/ssl-redirect: "false" # Example: Disable SSL redirection if needed

nginx.ingress.kubernetes.io/secure-backends: "true" # Use secure backends if applicable

spec:

rules:

- host: "new-endpoint.example.com" # Update this with your new endpoint

http:

paths:

- path: /

pathType: Prefix

backend:

service:

name: my-service # The name of the service to route traffic to

port:

number: 80

Troubleshooting Tips:

• Check Ingress Controller Logs: If the update is not reflecting, check the logs of your ingress controller (e.g., NGINX) to see if there are any errors related to your ingress resource.For example, for NGINX: bashCopykubectl logs -n
• Ensure DNS Resolution: If you're using a new endpoint (new-endpoint.example.com), ensure that the DNS records are properly configured to resolve to your ingress controller's external IP or LoadBalancer.
• Reapply the Ingress Resource: After updating the YAML file, you can apply the changes with: bashCopykubectl apply -f ingress.yaml

Let me know if you'd like more specific assistance based on your current configuration or if you're using a specific ingress controller!

Brandon Alexander

Wow, that's great. Is this ingress specific to global load balancer? Our GCP expert is saying that there is a limitation with GCP load balancer to use 2 different ports on same endpoint name.

Lets say the end point name is sso.company.com, but wanted two ports 443 and 4444. 443 port is for regular authentication and 4444 is for x509 authentication.

Do you think that annotation you had provided would work for GCP as well?

Thank you

Mahendra

The annotation I provided earlier might not directly apply to GCP's global load balancer for your scenario. GCP's load balancer, especially the HTTP(S) load balancer, typically routes traffic based on URL paths, hostnames, and sometimes query parameters, but it doesn’t natively allow different ports on the same endpoint (e.g., sso.company.com:443 and sso.company.com:4444) to route to different backend services.

Why the GCP Load Balancer might not support two different ports for the same endpoint:

Possible Workarounds:

Bottom Line:

If you want to use two ports (443 and 4444) for the same endpoint on GCP's load balancer, you'd face a challenge since the GCP HTTP(S) load balancer does not support port-based routing natively. Instead, you would need either multiple load balancers or a workaround like path-based routing.

Below are some potential coded examples for setting up GCP’s load balancer for different use cases, including path-based routing and the setup of multiple load balancers.

Example 1: Path-Based Routing on a Single Load Balancer

If you want to avoid using two different ports and instead route traffic based on the URL path (e.g., /auth for regular authentication and /x509 for X.509 authentication), you can achieve this using a single load balancer.

In this example, we will set up routing based on different paths:

• sso.company.com/auth routes to the regular authentication backend.
• sso.company.com/x509 routes to the X.509 authentication backend.

Step 1: Create HTTP(S) Load Balancer with Path-Based Routing

bashCopygcloud compute backend-services create auth-backend-service \ --global \ --protocol=HTTP gcloud compute backend-services create x509-backend-service \ --global \ --protocol=HTTP

bashCopygcloud compute url-maps create sso-url-map \ --default-service=auth-backend-service \ --path-matcher-name=auth-routes \ --path-rules='/auth/*=auth-backend-service,/x509/*=x509-backend-service'

• This URL map says: route requests with /auth/* to auth-backend-service and requests with /x509/* to x509-backend-service.

bashCopygcloud compute target-http-proxies create sso-http-proxy \ --url-map=sso-url-map

bashCopygcloud compute forwarding-rules create sso-forwarding-rule \ --global \ --target-http-proxy=sso-http-proxy \ --ports=80 \ --address=YOUR_EXTERNAL_IP

You would need to replace YOUR_EXTERNAL_IP with your external IP address or let GCP assign one.

Step 2: Set Up the Backend Services for Regular and X.509 Authentication

bashCopygcloud compute backend-services add-backend auth-backend-service \ --global \ --instance-group=your-auth-instance-group \ --instance-group-zone=your-zone

bashCopygcloud compute backend-services add-backend x509-backend-service \ --global \ --instance-group=your-x509-instance-group \ --instance-group-zone=your-zone

Result:

Now, requests to sso.company.com/auth would route to the regular authentication backend, and requests to sso.company.com/x509 would route to the X.509 authentication backend, all handled through a single load balancer.

Example 2: Multiple Load Balancers (One per Port)

If you must use different ports (e.g., port 443 for regular authentication and port 4444 for X.509 authentication), you'd need to create multiple load balancers, one for each port.

Step 1: Set Up Load Balancer for Regular Authentication on Port 443

bashCopygcloud compute backend-services create auth-backend-service \ --global \ --protocol=HTTPS

bashCopygcloud compute target-https-proxies create auth-https-proxy \ --url-map=auth-url-map \ --ssl-certificates=your-ssl-certificate

bashCopygcloud compute forwarding-rules create auth-forwarding-rule \ --global \ --target-https-proxy=auth-https-proxy \ --ports=443 \ --address=YOUR_EXTERNAL_IP

Step 2: Set Up Load Balancer for X.509 Authentication on Port 4444

bashCopygcloud compute backend-services create x509-backend-service \ --global \ --protocol=HTTPS

bashCopygcloud compute target-https-proxies create x509-https-proxy \ --url-map=x509-url-map \ --ssl-certificates=your-ssl-certificate

bashCopygcloud compute forwarding-rules create x509-forwarding-rule \ --global \ --target-https-proxy=x509-https-proxy \ --ports=4444 \ --address=YOUR_EXTERNAL_IP

Step 3: Backend Setup for Both

bashCopygcloud compute backend-services add-backend auth-backend-service \ --global \ --instance-group=your-auth-instance-group \ --instance-group-zone=your-zone

bashCopygcloud compute backend-services add-backend x509-backend-service \ --global \ --instance-group=your-x509-instance-group \ --instance-group-zone=your-zone

Result:

Now, your traffic for sso.company.com:443 would go to the regular authentication backend, and sso.company.com:4444 would route to the X.509 authentication backend. Each port has its own load balancer, forwarding rule, and backend.

Conclusion

• Option 1 (Path-Based Routing) is recommended because it uses a single load balancer, making it easier to manage. You route based on paths (e.g., /auth and /x509), which is a more scalable and simpler solution.
• Option 2 (Multiple Load Balancers) is a more complex approach that splits the traffic by port (443 and 4444). This is more work and less elegant, but it might be necessary if you cannot modify the URLs or need to strictly separate the two authentication types at the port level.