Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AuthPolicy does not recover from error state automatically if root cause of the error got fixed #702

Closed
trepel opened this issue Jun 14, 2024 · 6 comments · May be fixed by #1032
Closed
Assignees
Labels
kind/bug Something isn't working

Comments

@trepel
Copy link
Contributor

trepel commented Jun 14, 2024

Overview

If AuthPolicy gets into "AuthPolicy has encountered some issues: AuthScheme is not ready yet" error state (Accepted=True, Enforced=False) then it is not automatically reconciled to Enforced=True by Kuadrant operator even if the root cause of the error is gone. One has to trigger the reconciliation manually e.g. by updating the AuthPolicy CR.

Steps to reproduce

Basically follow the scenario for identical hostnames: https://github.com/Kuadrant/kuadrant-operator/blob/main/doc/auth.md#limitation-multiple-network-resources-with-identical-hostnames
In short:

  • create two HTTPRoutes declaring identical hostnames
  • create a 1st AuthPolicy attached to one of the HTTPRoutes
  • create a 2nd AuthPolicy attached to the other HTTPRoute
  • this 2nd AuthPolicy should end up with "AuthScheme is not ready yet" error
  • delete the 1st AuthPolicy
  • observe that 2nd AuthPolicy never gets onto Enforced=True state
  • change the 2nd AuthPolicy (add some authorization rule, or response success header etc)
  • once saved the 2nd AuthPolicy is immediately successfully enforced

Example how to change the AuthPolicy CR:

spec:
  rules:
    response:
      success:
        headers:
          dummy:
            metrics: false
            plain: {}
            priority: 0
@guicassolato
Copy link
Contributor

@trepel I think we can close this one. WDYT?

@trepel
Copy link
Contributor Author

trepel commented Nov 14, 2024

@guicassolato I couldn't reproduce the issue using the verification steps anymore. The 2nd AuthPolicy was fully enforced and applied - I configured it to deny everything and I got 403 Forbidden indeed. Thanks for pointing this out.

Would not it be better to close this one only after that piece of documentation is updated? The "identical hostnames" limitation seems to be fixed (at least partially).

@guicassolato
Copy link
Contributor

Would not it be better to close this one only after that piece of documentation is updated?

Works for me.

The "identical hostnames" limitation seems to be fixed (at least partially).

It should have been fixed completely. What part of it stands?

@trepel
Copy link
Contributor Author

trepel commented Nov 14, 2024

It should have been fixed completely. What part of it stands?

I haven't checked everything so I can't tell. If you say that it has been fixed completely then I believe you. We will have to adjust our tests accordingly.

@KevFan
Copy link
Contributor

KevFan commented Nov 19, 2024

Would not it be better to close this one only after that piece of documentation is updated? The "identical hostnames" limitation seems to be fixed (at least partially).

Created #1032 PR to remove this limitation from the documentation

@KevFan KevFan moved this to In Progress in Kuadrant Nov 19, 2024
@KevFan KevFan self-assigned this Nov 19, 2024
@trepel
Copy link
Contributor Author

trepel commented Nov 20, 2024

Thanks @KevFan I think that this one can be closed then.

@github-project-automation github-project-automation bot moved this from Ready For Review to Done in Kuadrant Nov 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Something isn't working
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

4 participants