-
Notifications
You must be signed in to change notification settings - Fork 107
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
fix(authz): Fix broken external auth configuration #892
Conversation
There are two misconfigurations being fixed: * In the SMCP, the service hostname of Authorino was coded with `-authorization` suffix, but the right suffix is `-authorino-authorization`. * In the `kserve-predictor` AuthorizationPolicy, the hardcoded `opendatahub-odh-auth-provider` provider name was used, but it should have been the template `{{ .AppNamespace }}-auth-provider`. In `pkg/feature/feature.go` the patch manifests (i.e. the ones containing `.patch` in the filename) are always applied. Thus, the first bullet is solved by fixing the patch file that adds the `extensionProvider` to the SMCP. For the second bullet, the faulty AuthorizationPolicy is created with a regular manifest template which is only applied if the resource does not exist. Thus, a patch manifest is added to properly fix the faulty policy (including operator upgrades). Signed-off-by: Edgar Hernández <23639005+israel-hdez@users.noreply.github.com>
@VaishnaviHire This would fix the broken installation that Eyal reported. |
@israel-hdez I think this is a good workaround for now, but there's a config map ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
I am wondering however if we have any automated test somewhere smoke testing this setup?
you want to keep file name "pkg/feature/templates/servicemesh/kserve/ |
Yes, manifests are applied in filename alphabetical order. So, I wanted to make sure the patch is applied at last. |
I guess E2E tests on KServe repo would have catched this, but they are not using the operator to setup the stack. So, I think in serving side we should improve our E2E setup to catch earlier this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: bartoszmajsak, VedantMahabaleshwarkar, zdtsw The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
i am confused again :D |
Yeah, we missed it :( @zdtsw go ahead and open PR with the fix. |
|
I added fix and ported missing tests in #905 |
Description
There are two misconfigurations being fixed:
-authorization
suffix, but the right suffix is-authorino-authorization
.kserve-predictor
AuthorizationPolicy, the hardcodedopendatahub-odh-auth-provider
provider name was used, but it should have been the template{{ .AppNamespace }}-auth-provider
.In
pkg/feature/feature.go
the patch manifests (i.e. the ones containing.patch
in the filename) are always applied. Thus, the first bullet is solved by fixing the patch file that adds theextensionProvider
to the SMCP.For the second bullet, the faulty AuthorizationPolicy is created with a regular manifest template which is only applied if the resource does not exist. Thus, a patch manifest is added to properly fix the faulty policy (including operator upgrades).
Fixes https://issues.redhat.com/browse/RHOAIENG-4192
How Has This Been Tested?
Both doing a clean install, and simulating an upgrade.
Merge criteria: