v0.10.0

New features and Enhancements

• All valid hosts added to cache (#324)
  • Instead of aborting at the first host in the list of hosts in an AuthConfig (spec.hosts) that cannot be added to the index of AuthConfigs due to being already taken, Authorino now ensures all valid hosts in the list are added, despite presence of invalid (taken) ones among them. Only the invalid ones will be rejected.
• Improved AuthConfig status – This is a big one!
  • Now the AuthConfig Status sub-resource is divided in summary and conditions (#318). The former summarizes info about the status of the resource, including readiness state, hosts accepted, evaluator counters, etc. The latter provides fine-grained info in the form of "conditions", to infer availability and full-readiness of the resource, described in the table below:

    Type	Status	Reason	Message	Meaning
    Available	True	HostsLinked	N/A	At least one host from spec.hosts was linked to the AuthConfig in the index. Requests sent to the linked host can be expected to be protected by this AuthConfig. User can check status.summary.hostsReady for the list of host names that did succeed being linked to the AuthConfig in the index.
    Available	False	HostsNotLinked	No hosts linked to the resource.	No host from spec.hosts was linked to the AuthConfig in the index. No request will cause this AuthConfig to be evaluated by Authorino. Only possible status for Ready is False in this case.
    Ready	True	Reconciled	N/A	The AuthConfig is indexed for all host names listed in spec.hosts.
    Ready	False	HostsNotLinked	One or more hosts not linked to the resource	Failed to index the AuthConfig for one or more host names in spec.hosts. User should check status.summary.hostsReady for the list of host names that did succeed being linked to the AuthConfig in the index; occasionally none.

  • Reconciliation errors and proper reason to failing reconciling an AuthConfig reflected in the status. The table below summarizes all the reasons for an AuthConfig to be cnsidered "ready" or "not ready".

    Reason	Description	Ready?
    Reconciling	Transient state between reconciliation started and finished (due to success or terminal failure)	N
    Invalid	Invalid resource. AuthConfig cannot be added to cache for any of the hosts listed. Message will reflect the exact error (e.g. broken ref).	N
    HostsNotLinked	One or more hosts not linked to the resource	N
    CachingError	Failed to add the AuthConfig to the index	N
    Reconciled	Resource reconciled	Y
    Unknown	Should never happen 🙂	N

• Support for host names with wildcards (#312) - Another big one!
  • Now you can use wildcards in the host names you add to spec.hosts. E.g. *.pets.com, which matches authorization requests for dogs.pets.com, cats.pets.com and even snakes.pets.com (if you are that kind of person).
  • More specific host names take precedence. E.g. when evaluating for a request that is sent for dogs.pets.com, an AuthConfig A that links dogs.pets.com will be favored before an AuthConfig B that links the more generic host with wildcard *.pets.com; in case of an authorization request sent for cats.pets.com, Authorino would fall back to AuthConfig B (wildcard).
  • You can have as many levels as you want between more specific to more generic host names with wildcards. E.g. api.pets.com → *.pets.com → *.com → *.
  • Important! Keep in mind that due to the mechanism that prevents inattentive/malicious users from fully (or now also partially) taking control over someone else's auth scheme, by applying another AuthConfig that links identical (or now also more specific) host names previously accepted for another resource, and where both AuthConfigs are in the scope of the same Authorino instance, the support for host names with wildcards redefines the concept of host collision, from a relation of equality (host1 == host2) to a relation of sets and subsets (host1 ⊆ host2). This imposes a constraint regarding the order that legit AuthConfigs have to be applied to the cluster – always starting with the ones for more specific host names first, to the more generic ones (with wildcards) second.
• Prevention of host name collisions in all cases (#343)
  • Authorino now rejects linking AuthConfigs to hosts already taken regardless of namespace. This is a policy we used to enforce in the past only across different namespaces (with Authorino deployed in cluster-wide reconciliation mode only). It is now enforced in all cases, including with Authorino in namespaced mode, for AuthConfigs in the same Kubernetes namespace. This implies that users who get hosts in their AuthConfigs rejected to be linked will have to coordinate who actually owns the auth scheme for that host and, if necessary, remove it from an AuthConfig where the host was previously taken and/or reapplying the sequence of AuthConfigs in an acceptable order.
• [Breaking change] Kube notation for API key and MTLS Secret label selectors (#341, #344)
  • Authorino now complies with the new Kubernetes syntax to express the label selectors used for API key and MTLS Kubernetes secrets scoped with an AuthConfig. The API changed as follows:
    
    Before:

    spec:
      identity:
      - name: friends
        apiKey:
          labelSelectors:
            group: friends

    Now:

    spec:
      identity:
      - name: friends
        apiKey:
          selector:
            matchLabels:
              group: friends

  • Apart from making the AuthConfig more seamless to use by users familiar with this API of Kubernetes, we all also get as bonus support for label expressions. E.g.:

    spec:
      identity:
      - name: friends
        apiKey:
          selector:
            matchExpressions:
              key: group
              operator: NotIn
              values:
              - enemies

• Improvements to the raw HTTP external authorization interface
  • Protection against large body content (#313)
    • Set to a maximum of 8192 (8KB) by default
    • Returns an HTTP status 413 Request Entity Too Large when exceeded
    • Can be configured by setting the MAX_REQUEST_BYTES environment variable in the Authorino pod - support by the Operator via spec.maxHttpRequestBodySize field of the Authorino CR
  • Improvements in the log messages (debug level) (#325)
• Authorino version info embedded into the binary (#345)
  • You no longer need to trust only on the tag of the container image to check the exact version of the Authorino binary you are running. You can now find it right in the very second message in the logs:

    {"level":"info","ts":1634674939.7563884,"logger":"authorino","msg":"setting instance base logger","min level":"debug","mode":"production"}
    {"level":"info","ts":1634674939.7567484,"logger":"authorino","msg":"booting up authorino","version":"v0.10.0"}
    

• Red Hat Universal Base Image (UBI) 8 (#332)
  • Container images are now based on Red Hat Universal Base Image (UBI) 8 instead of Google's distroless images. This enables better security scans and support on community images released in the upstream.

Bug fixes

• No more phantom host associations (#327)
  • Oops. This is awkward. We discovered that host names removed from an AuthConfig were refusing to leave the index. It looks like they loved Authorino so much that they wanted to continue to be linked to the AuthConfig that once brought them to the party. But not anymore! Now we ensure deleted hosts vanish from the index for good.
  • This didn't affect the deletion of AuthConfigs as a whole, but only when editing existing ones. Either way, it's now fixed.
• Respect the creation order of the resources when bootstrapping the index of AuthConfigs (#330, #338, #349)
  • When a new Authorino pod started, it bootstraped the index of AuthConfigs by reconciling again all pre-existing resources marked as available in whatever order the reconciliation events were picked by the runtime controller. Since the ordering of the events cannot be guaranteed, this behavior led to a probabilistic situation of error where multiple pods (multiple generations of a pod) could exist with different states between them regarding which AuthConfigs and corresponding hosts were accepted in the index. This is now fixed and Authorino will always respect the order of the resources based on creationTimestamp whenever bootstrapping the index for the first time. This should be enough to prevent inconsistent states, ensuring the same sequence of decisions of the past.
  • While bootstrapping the index for the first time, AuthConfigs in the process of being reconciled might momentarily return a 503 Busy status code when requested, until they are fully operable. We put our best efforts to make this step as efficient and quick as possible, so it's almost never perceived by the user.
• Avoid panicking when external OPA response misses the Content-Type header (#347)
• Use RWMutex for all the cases where multiple concurrent reads and writes are expected (status updater, API key and MTLS loading and access) (#348)

Dependencies and Tooling

• A couple of improvements to the Developer's Makefile
  • Check if GNU sed is installed (#319)
  • Set vi as default editor for make deploy (#321)
  • Improved template of the sample Authorino CR for local deployments (#322)
    • Now also teaching more about supported fields, based on the latest version of the Authorino Operator
• github.com/open-policy-agent/opa bumped to v0.42.0 (#331)

Testing

• New test benchmarks (#334, #336)
  • Performance (time, memory consumption and allocation requests) of steps of the workflow and comparable evaluators, including:
    • adding an AuthConfig to the index (ReconcileAuthConfig),
    • execution of the Auth Pipeline for an authorization request (AuthPipeline),
    • authentication based on API keys (APIKeyAuthn), and
    • simple JSON pattern-matching (JSONPatternMatchingAuthz) vs. OPA (OPAAuthz) for authorization.
  • Tests run automatically on every PR together with the unit tests; for setups of 1, 4 and 10 CPUs
  • Results periodically updated and published to the README
• Ensure tests run locally for the target OS even for contributors working on other operating systems (#333)
• Badges for the automated tests right in the README (#337)
  

Documentation

• Deep metrics added to the feature description page (#335)
• Rename the 'cache' of AuthConfigs as 'index' (#339)
  • You might have noticed from this release notes that we've now been calling the cache of AuthConfigs the index of AuthConfigs. We hope we didn't miss any reference in the docs; otherwise it might be a good opportunity for you to help us and send your first pull request 🙂.