AuthConfig v1beta2

[guicassolato]

Introduces a new version of the AuthConfig API (v1beta2), implementing roughly the following bullet points of #400:

1. From lists (arrays) of named definitions to maps (objects)
2. Dynamic values, interpolation, selector expansion, and comparison values
   2.1. Dynamic values (or values fetched from the Authorization JSON with valueFrom.authJSON)
3. Renaming of phases of the Auth Pipeline
   3.1. identity → authentication
4. Renaming of auth methods
   4.1. identity.oidc → .jwt
   4.2. identity.oauth2 → .oauth2Introspection
   4.3. identity.mtls → .x509
   4.4. identity.kubernetes → .kubernetesTokenReview
   4.5. identity.credentials
   4.6. identity.extendedProperties → .override and .default
   4.7. authorization.json → .rules .patternMatching
   4.8. authorization.kubernetes → .kubernetesSubjectAccessReview
   4.9. authorization.authzed → .spicedb
5. Restructuring of response
   5.1. wrappers as structured property
   5.2. denyWith merged into response

Plus a few other minor enhancements preparing for the future, such as:

• Unifying configs to build HTTP clients and send HTTP requests to external services
• Full YAML/JSON data type compatibility for setting static values (so it behaves in the same way as when selecting a dynamic value from the Authorization JSON)

Because this introduces a second version of the CRD without removing the existing one, this PR also prepares Authorino for the deployment of a conversion webhook. Authorino itself can double as either the data plane external authorization server (by running it, as usual, with authorino server) or as a control plane-level webhook service.

The tooling for running Authorino locally (developer workflow) will take care of deploying an instance of the webhook service and configuring the Kubernetes API server to use by injecting the service refs in the CRD at runtime. I imagine soon this will be handled by the Authorino Operator as well.

No changes regarding the reconciliation of the AuthConfig CRs were made at this point. The reconciler will continue to request CRs based on v1beta1 which are fully compatible with what's exposed by v1beta2. Some new features of v1beta2 might not yet be available, until the reconciler is updated to request CRs on v1beta2.

Verification steps

① Setup

make local-setup OPERATOR_BRANCH=conversion-webhook FF=1

Note: A default conversion webhook service will be deployed and managed by the Authorino Operator. The Authorino local-setup workflow substitutes the image of the webhook deployment with the one built locally, so the webhook runs based on the same code as the deployed Authorino instances will default to. The local-setup workflow also ensures that patches to the AuthConfig CRD performed by the Operator to activate the webhook are kept when re-applying the CRD with local changes.

② Verify that the new version of API has been installed

kubectl api-resources -o wide | grep authconfigs
# authconfigs                                    authorino.kuadrant.io/v1beta2            true         AuthConfig                       delete,deletecollection,get,list,patch,create,update,watch

③ Create a trivial AuthConfig based on v1beta2

Create the AuthConfig:

kubectl apply -f - <<EOF
apiVersion: authorino.kuadrant.io/v1beta2
kind: AuthConfig
metadata:
  name: talker-api-protection
spec:
  hosts:
  - talker-api-authorino.127.0.0.1.nip.io
EOF

Request the AuthConfig in its default served version (v1beta2):

kubectl get authconfigs/talker-api-protection -o yaml

Request the AuthConfig in both versions:

kubectl get authconfigs.v1beta1.authorino.kuadrant.io/talker-api-protection -o yaml

kubectl get authconfigs.v1beta2.authorino.kuadrant.io/talker-api-protection -o yaml

④ Create a slightly more complex AuthConfig based on v1beta2

Create the AuthConfig:

kubectl apply -f - <<EOF
apiVersion: authorino.kuadrant.io/v1beta2
kind: AuthConfig
metadata:
  name: talker-api-protection
spec:
  hosts:
  - talker-api-authorino.127.0.0.1.nip.io
  authentication:
    "friends":
      apiKey:
        selector:
          matchLabels:
            "app": "talker-api"
            "group": "friends"
        allNamespaces: false
      credentials:
        authorizationHeader:
          prefix: API-KEY
EOF

Request the CR in both versions and compare.

⑤ Create a all-in-one AuthConfig based on v1beta2

kubectl apply -f - <<EOF
apiVersion: authorino.kuadrant.io/v1beta2
kind: AuthConfig
metadata:
  name: talker-api-protection
