kyma-project / api-gateway

Apache License 2.0
4 stars 26 forks source link

Migration from APIRule v1beta1 noop handler to v2alpha1 noAuth causes downtime #1281

Open strekm opened 1 week ago

strekm commented 1 week ago

Description

Migration from APIRule v1beta1 noop handler to v2alpha1 noAuth causes downtime. For some period of time calling exposed workload returns 403.

Expected result

Exposed workload responds with 200

Actual result

Exposed workload responds with 403

Steps to reproduce

export NAMESPACE=test
export GATEWAY=kyma-system/kyma-gateway
export DOMAIN_TO_EXPOSE_WORKLOADS={KYMA_DOMAIN}

kubectl create ns $NAMESPACE                                                                                   
kubectl label namespace $NAMESPACE istio-injection=enabled --overwrite

kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.22/samples/httpbin/httpbin.yaml -n $NAMESPACE

cat <<EOF | kubectl apply -f -
apiVersion: gateway.kyma-project.io/v1beta1 
kind: APIRule
metadata:
  name: httpbin
  namespace: $NAMESPACE
spec:
  host: httpbin.$DOMAIN_TO_EXPOSE_WORKLOADS
  service:
    name: httpbin
    namespace: $NAMESPACE
    port: 8000
  gateway: $GATEWAY
  rules:
    - path: /headers     
      methods: ["GET"]
      accessStrategies:
        - handler: noop
EOF

curl -ik -X GET https://httpbin.$DOMAIN_TO_EXPOSE_WORKLOADS/headers -H "test:true" -> 200

cat <<EOF | kubectl apply -f -
apiVersion: gateway.kyma-project.io/v2alpha1
kind: APIRule
metadata:
  name: httpbin
  namespace: $NAMESPACE
spec:
  hosts: 
    - httpbin.$DOMAIN_TO_EXPOSE_WORKLOADS
  service:
    name: httpbin
    namespace: $NAMESPACE
    port: 8000
  gateway: $GATEWAY
  rules:
    - path: /headers
      methods: ["GET"]
      noAuth: true
EOF

curl -ik -X GET https://httpbin.$DOMAIN_TO_EXPOSE_WORKLOADS/headers -H "test:true" -> 403 then 200

PR

strekm commented 1 week ago

so migration from allow and no_auth to noAuth both works. did not get to check if jwt -> noAuth works

barchw commented 4 days ago

Issue is reproducible. 403 happens until the VS is switched directly to service, so it most likely means that oathkeeper is not allowed to access the endpoint in an authorization policy