Authorino introduced (Kuadrant/authorino#273) a new listener for raw HTTP external authorization requests (alternatively to the gRPC protocol).

By default, the service will listen on port 5001 and use the same TLS certs defined for the gRPC server.

The default port number can be changed by setting the new env var EXT_AUTH_HTTP_PORT. The same env var can be used to disable the new listener in the Authorino instance – value equal to 0 (zero).

Neither of these is currently exposed in the Authorino CRD.

The port exposed for the controller metrics endpoint does not match the one listened by default (8080) by the Authorino instances whenever not specified otherwise via command-line arguments.

This seems to be a residual from kube-rbac-proxy originally deployed with Authorino to protected the metrics endpoint not being ported to the operator implementation (by design).

Add support for Authorino's tracing-service-endpoint and tracing-service-tag command-line args in the Authorino CRD.

Related to Kuadrant/authorino#380, Kuadrant/authorino#384.

Is there a particular version of controller-gen that is needed? When I try make install, I get the following error.

Error: unable to parse option "crd:trivialVersions=true,preserveUnknownFields=false": [unknown argument "preserveUnknownFields" extra arguments provided: "false"]

I was able to make more progress by removing preserveUnknownFields, but even after that, I get the following error

error: unable to recognize "/home/croberts/src/authorino-operator/config/install/manifests.yaml": no matches for kind "CustomResourceDefinition" in version "apiextensions.k8s.io/v1beta1"

In case it helps, I'm using the folliwng
go version go1.18.2 linux/amd64

OpenShift:
Client Version: 4.9.0-202111041612.p0.git.96e95ce.assembly.stream-96e95ce
Server Version: 4.10.12
Kubernetes Version: v1.23.5+70fb84c

Steps to reproduce

• Create Authorino CR with no log level spec
• Update CR adding spec.logLevel = 'debug'

Authorino is not rolled out with the new conf.

We're using distroless base images to build the project. This is good for optimization of the container images but won't work for security scans such as the ones run by Quay Security Scanner (based on Clair).

docker scan, which relies on Snyk, is a good alternative for local environment and CI. Nevertheless, we likely want something that is supported by Quay.io as well.

Currently, the operator which is deployed from the https://quay.io/repository/3scale/authorino-operator-catalog dies from OOM Killed when the first Authorino is created. Currently, the limits are requests: 20M and limit: 100M. However, the memory usage after the first Authorino and no AuthConfigs skyrocketed to 166M.

Configure Authorino using command-line flags, to keep up with the changes introduced in Kuadrant/authorino#366.

Ideally, the operator should be able to detect when to use command-line flags to the inject the configuration to the binary or the now deprecated environment variables equivalent. This is particularly useful when crossing newer versions of the operator with older versions of the operand in dev and test environments, where finer backward compatibility is often needed (e.g. deploying a git-ref a few commits behind latest or head of release).

Newer versions of the operand (post-#366) with older versions of the operator should not be an issue, due to the backward compatibility ensured by the operand. IOW, Authorino still processes the old env vars to set the defaults of the configuration options.

As part of adding Observability to Authorino, some metrics at the operator level need to be exposed to measure the states of the instances deployed via the operator.

The proposal is that initially the operator can expose two metrics

• authorino_instance_boostrap_time(instance_namespace="",instance_name="") - Measures the time an instance of Authorino takes to created
• authorino_instances_total(status="") - Counts the number of Authorino instances managed by the operator

Add unit testing for all the scenarios and cases handled by the authorino controller

Authorino Operator v0.4.1 had to drop RuntimeDefault seccomp profile in the security context for backward compatibility with older versions of OpenShift (#97).

Hopefully this can soon be added back,

1. because the minimum version of OpenShift supported for the Authorino Operator became 4.11+, or
2. because older versions of OpenShift based on compatible versions of Kubernetes for this feature (i.e. v1.22+) decided to address the issue and allow RuntimeDefault seccomp profile (see openshift/cluster-kube-apiserver-operator#1325).

I created this Authorino, and it failed with listener secret with tls cert not provided, which makes sense as I did not create one. However, from a usability standpoint, I think it would be better if it didn't allow me to create it at all. I would suggest removing the default value for that section and letting users specify it themselves.

apiVersion: operator.authorino.kuadrant.io/v1beta1
kind: Authorino
metadata:
  name: authorin-phala-kudrnt-te-q3yw
  namespace: authorino
spec:
  clusterWide: false
status:
  conditions:
    - lastTransitionTime: '2022-05-16T14:36:26Z'
      message: listener secret with tls cert not provided
      reason: TlsSecretNotProvided
      status: 'False'
      type: Ready

Authorino Operator's pod is named authorino-operator-controller-manager, as bootstrapped by default in projected created using the Operator SDK.

This is a long name that could be better simplified to just authorino-operator.

Authorino introduced (Kuadrant/authorino#273) a new env variable TIMEOUT to control the maximum duration (in milliseconds) of external authorization requests before context is cancelled by the service. This config works for both, gRPC server requests and requests to the new raw HTTP interface.

By default, the timeout is disabled (i.e. TIMEOUT=0), and left it to be controlled by the proxy. For other types of integration or to be able to protect the Authorino instance from long running workloads regardless of the proxy's settings, this timeout option needs to be exposed in the Authorino CRD.

Authorino recently introduced (Kuadrant/authorino#247) support for a new EVALUATOR_CACHE_SIZE environment variable that controls the size of each cache table associated with each evaluator where caching is enabled.

Currently it is not possible to set to this configuration via Authorino CR and attempts to set the environment variable directly in the Authorino Deployment will be reconciled back by the Operator.

Authorino has included support for different levels of logs, this can be defined via the LOG_LEVEL and LOG_MODE env vars. This issue is to enable the authorino operator to set these envs via the Authorino API in the spec block of the Authorino CR

apiVersion: operator.authorino.kuadrant.io/v1beta1
kind: Authorino
spec:
  logLevel: info
  logMode: production
  ...

https://github.com/Kuadrant/authorino/blob/main/main.go#L53-L54

At the moment, in the task creating the catalog, there's only a distinction when the build is for main or a release branch, tagging the catalog related images as latest and the specific vX.Y.Z release tag... but there's no condition for the SHA tagged build.

The current latest SHA build is rendered as:

bin/opm render quay.io/kuadrant/authorino-operator-catalog:30fb663ddc5b2978add48fd6ee9ff526317c05a5 --output=yaml


...

---
entries:
- name: authorino-operator.v0.0.0
name: alpha
package: authorino-operator
schema: olm.channel
---
image: quay.io/kuadrant/authorino-operator-bundle:latest # This should be quay.io/kuadrant/authorino-operator-bundle:30fb663ddc5b2978add48fd6ee9ff526317c05a5
name: authorino-operator.v0.0.0
package: authorino-operator
properties:
...

relatedImages:
- image: quay.io/kuadrant/authorino-operator:latest  #This should be quay.io/kuadrant/authorino-operator:30fb663ddc5b2978add48fd6ee9ff526317c05a5

...

Putting aside that this operator should build the catalog with the new file system instead of the current deprecated Sqlite-based one, the proposed change would be to include the SHA commit as a tag in the GH action that creates the catalog in .github/workflows/build-images.yaml and possibly make changes in the invoked target in the Makefile

Recommended upgrading sigs.k8s.io/controller-runtime to v0.11.2, to fix a transitive dependency vulnerability found in github.com/prometheus/client_golang/prometheus/promhttp.

Current version: 0.9.2
Latest version: 0.11.2

Implement a logic to update the Authorino CRs status block based on the conditions specification.

Migrate the logging package to use the same as the once used in authorino

See this PR for reference.

We want to improve automation in all repos for the Kuadrant components. We're aiming for:

1. good coverage of automation tasks related to code style, testing, CD/CD (image builds, releases), etc
2. consistency across components
3. automation as manageable code – i.e. less mouse clicks across scaterred UI "settings" pages and more Gitops, more YAMLs hosted as part of a code base.

As part of a preliminary investigation (Kuadrant/kuadrant-operator#21) of the current state of such automation, the following desired workflows and corresponding status for the Authorino Operator repo were identified. Please review the list below.

• A. Linters & Code style
  • A1. Built-in auto-format (go fmt, go vet, cargo fmt)
  • A2. 3rd-party linters (Reviewdog, golangci-lint, Clippy - Trailing whitespaces, EOF newline, Language-specific)
  • A3. Spelling (client9/misspell)
  • A4. Language (Woke)
• B. Tests
  • B1. Unit tests (go test, cargo test)
  • B2. End-to-end tests (build an image → deploy → run integration tests)
  • B3. Smoke tests (deploy image from quay.io/kuadrant → run integration tests)
  • B4. Performance & Benchmarks
• C. CI/CD
  • C1. Build and push image to quay.io/kuadrant
  • C2. Deploy (shared Kubernetes/OpenShift cluster in the cloud)
• D. Release
  • D1. Release (tag, version)
• E. Code scan (vulnerability, dependency updates)
  • E1. Dependabot alerts
  • E2. Dependabot version updates
  • E3. Dependabot security updates
  • E4. Code vulnerability scan (CodeQL, Red Hat Dependency Analytics)
  • E5. Static Code Analysis (SonarQube)
• F. Badges
  • F1. Test status & coverage
  • F2. Code analysis (dependencies, security)

Workflows do not have to be implemented exactly as in the list. The list is just a driver for the kind of tasks we want to cover. Each component should assess it as it makes sense considering the component's specificities. More details in the original epic: Kuadrant/kuadrant-operator#21.

You may also want to use this issue to reorganize how current workflows are implemented, thus helping us make the whole thing consistent across components.

For an example of how Authorino intends to organise this for a Golang code base, see Kuadrant/authorino#351.

• actions/checkout should be updated to v3
  • https://github.com/actions/checkout/releases/tag/v3.5.3
• actions/setup-go should be updated to v4
  • https://github.com/actions/setup-go#v4

Relevant to address:

• CVE-2023-44487
• CVE-2023-39325

Ideally, these Golang versions would become bases of ubi9/go-toolset, allowing minimal changes in the workflows, including downstream automated builds of Authorino by Red Hat. (RHSA-2023:5838.)

make operator-sdk fails when executed by the GitHub action Test Scripts for macos-latest platform.

E.g. https://github.com/Kuadrant/authorino-operator/actions/runs/6313837883/job/17142801232?pr=140

Authorino deployments created by the Operator comes with no container resource requests/limits configuration. One can set those by editing the Deployment manually, as such changes are not reconciled by the Operator. However, it would be nice to have the option to set those in the Authorino CR and thus avoid having to redeploy the pod.

https://app.codecov.io/gh/Kuadrant

• Ginkgo v1 is deprecated. We should migrate to use v2 instead
  • https://onsi.github.io/ginkgo/MIGRATING_TO_V2

Add a make command to the makefile for removing Authorino's CRDs, an example on how to remove the CRDs can be found here

Originally posted by @guicassolato in #1 (comment)

Authorino Operator panics when reconciling a CR such as the following, where TLS cert secrets are provided but without explicitly setting enabled: true:

apiVersion: operator.authorino.kuadrant.io/v1beta1
kind: Authorino
metadata:
  name: authorino
spec:
  image: quay.io/3scale/authorino:v0.5.0
  replicas: 1
  clusterWide: true
  listener:
    tls:
      certSecretRef:
        name: authorino-server-cert
  oidcServer:
    tls:
      certSecretRef:
        name: authorino-oidc-server-cert
EOF

Logs:

[bob@workstation example]$ k logs -f deployment/authorino-operator-controller-manager -c manager -n authorino-operator
2022-04-06T11:35:18.332Z        INFO    controller-runtime.metrics      metrics server is starting to listen    {"addr": "127.0.0.1:8080"}
2022-04-06T11:35:18.334Z        INFO    setup   starting manager
I0406 11:35:18.334570       1 leaderelection.go:243] attempting to acquire leader lease authorino-operator/aac3a15d.authorino.kuadrant.io...
2022-04-06T11:35:18.334Z        INFO    controller-runtime.manager      starting metrics server {"path": "/metrics"}
I0406 11:35:33.776897       1 leaderelection.go:253] successfully acquired lease authorino-operator/aac3a15d.authorino.kuadrant.io
2022-04-06T11:35:33.776Z        DEBUG   controller-runtime.manager.events       Normal  {"object": {"kind":"ConfigMap","namespace":"authorino-operator","name":"aac3a15d.authorino.kuadrant.io","uid":"8dafc1e5-b6da-4c4b-b7fc-35cfadda7d59","apiVersion":"v1","resourceVersion":"36445045"}, "reason": "LeaderElection", "message": "authorino-operator-controller-manager-d4ccf5478-zxmmw_41a63594-323f-477d-9e52-e6490c5f7611 became leader"}
2022-04-06T11:35:33.777Z        DEBUG   controller-runtime.manager.events       Normal  {"object": {"kind":"Lease","namespace":"authorino-operator","name":"aac3a15d.authorino.kuadrant.io","uid":"beecf777-33bc-4cf1-81e8-f44256d46893","apiVersion":"coordination.k8s.io/v1","resourceVersion":"36445046"}, "reason": "LeaderElection", "message": "authorino-operator-controller-manager-d4ccf5478-zxmmw_41a63594-323f-477d-9e52-e6490c5f7611 became leader"}
2022-04-06T11:35:33.777Z        INFO    controller-runtime.manager.controller.authorino Starting EventSource    {"reconciler group": "operator.authorino.kuadrant.io", "reconciler kind": "Authorino", "source": "kind source: /, Kind="}
2022-04-06T11:35:33.777Z        INFO    controller-runtime.manager.controller.authorino Starting Controller     {"reconciler group": "operator.authorino.kuadrant.io", "reconciler kind": "Authorino"}
2022-04-06T11:35:33.877Z        INFO    controller-runtime.manager.controller.authorino Starting workers        {"reconciler group": "operator.authorino.kuadrant.io", "reconciler kind": "Authorino", "worker count": 1}
2022-04-06T11:35:33.877Z        DEBUG   authorino-operator.controller.Authorino Found an instance of authorino  {"authorino": "hello-world/authorino", "authorinoInstanceName": "authorino"}
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x15040d9]

goroutine 257 [running]:
github.com/kuadrant/authorino-operator/controllers.(*AuthorinoReconciler).installationPreflightCheck(0xc0005808a0, 0xc0000ee000, 0x1e, 0xc000416a00)
        /workspace/controllers/authorino_controller.go:677 +0x239
github.com/kuadrant/authorino-operator/controllers.(*AuthorinoReconciler).Reconcile(0xc0005808a0, 0x1a05578, 0xc000514f30, 0xc000627b10, 0xb, 0xc000627af0, 0x9, 0xc000514f30, 0xc000030000, 0x16cd6c0, ...)
        /workspace/controllers/authorino_controller.go:100 +0x28b
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler(0xc000550b40, 0x1a054d0, 0xc0003dac00, 0x1693a20, 0xc000416980)
        /go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:298 +0x30d
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem(0xc000550b40, 0x1a054d0, 0xc0003dac00, 0xc0003c3700)
        /go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:253 +0x205
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2(0xc000626b50, 0xc000550b40, 0x1a054d0, 0xc0003dac00)
        /go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:214 +0x6b
created by sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2
        /go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:210 +0x425

Reported originally by @OperationalDev in Kuadrant/authorino#243

Dear Team,

Do we have a way to install Operator in disconnected kubernetes cluster ? Or maybe there is a helm-chart to install and configure it using ArgoCD. Please refer to the link or location where I can find the details about it

Release branches miss the replaces directive in the ClusterServiceVersion (CSV) manifest, set manually in the pull requests to the operator hubs, e.g.

• https://github.com/redhat-openshift-ecosystem/community-operators-prod/blob/19da6a06ab1db0351c0f354827915957830c59f4/operators/authorino-operator/0.7.0/manifests/authorino-operator.clusterserviceversion.yaml#L350
• https://github.com/k8s-operatorhub/community-operators/blob/9e7f3d392a50b17426a5c08ddb5b15f26dc2193b/operators/authorino-operator/0.7.0/manifests/authorino-operator.clusterserviceversion.yaml#L350

The directive should be filled whenever there's a new release of the operator.

When the OLM manifest bundle is generated, for some reason the AuthConfig v1beta2 entry in the CSV misses display name and description:

This is causing the operator to show up in the operator hub like this:

However, those values seem to be properly set in the source code (v1beta1, v1beta2) and generated CRD specs (v1beta1, v1beta2.) Therefore, it could be a problem of when generating the bundle only. TBC.

The kube-rbac-proxy needs to be added to the deployment of authorino in order to protect the /metrics endpoint

Originally posted by @guicassolato in #1 (comment)

It would be nice if there was a way to add labels to objects created by the operator when we create an authorino object.

This could be as simple as propagating the the labels on the authorino object to all of the objects created by the operator for this object.

Testing auto-adding issues to project - see Kuadrant/kuadrant-operator#222

To reproduce:

• Deploy Authorino CR

apiVersion: operator.authorino.kuadrant.io/v1beta1
kind: Authorino
metadata:
  name: authorino
  namespace: mysn
spec:
  clusterWide: true
  image: "authorino:wrong"
  listener:
    tls:
      enabled: false
  oidcServer:
    tls:
      enabled: false

The deployment cannot progress because the image does not exist:

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "1"
  creationTimestamp: "2022-05-23T16:05:45Z"
  generation: 1
  name: authorino
  namespace: eguzki
  ownerReferences:
    - apiVersion: operator.authorino.kuadrant.io/v1beta1
      blockOwnerDeletion: true
      controller: true
      kind: Authorino
      name: authorino
      uid: a48091aa-fda0-4c2a-97db-233fb5611611
  resourceVersion: "54595"
  uid: 8b7cef3f-26e8-49bd-8c64-5bb8ad9e0790
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      authorino-resource: authorino
      control-plane: controller-manager
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        authorino-resource: authorino
        control-plane: controller-manager
    spec:
      containers:
        - image: authorino:wrong
          imagePullPolicy: Always
          name: authorino
          resources: {}
          terminationMessagePath: /dev/termination-log
          terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      serviceAccount: authorino-authorino
      serviceAccountName: authorino-authorino
      terminationGracePeriodSeconds: 30
status:
  conditions:
    - lastTransitionTime: "2022-05-23T16:05:45Z"
      lastUpdateTime: "2022-05-23T16:05:45Z"
      message: Deployment does not have minimum availability.
      reason: MinimumReplicasUnavailable
      status: "False"
      type: Available
    - lastTransitionTime: "2022-05-23T16:05:45Z"
      lastUpdateTime: "2022-05-23T16:05:45Z"
      message: ReplicaSet "authorino-6cc855978f" is progressing.
      reason: ReplicaSetUpdated
      status: "True"
      type: Progressing
  observedGeneration: 1
  replicas: 1
  unavailableReplicas: 1
  updatedReplicas: 1

And yet the authorino CR says it is ready:

apiVersion: operator.authorino.kuadrant.io/v1beta1
kind: Authorino
metadata:
  creationTimestamp: "2022-05-23T16:05:44Z"
  generation: 1
  name: authorino
  namespace: eguzki
  ownerReferences:
    - apiVersion: kuadrant.kuadrant.io/v1beta1
      blockOwnerDeletion: true
      controller: true
      kind: Kuadrant
      name: kuadrant-sample
      uid: 4d955244-bee7-4a11-b4df-90727db2934e
  resourceVersion: "54594"
  uid: a48091aa-fda0-4c2a-97db-233fb5611611
spec:
  clusterWide: true
  image: authorino:wrong
  listener:
    tls:
      enabled: false
  oidcServer:
    tls:
      enabled: false
  volumes: {}
status:
  conditions:
    - lastTransitionTime: "2022-05-23T16:05:45Z"
      reason: Provisioned
      status: "True"
      type: Ready

It is expected that authorino CR status conditions reflect that authorino is not deployed

Authorino instances can either watch AuthConfigs in the same namespace where the instance is running (namespaced deployment mode) or in all namespaces (cluster-wide deployment mode).

Currently it is not possible to deploy an instance of Authorino in namespace X and make it watch for AuthConfigs defined in namespace Y (and no other namespace).

This is because, when the instance is not cluster-wide:

1. the value of the WATCH_NAMESPACE environment variable injected is set from the namespace of the Authorino CR

   authorino-operator/controllers/authorino_controller.go

   Line 284 in 5ada185

   Name: api.WatchNamespace,

2. the RBAC created (RoleBinding) gives permission for the instance only in the namespace where it is running and no other

   authorino-operator/controllers/authorino_controller.go

   Line 542 in 5ada185

   roleBinding = authorinoResources.GetAuthorinoRoleBinding(authorino.Namespace, authorino.Name, roleBindingName, "ClusterRole", clusterRoleName, serviceAccount)

This makes cluster-wide deployment mode the only option for topologies where the Authorino instance is in one namespace and the AuthConfigs of interest in another. Label selectors might be needed to prevent the cluster-wide instance from caching AuthConfigs from other namespaces.

A few latest changes in the Authorino CR have not been reflected in the README. This is the case of the new fields such as spec.metrics, spec.listener.ports and spec.listener.timeout.

Authorino Operator's deployment manifests, generated using this make target, currently enforce authorino-operator as the Kubernetes namespace to run the operator workload.

While on one hand that single-file manifest is very useful to install and deploy the Operator and the CRDs, changing the operator namespace, on the other hand, is not straightforward, requiring all occurrences of namespace: authorino-operator in the file, as well as the name of Namespace resource itself, to be properly replaced.

Except in the RoleBinding and ClusterRoleBinding resources, mentioning the Kubernetes namespace could be avoided, but in general, perhaps using a placeholder to ensure assertive replacement (e.g. making possible to rely on envsubst)? Another option would be relying more on Operator Lifecyle Manager to install the operator? Although it's not available by default in Kubernetes, but only in OpenShift.