spec:
  hosts:
  - talker-api.127.0.0.1.nip.io
  - talker-api.default.svc.cluster.local
  patterns:
    "adminPath":
    - selector: context.request.http.path
      operator: matches
      value: ^/admin(/.*)?$
    "resourcePath":
    - selector: context.request.http.path
      operator: matches
      value: ^/greetings/\d+$
  when:
  - selector: context.metadata_context.filter_metadata.envoy\.filters\.http\.skipper_lua_filter|skip
    operator: neq
    value: "true"
  authentication:
    "apiKeyUsers":
      apiKey:
        selector:
          matchLabels:
            "app": "talker-api"
            "talker-api/credential-kind": "api-key"
        allNamespaces: false
      credentials:
        authorizationHeader:
          prefix: API-KEY
      overrides:
        "groups":
          value: ["admin"]
    "mtlsUsers":
      x509:
        selector:
          matchLabels:
            "app": "talker-api"
            "talker-api/credential-kind": "ca-cert"
        allNamespaces: false
    "k8sServiceAccountTokens":
      kubernetesTokenReview:
        audiences:
        - talker-api.default.svc.cluster.local
    "oidcServerUsers":
      jwt:
        issuerUrl: https://accounts.company.com
        ttl: 3600
      defaults:
        "username":
          selector: auth.identity.preferred_username
      overrides:
        "jwtRBAC":
          value: true
    "oauth2OpaqueTokens":
      oauth2Introspection:
        endpoint: https://accounts.company.com/oauth2/v1/introspect
        credentialsRef:
          name: oauth2-introspection-credentials
      overrides:
        "jwtRBAC":
          value: true
    "fromEnvoy":
      plain:
        selector: context.metadata_context.filter_metadata.envoy\.filters\.http\.jwt_authn|verified_jwt
      when:
      - selector: context.metadata_context.filter_metadata.envoy\.filters\.http\.jwt_authn
        operator: neq
        value: ""
    "anonymousAccess":
      anonymous: {}
      priority: 1
  metadata:
    "geoInfo":
      http:
        url: http://ip-location.authorino.svc.cluster.local:3000/{context.request.http.headers.x-forwarded-for.@extract:{"sep":","}}
        method: GET
        headers:
          "Accept":
            value: application/json
        sharedSecretRef:
          name: ip-location
          key: shared-secret
      cache:
        key:
          selector: "context.request.http.headers.x-forwarded-for.@extract:{\"sep\":\",\"}"
        ttl: 3600
      metrics: true
    "oidcUserInfo":
      userInfo:
        identitySource: oidcServerUsers
    "umaResourceInfo":
      when:
      - patternRef: resourcePath
      uma:
        endpoint: http://keycloak.authorino.svc.cluster.local:8080/auth/realms/kuadrant
        credentialsRef:
          name: talker-api-uma-credentials
      cache:
        key:
          selector: context.request.http.path
  authorization:
    "externalOpaPolicy":
      opa:
        externalPolicy:
          url: https://raw.githubusercontent.com/guicassolato/authorino-opa/main/allowed-methods.rego
          ttl: 3600
    "inlineRego":
      opa:
        rego: |
          country = object.get(object.get(input.auth.metadata, "geo-info", {}), "country_iso_code", null)
          allow {
            allowed_countries := ["ES", "FR", "IT"]
            allowed_countries[_] == country
          }
        allValues: true
    "kubernetesRBAC":
      when:
      - patternRef: admin-path
      - selector: auth.identity.kubernetes-rbac
        operator: eq
        value: "true"
      kubernetesSubjectAccessReview:
        user:
          selector: auth.identity.username
    "simplePatternMatching":
      when:
      - patternRef: admin-path
      - selector: auth.identity.jwtRBAC
        operator: eq
        value: "true"
      patternMatching:
        patterns:
        - selector: auth.identity.roles
          operator: incl
          value: admin
    "externalSpicedbPolicy":
      spicedb:
        endpoint: spicedb.spicedb.svc.cluster.local:50051
        insecure: true
        sharedSecretRef:
          name: spicedb
          key: grpc-preshared-key
        subject:
          kind:
            value: blog/user
          name:
            selector: auth.identity.metadata.annotations.username
        resource:
          kind:
            value: blog/post
          name:
            selector: context.request.http.path.@extract:{"sep":"/","pos":2}
        permission:
          selector: context.request.http.method.@replace:{"old":"GET","new":"read"}.@replace:{"old":"POST","new":"write"}
    "deny20percent":
      opa:
        rego: allow { rand.intn("foo", 100) < 80 }
      priority: 1
    "timestamp":
      opa:
        rego: |
          now = time.now_ns() / 1000000000
          allow = true
        allValues: true
      priority: 20
  response:
    unauthenticated:
      message:
        value: Authentication failed
    unauthorized:
      message:
        value: Access denied
      headers:
        "random":
          selector: auth.authorization.deny20percent
    success:
      headers:
        "x-auth-service":
          plain:
            value: Authorino
        "x-auth-data":
          json:
            properties:
              "username":
                selector: auth.identity.username
              "geo":
                selector: auth.metadata.geoInfo
              "timestamp":
                selector: auth.authorization.timestamp
        "festival-wristband":
          wristband:
            issuer: https://authorino-authorino-oidc.authorino.svc.cluster.local:8083/authorino/e2e-test/festival-wristband
            tokenDuration: 300
            customClaims:
              "username":
                selector: auth.identity.username
              "uri":
                selector: context.request.http.path
              "scope":
                selector: context.request.http.method.@case:lower
            signingKeyRefs:
            - name: wristband-signing-key
              algorithm: ES256
          key: x-wristband-token
      dynamicMetadata:
        "username":
          plain:
            selector: auth.identity.username
  callbacks:
    "telemetry":
      http:
        url: http://telemetry.server
        method: POST
        body:
          selector: |
            \{"requestId":context.request.http.id,"username":"{auth.identity.username}","authorizationResult":{auth.authorization}\}
        oauth2:
          tokenUrl: https://accounts.company.com/oauth2/v1/token
          clientId: talker-api
          clientSecretRef:
            name: talker-api-telemetry-credentials
            key: client-secret
