Conflict with AWS Ingress Controller

[jboutwell-rva]

I've been attempting to use the shinyproxy-operator in a new EKS cluster. I had issues with the operator being able to communicate with the shinyproxy container and looking at operator logs I see:

io.fabric8.kubernetes.client.KubernetesClientException: Failure executing: POST at: https://172.20.0.1/apis/networking.k8s.io/v1/namespaces/shinyproxy/ingresses. Message: Forbidden!Configured service account doesn't have access. Service account may have been revoked. admission webhook "vingress.elbv2.k8s.aws" denied the request: invalid ingress class: IngressClass.networking.k8s.io "skipper" not found.
	at io.fabric8.kubernetes.client.dsl.base.OperationSupport.requestFailure(OperationSupport.java:682) ~[shinyproxy-operator.jar:1.1.0]
	at io.fabric8.kubernetes.client.dsl.base.OperationSupport.requestFailure(OperationSupport.java:661) ~[shinyproxy-operator.jar:1.1.0]

After much digging it appears to be related to the change to use ingressClassName: skipper as opposed to kubernetes.io/ingress.class: "skipper" with version 1.1.0. I don't think this itself is an issue, but the AWS ALB webhook does not seem to agree. I can isolate that change as I cannot create a standalone Ingress with ingressClassName in the cluster without it also failing for the same error. I can't find any related issue online in either skipper or AWS ingress issues, but adding the following IngressClass finally resolved it.

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: skipper
spec:
  controller: k8s.io/skipper # Arbitrary?

I'm outside of my expertise with Kubernetes and Ingress to understand what is the issue (and likely some nuance of AWS Ingress), and I don't know if the above IngressClass will result in other unforeseen issues. Is there something I am miss understanding? Have others run up against any issues when using AWS Ingress? Thanks!

Setup details:
EKS / Kubernetes version 1.23
ShinyProxy Operator version 1.1.0
Applied the 2-namespaced-ds (or near identical) configuration

Other attempts to fix that failed:
Reverting to ShinyProxy Operator 1.0.x (failed because of incompatability with Kubernetes 1.23)
Upgrading skipper to version 0.14.x (no effect)
Using hpa instead of ds (same error)
Banging head into wall (pain)

[LEDfan]

Unfortunately we don't have experience with the AWS Ingress controller. However, we recently released version 2 of the operator which no longer requires Skipper. Therefore I would like to ask to re-try using the latest version of the operator.

[jboutwell-rva]

It did end up working well in production for v2.6.1 with the described workaround.

I have upgraded since to ShinyProxy v3.0.1 / Operator v2.0.0 and the documented Kustomization works out of the box. I'll include by ingress patches for the AWS Load Balancer Controllers for others who many find it helpful. Thanks for all your work on this tool!

  kubernetesIngressPatches: |
    - op: add
      path: /metadata/annotations
      value:
        alb.ingress.kubernetes.io/certificate-arn: <ACM ARN>
        alb.ingress.kubernetes.io/healthcheck-path: /actuator/health
        alb.ingress.kubernetes.io/healthcheck-port: 9090
        alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS":443}]'
        alb.ingress.kubernetes.io/ssl-redirect: '443'
        alb.ingress.kubernetes.io/scheme: internet-facing
        alb.ingress.kubernetes.io/target-type: ip
        external-dns.alpha.kubernetes.io/hostname: <HOST IF USING EXTERNAL DNS>
    - op: add
      path: /spec/ingressClassName
      value: alb

[LEDfan]

Thank you for reporting back! I'm very happy to hear that both the old and new version works fine.