Can KOTS Admin be placed behind a AWS ALB with a SSL cert?

Due to corp firewalls, port :8800 is not open, making access to the KOTS Admin page a logistical nightmare. I was able to create an AWS ALB that listens on :443 with an ACM cert for jama-admin.moms-spaghetti.com that will match on the host header to send the request to a target group on :8800. And this seemed to be all good until getting to the Secure the Admin Console page (https://jama-admin.moms-spaghetti.com/tls-warning). When I hit Continue, I got The page isn’t redirecting properly error when being sent to https://jama-admin.moms-spaghetti.com/tls.

We have some documentation for setting up different load balancers depending on the cloud provider. You can see that here: https://kurl.sh/docs/install-with-kurl/public-cloud-load-balancing#aws-network-load-balancer-internalinternet-facing

Cloud load balancer configuration is out of scope for Replicated products. We provide guidance to demonstrate some configurations that can work this is not an exhaustive list of how load balancing can be configured in cloud environments.

If you have a specific question on routing and you’re already familiar with this documentation I recommend collecting a support bundle from the instance after generating test traffic and opening a support case. We can review if there is anything wrong with the Replicated products or see if there is any advice we can give on the cloud side.

To really help with this we need a good bit of detail on how you’re testing, how you desire for termination to be done (do you mean to terminate at the LoadBalancer or do you mean to pass through and terminate in the cluster, do you even care where it terminates), and logs showing what failure you are seeing.

That document refers to the Kubernetes API, not to KOTS Admin UI.

Hello :wave:

The doc that Chris mentioned is the extent of the documentation that we have on Load Balancers and Replicated installations.

I believe we have other Vendors whose customers have attempted this and the main consideration is that since the Admin Console terminates TLS, you’ll want to make sure that your target group is an HTTPS target group so that the request to the backend isn’t HTTP otherwise you’ll end up with redirects.

If you still aren’t having any luck despite using HTTPS as the protocol for the target group, as a workaround you could try creating a one-off Kubernetes Service object of type NodePort for the Admin Console that points directly to the kotsadm service instead of the kurl-proxy service(which is what’s terminating TLS) and then use that NodePort service for the target group in your ALB.

apiVersion: v1
kind: Service
metadata:
  name: kotsadm-alb-nodeport-svc
  namespace: default
spec:
  ports:
  - name: http
    nodePort: <your-node-port-goes-here>
    port: 3000
    protocol: TCP
    targetPort: http
  selector:
    app: kotsadm
  type: NodePort

NOTE: This comes with the downside of having to maintain that K8s object standalone or potentially add it to the Jama Replicated release. Also, requests from the ALB to the Admin Console would then be unencrypted which may be acceptable given the use case.