Skip to content

v0.6.0

Pre-release
Pre-release
Compare
Choose a tag to compare
@guicassolato guicassolato released this 13 Dec 17:46
· 645 commits to main since this release
v0.6.0
dc811c4
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.

New features and Enhancements

  • Label selectors for the AuthConfig (#179)
    • It is now possible to configure an instance of Authorino to watch only a subset of the AuthConfigs in the watching space (Kubernetes namespace or Kubernetes cluster)
    • The new selector is configurable for an instance of Authorino via AUTH_CONFIG_LABEL_SELECTOR environment variable (spec.authConfigLabelSelectors field of the Authorino CR)
    • For consistency, the environment variable to configure label selector for API key secrets to be watched by the Auhtorino instance was also renamed to SECRET_LABEL_SELECTOR (spec.secretLabelSelectors field of the Authorino CR)
    • Label selectors for both AuthConfigs and API key Secrets are now fully compatible with Kubernetes label selector syntax, accepting values such as: 
      authorino.kuadrant.io/managed-by=authorino
authorino.kuadrant.io/managed-by=authorino,other-label=other-value
authorino.kuadrant.io/managed-by in (authorino,kuadrant)
authorino.kuadrant.io/managed-by!=authorino-v0.4
!disabled
    • [Breaking change] The semantics of label selectors for API key secrets also changed together with the new syntax, now working as one would expect from any Kubernetes label selector, effectively causing:
      i. AuthConfigs no longer required to declare all labels of the API key secrets it accepts to authenticate for the protected hosts;
      ii. API key secrets can be labeled in sets and subsets in the AuthConfigs
  • Custom headers option for HTTP external metadata requests (#186)
    • The AuthConfig API was extended with an option spec.metadata.http.headers to customize the headers of the HTTP request to external sources of metadata (Generic HTTP external metadata feature). Values can be static values or dynamically fetched from the Authorization JSON.
  • Priorities for the evaluator configs (#188)
    • The AuthConfig API was extended with an option priority that can be defined in any evaluator of all phases.
    • Evaluators of same priority execute concurrently to each other "in a block”; after syncing that block (i.e. after all evaluators of the block have returned), the next block of evaluator configs of consecutive priority (immediately higher numbered) is triggered.
    • The default priority of an evaluator, when omitted is 0, meaning the highest priority block, i.e. the one the evaluates first.
    • Typical use cases for for priorities are:
      i. Saving expensive tasks to be triggered when there's a high chance of returning immediately after finishing executing a less expensive one – e.g.
      - an identity config that calls an external IdP to verify a token that is rarely used, compared to verifying JWTs preferred by most users of the service;
      - an authorization policy that performs some quick checks first, such as verifying allowed paths, and only if it passes, moves to the evaluation of a more expensive policy.
      ii. Establishing dependencies between evaluators - e.g.
      - an external metadata request that needs to wait until a previous metadata responds first (in order to use data from the response)
  • [Breaking change] OAuth2 token introspection authentication method now rejects access tokens that are inactive right in the identity verification phase (#194)
    • Before, inactive tokens had to be rejected via authorization policy added to the AuthConfig.
    • With the change, OAuth2 token introspection in Authorino is now fully compliant with RFC 7662.
  • OpenID Connect discovery auto-refresh (#197)
    • The AuthConfig API was extended with a new option spec.identity.oidc.ttl: <time to refresh in seconds> the sets the frequency for OpenID Connect configurations to be auto-refreshed from the OIDC provider.
    • Default value of the property is 0, meaning the auto refreshed of the OIDC config is disable
  • [Breaking change] The API group of the AuthConfigs is now authorino.kuadrant.io (replacing the old authorino.3scale.net) (#203)
    • This can cause existing AuthConfigs to stop being reconciled by Authorino instances until the apiVersion field of the resource is updated to authorino.kuadrant.io
    • All RBAC roles associated with the Authorino service will also be redefined in the cluster, possibly causing previous bindings to have to be recreated

Dependencies and Tooling

  • Local setup now relies on the Authorino Operator to deploy (#180)
    • With the release of the Authorino Operator, this is now the default way to install and deploy Authorino, including for the devs workflow when trying a local branch of Authorino
  • Manifest bundles
    • Authorino can now be installed from one single manifest file (#191, #193) – used by the Authorino Operator
    • Install Authorino Operator and cert-manager from manifests (#201) – devs workflow

Bug fixes

  • Removed required labels from existing API key secrets now properly trigger the reconciliation of the resource and related AuthConfig (#179)
  • Fix Kubernetes auth permissions for the manager-role (#187)
  • Rename authorino-(editor|viewer)-role => authorino-authconfig-(editor|viewer)-role, so they won't collide with operator's homonimous roles associated to the Authorino crd (#192)
  • Fix DNS names of the cert-manager certificates (#198)
  • Auth credentials passed in cookies can now contain the equal sign ('=') in the value (#196)
  • Avoid OIDC verify token to crash when missing the provider config (#199)

Documentation

Authorino documentation was completely restructured (#180, #200, #202), with

  • Better and more straightforward README file, including all you expect to know about Authorino in one short page (first steps, how it works, FAQs, list of features, etc).
  • A new Getting started page, with requirements, installation instructions and first steps.
  • 21 new User guides, from a Hello World to implementing Edge Authentication Architecture (EAA) using Authorino.
  • The Architecture page now includes better diagrams and descriptions that will help you understand how Authorino works under the hood and to better leverage it for your specific needs, including details about possible topologies, deployment modes, RBAC, caching options for sharding and gains of performance, etc.
  • A new Features page completely extracted from the description of the architecture and now including more details and links to corresponding API types.
Assets 2
Loading