API Rule with mutators section set to Allow does not work

[mjakobczyk]

Description

According to the current API Gateway documentation in order to expose a service by creating an APIRule CR we can make use of an yaml example that is presented in this section - https://kyma-project.io/docs/components/api-gateway#tutorials-expose-a-service Unfortunately, it turns out that if you set an Allow in mutators section then APIRule will not be applied properly and results in Resource not found error after trying to access the exposed resource.

Found in the latest Kyma v1.18 release.

Expected result

• including mutators section with Allow set should not crash API Rule
• hint in documentation should be present to inform not to use mutators section when using Allow access strategy

Actual result

For now such error is presented: {"error":{"code":404,"status":"Not Found","request":"(code)","message":"The requested resource could not be found"}}

Steps to reproduce

Try to apply a new API Rule using following schema: (example is being taken straight from docs, please check the link above)

apiVersion: gateway.kyma-project.io/v1alpha1
kind: APIRule
metadata:
  name: httpbin
spec:
  service:
    host: httpbin.$DOMAIN
    name: httpbin
    port: 8000
  gateway: kyma-gateway.kyma-system.svc.cluster.local
  rules:
    - path: /.*
      methods: ["GET"]
      accessStrategies:
        - handler: allow
      mutators:
        - handler: allow
    - path: /post
      methods: ["POST"]
      accessStrategies:
        - handler: allow
      mutators:
        - handler: allow

Troubleshooting

It looks like Allow access strategy is not being supported by the Oathkeeper under the hood - it does not recognise Removing mutators section completely makes the API Rule work. On basis of example present before, this should work:

apiVersion: gateway.kyma-project.io/v1alpha1
kind: APIRule
metadata:
  name: httpbin
spec:
  service:
    host: httpbin.$DOMAIN
    name: httpbin
    port: 8000
  gateway: kyma-gateway.kyma-system.svc.cluster.local
  rules:
    - path: /.*
      methods: ["GET"]
      accessStrategies:
        - handler: allow
    - path: /post
      methods: ["POST"]
      accessStrategies:
        - handler: allow

[kubadz]

One comment from my side:

accessStrategy named Allow is different than other accessStrategies because it exposes the service directly via Istio VirtualService bypassing the Oathkeeper proxy. As mutators are a feature of Oathkeeper, there is no possibility to use them while using Allow accessStrategy. I agree with Michał that we should mention it in the documentation. IMO APIGateway should simply ignore the mutator in this case, whereas currently when it sees that mutator is configured, it treats the whole configuration like it was configured with other accessStrategy than Allow (it creates an Oathkeeper rule with AllowaccessStrategy, which is not valid in Oathkeeper).

[kyma-stale-bot[bot]]

This issue has been automatically marked as stale due to the lack of recent activity. It will soon be closed if no further activity occurs. Thank you for your contributions.

[kyma-stale-bot[bot]]

This issue has been automatically marked as stale due to the lack of recent activity. It will soon be closed if no further activity occurs. Thank you for your contributions.

[kyma-stale-bot[bot]]

This issue has been automatically marked as stale due to the lack of recent activity. It will soon be closed if no further activity occurs. Thank you for your contributions.

[kyma-stale-bot[bot]]

This issue has been automatically marked as stale due to the lack of recent activity. It will soon be closed if no further activity occurs. Thank you for your contributions.

[kyma-stale-bot[bot]]

This issue has been automatically closed due to the lack of recent activity.

[kyma-stale-bot[bot]]

This issue has been automatically marked as stale due to the lack of recent activity. It will soon be closed if no further activity occurs. Thank you for your contributions.

[kyma-stale-bot[bot]]

This issue has been automatically marked as stale due to the lack of recent activity. It will soon be closed if no further activity occurs. Thank you for your contributions.

[werdes72]

/remove-lifecycle stale

[kyma-stale-bot[bot]]

This issue has been automatically marked as stale due to the lack of recent activity. It will soon be closed if no further activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue has been automatically marked as stale due to the lack of recent activity. It will soon be closed if no further activity occurs. Thank you for your contributions.

[kyma-bot]

This issue or PR has been automatically marked as stale due to the lack of recent activity. Thank you for your contributions.

This bot triages issues and PRs according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 7d of inactivity since lifecycle/stale was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Close this issue or PR with /close

If you think that I work incorrectly, kindly raise an issue with the problem.

/lifecycle stale

[kyma-bot]

This issue or PR has been automatically closed due to the lack of activity. Thank you for your contributions.

This bot triages issues and PRs according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 7d of inactivity since lifecycle/stale was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle stale

If you think that I work incorrectly, kindly raise an issue with the problem.

/close

[kyma-bot]

@kyma-bot: Closing this issue.

In response to this:

This issue or PR has been automatically closed due to the lack of activity. Thank you for your contributions.

This bot triages issues and PRs according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 7d of inactivity since lifecycle/stale was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle stale

If you think that I work incorrectly, kindly raise an issue with the problem.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.