EOF

Request the CR in both versions and compare.

TODOs

• Let the Operator manage the deployment of the conversion webhook
• Tests for v1beta2.AuthConfig.ConvertTo and v1beta2.AuthConfig.ConvertFrom
• One-of constraints for v1beta2

This PR should be merged together with Kuadrant/authorino-operator#137.

[KevFan]

Ran through the verification steps and all working as expected 👍

[KevFan]

Changes looks good to me 👍

Ran throught the verification steps and all working as expected 🥇

[Boomatang]

I have read the changes. Nothing is standing out to me in the change as a problem. With the size the PR and my lack of experiences with authorino in general I can't confidently say these changes are correct.

[KevFan]

Changes looks good to me anyhow

[adam-cattermole]

I went through all the user-guides as a second pair of eyes and found some very minor suggestions (unrelated to this PR) all fixed in latest commits - thanks @guicassolato - the changes look good to me

[didierofrivia]

I've reviewed the changes, with attention to the new architecture of the main.go spawning the services (auth, webhook) with cobra cmds coming from the Deployment object and the conversions of the designated hub v1beta1... Haven't had time to go through the guides, but I've seen in the comments that they work as expected, will try to do some of the more complex ones in the near future. Great work! 🥇

[eguzki]

I am surely missing something. The expected is that the new version of the CRD is the stored one so eventually the older one can be dropped

[eguzki]

For the future, for this kind of tasks, I would use kustomize

[guicassolato]

Following the same pattern adopted by https://docs.kuadrant.io/getting-started/#set-up-clusters-and-multicluster-gateway-controller.

kustomize is also bit more cumbersome when you need to support many options (even with overlays). Besides, it isn't much helpful for things like sequencing commands, e.g. https://github.com/Kuadrant/authorino-operator/blob/152a1627a0b2f5d36c3983192644ec8c5d625bad/utils/install.sh#L140

[eguzki]

shouldn't be v1beta2 the one to be stored?

[guicassolato]

Not necessarily. Usually, first you introduce a new version of the API and allow time for users to adapt; then the newer version becomes the stored one in a subsequent rolling update. This way, when they install the new version of the CRD, previously existing CRs based on the old version won't be a blocker.

For ref: https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/#version-removal

[eguzki]

I am missing something. If the stored version is the old one, even the clients of the new version will store CR with the old version. then the newer version becomes the stored one in a subsequent rolling update. Then, there will be the same situation, all the CR stored versions would be the old one and the CRD's stored one will be the new one. I do not see any advantage of postponing the stored version.

What I was assuming, and correct me if I am wrong, whenever a client updates / creates an object, if the object's version is not the stored one, the webhook conversion API will be called and the object converted.

[eguzki]

Looking at the Versions in CustomResourceDefinitions, the workflow for upgrading CRD version would be (high level):

• Release 1: Add a new version to the version list. The old version is the stored one. Both versions will be served. No deprecation flag.
• Release 2 (or later): Old version deprecation. The old version is served, but not stored and added deprecation warning. The new version is the stored (and served) one. Just after installing the new CRD with the changes, the stored (in old version) CR's need to be migrated. This is procedure needs to be run by some cluster admin.
• Release 3 (or later): Version removal. When all the clients have migrated to the new version (one option is checking kube-apiserver logs), the old version can either be disabled for serving (served: false) or just removed from the CRD spec.versions list.

[guicassolato]

Excellent summary, @eguzki. Thank you for this!

[eguzki]

considered adding kubebuilder:deprecatedversion ??

[eguzki]

Should not be done in this step. check my comment above.

[eguzki]

I could not review all changes deeply, but I think is good enough for going forward. Fixes can be done later.

Awesome work 🎖️