diff --git a/docs/user-guides/README.md b/docs/user-guides/README.md new file mode 100644 index 00000000..c59d7fff --- /dev/null +++ b/docs/user-guides/README.md @@ -0,0 +1,33 @@ +# AuthConfig Consumers +Authorino's `AuthConfig` is a custom resource that defines authentication and authorization policies. Many tools and frameworks act +as consumers of `AuthConfig` by automatically generating and managing these resources on behalf of users. Since these consumers +follow the same specification, the general concepts and steps outlined in the user guides are applicable. +However, some details—such as resource names and specific API fields—may differ based on the consuming framework. + +This section provides guidance for users working with tools that act as consumers of `AuthConfig`, allowing them to leverage the +same principles outlined in the user guides, regardless of the framework they are using. + +## Kuadrant +[Kuadrant](https://kuadrant.io/) provides API security and access control capabilities through its own custom resource: `AuthPolicy`. +`AuthPolicy` is designed specifically for use with the Kubernetes [Gateway API](https://gateway-api.sigs.k8s.io/), allowing users +to define authentication and authorization rules directly in their network policy configurations. + +Rather than defining `AuthConfig` resources directly, users can define an `AuthPolicy`, and Kuadrant will automatically +generate the corresponding `AuthConfig` for Authorino to consume. + +### Key Details About `AuthPolicy` as an `AuthConfig` Consumer + +- **Same Specification**: The spec schema of `AuthPolicy` is effectively the same as `AuthConfig`. +- **Automatic Hostname Handling**: Unlike `AuthConfig`, `AuthPolicy` does not explicitly define `spec.host`. Instead, hostnames are +inferred from the Kubernetes network object in `spec.targetRef` and the route selectors in the policy. +- **Authorino Integration**: Kuadrant translates `AuthPolicy` into an `AuthConfig`, which is then processed by Authorino to enforce +authentication and authorization. + +### Authorino Features Not Available via Kuadrant +Some Authorino-specific features may not be available when using Authorino through Kuadrant: + +- [Sharding](./sharding.md) +- [Host Override via Context Extension](./host-override.md) + +For more details on enforcing authentication and authorization with Kuadrant, see the +[Kuadrant Auth documentation](https://docs.kuadrant.io/latest/kuadrant-operator/doc/overviews/auth/). diff --git a/docs/user-guides/anonymous-access.md b/docs/user-guides/anonymous-access.md index a0667e6d..dae63e2a 100644 --- a/docs/user-guides/anonymous-access.md +++ b/docs/user-guides/anonymous-access.md @@ -29,23 +29,6 @@ kind create cluster --name authorino-tutorial The next steps walk you through installing Authorino, deploying and configuring a sample service called **Talker API** to be protected by the authorization service. -
| Using Kuadrant | -
|---|
|
- If you are a user of Kuadrant and already have your workload cluster configured and sample service application deployed, as well as your Gateway API network resources applied to route traffic to your service, skip straight to step ❺. -At step ❺, instead of creating an For more about using Kuadrant to enforce authorization, check out Kuadrant auth. - |
-
- Kuadrant users –
- Remember to create an AuthPolicy instead of an AuthConfig.
- For more, see Kuadrant auth.
- |
-
If you are a user of Kuadrant and already have your workload cluster configured and sample service application deployed, as well as your Gateway API network resources applied to route traffic to your service, skip straight to step ❺.
-At step ❺, instead of creating an AuthConfig custom resource, create a Kuadrant AuthPolicy one. The schema of the AuthConfig's spec matches the one of the AuthPolicy's, except spec.host, which is not available in the Kuadrant AuthPolicy. Host names in a Kuadrant AuthPolicy are inferred automatically from the Kubernetes network object referred in spec.targetRef and route selectors declared in the policy.
For more about using Kuadrant to enforce authorization, check out Kuadrant auth.
-
- Kuadrant users –
- Remember to create an AuthPolicy instead of an AuthConfig.
- For more, see Kuadrant auth.
- |
-
If you are a user of Kuadrant and already have your workload cluster configured and sample service application deployed, as well as your Gateway API network resources applied to route traffic to your service, skip straight to step ❻.
-At step ❻, instead of creating an AuthConfig custom resource, create a Kuadrant AuthPolicy one. The schema of the AuthConfig's spec matches the one of the AuthPolicy's, except spec.host, which is not available in the Kuadrant AuthPolicy. Host names in a Kuadrant AuthPolicy are inferred automatically from the Kubernetes network object referred in spec.targetRef and route selectors declared in the policy.
For more about using Kuadrant to enforce authorization, check out Kuadrant auth.
-
- Kuadrant users –
- Remember to create an AuthPolicy instead of an AuthConfig.
- For more, see Kuadrant auth.
- |
-
If you are a user of Kuadrant and already have your workload cluster configured and sample service application deployed, as well as your Gateway API network resources applied to route traffic to your service, skip straight to step ❻.
-At step ❻, instead of creating an AuthConfig custom resource, create a Kuadrant AuthPolicy one. The schema of the AuthConfig's spec matches the one of the AuthPolicy's, except spec.host, which is not available in the Kuadrant AuthPolicy. Host names in a Kuadrant AuthPolicy are inferred automatically from the Kubernetes network object referred in spec.targetRef and route selectors declared in the policy.
For more about using Kuadrant to enforce authorization, check out Kuadrant auth.
-
- Kuadrant users –
- Remember to create an AuthPolicy instead of an AuthConfig.
- For more, see Kuadrant auth.
- |
-
| Using Kuadrant | -
|---|
|
- If you are a user of Kuadrant and already have your workload cluster configured and sample service application deployed, as well as your Gateway API network resources applied to route traffic to your service, skip straight to step ❺. -At step ❺, instead of creating an For more about using Kuadrant to enforce authorization, check out Kuadrant auth. - |
-
- Kuadrant users –
- Remember to create an AuthPolicy instead of an AuthConfig.
- For more, see Kuadrant auth.
- |
-
If you are a user of Kuadrant and already have your workload cluster configured and sample service application deployed, as well as your Gateway API network resources applied to route traffic to your service, skip straight to step ❺.
-At step ❺, instead of creating an AuthConfig custom resource, create a Kuadrant AuthPolicy one. The schema of the AuthConfig's spec matches the one of the AuthPolicy's, except spec.host, which is not available in the Kuadrant AuthPolicy. Host names in a Kuadrant AuthPolicy are inferred automatically from the Kubernetes network object referred in spec.targetRef and route selectors declared in the policy.
For more about using Kuadrant to enforce authorization, check out Kuadrant auth.
-
- Kuadrant users –
- Remember to create an AuthPolicy instead of an AuthConfig.
- For more, see Kuadrant auth.
- |
-
If you are a user of Kuadrant and already have your workload cluster configured and sample service application deployed, as well as your Gateway API network resources applied to route traffic to your service, skip straight to step ❹.
-At steps ❹ and ❺, instead of creating an AuthConfig custom resource, create a Kuadrant AuthPolicy one. The schema of the AuthConfig's spec matches the one of the AuthPolicy's, except spec.host, which is not available in the Kuadrant AuthPolicy. Host names in a Kuadrant AuthPolicy are inferred automatically from the Kubernetes network object referred in spec.targetRef and route selectors declared in the policy.
For more about using Kuadrant to enforce authorization, check out Kuadrant auth.
-
- Kuadrant users –
- Remember to create an AuthPolicy instead of an AuthConfig.
- For more, see Kuadrant auth.
- |
-
- Kuadrant users –
- Remember to create an AuthPolicy instead of an AuthConfig.
- For more, see Kuadrant auth.
- |
-
If you are a user of Kuadrant and already have your workload cluster configured and sample service application deployed, as well as your Gateway API network resources applied to route traffic to your service, skip straight to step ❻.
-At step ❻, instead of creating an AuthConfig custom resource, create a Kuadrant AuthPolicy one. The schema of the AuthConfig's spec matches the one of the AuthPolicy's, except spec.host, which is not available in the Kuadrant AuthPolicy. Host names in a Kuadrant AuthPolicy are inferred automatically from the Kubernetes network object referred in spec.targetRef and route selectors declared in the policy.
For more about using Kuadrant to enforce authorization, check out Kuadrant auth.
-
- Kuadrant users –
- Remember to create an AuthPolicy instead of an AuthConfig.
- For more, see Kuadrant auth.
- |
-
If you are a user of Kuadrant and already have your workload cluster configured and sample service application deployed, as well as your Gateway API network resources applied to route traffic to your service, skip straight to step ❺.
-At step ❺, instead of creating an AuthConfig custom resource, create a Kuadrant AuthPolicy one. The schema of the AuthConfig's spec matches the one of the AuthPolicy's, except spec.host, which is not available in the Kuadrant AuthPolicy. Host names in a Kuadrant AuthPolicy are inferred automatically from the Kubernetes network object referred in spec.targetRef and route selectors declared in the policy.
For more about using Kuadrant to enforce authorization, check out Kuadrant auth.
-
- Kuadrant users –
- Remember to create an AuthPolicy instead of an AuthConfig.
- For more, see Kuadrant auth.
- |
-
If you are a user of Kuadrant, you can skip step ❸. You may already have Authorino installed and running as well. In this case, skip also step ❺. If you even have your workload cluster configured, with sample service application deployed, as well as your Gateway API network resources applied to route traffic to your service, go straight to step ❼.
-At step ❼, instead of creating an AuthConfig custom resource, create a Kuadrant AuthPolicy one. The schema of the AuthConfig's spec matches the one of the AuthPolicy's, except spec.host, which is not available in the Kuadrant AuthPolicy. Host names in a Kuadrant AuthPolicy are inferred automatically from the Kubernetes network object referred in spec.targetRef and route selectors declared in the policy.
For more about using Kuadrant to enforce authorization, check out Kuadrant auth.
-
- Kuadrant users –
- Remember to create an AuthPolicy instead of an AuthConfig.
- For more, see Kuadrant auth.
- |
-
| - ⚠️ Important: - This feature may not be available to users of Authorino via Kuadrant. - | -
| Using Kuadrant | -
|---|
|
- If you are a user of Kuadrant and already have your workload cluster configured and sample service application deployed, as well as your Gateway API network resources applied to route traffic to your service, skip straight to step ❺. -At step ❺, instead of creating an For more about using Kuadrant to enforce authorization, check out Kuadrant auth. - |
-
- Kuadrant users –
- Remember to create an AuthPolicy instead of an AuthConfig.
- For more, see Kuadrant auth.
- |
-
If you are a user of Kuadrant and already have your workload cluster configured and sample service application deployed, as well as your Gateway API network resources applied to route traffic to your service, skip straight to step ❺.
-At step ❺, instead of creating an AuthConfig custom resource, create a Kuadrant AuthPolicy one. The schema of the AuthConfig's spec matches the one of the AuthPolicy's, except spec.host, which is not available in the Kuadrant AuthPolicy. Host names in a Kuadrant AuthPolicy are inferred automatically from the Kubernetes network object referred in spec.targetRef and route selectors declared in the policy.
For more about using Kuadrant to enforce authorization, check out Kuadrant auth.
-
- Kuadrant users –
- Remember to create an AuthPolicy instead of an AuthConfig.
- For more, see Kuadrant auth.
- |
-
If you are a user of Kuadrant and already have your workload cluster configured and sample service application deployed, as well as your Gateway API network resources applied to route traffic to your service, skip straight to step ❺.
-At step ❺, instead of creating an AuthConfig custom resource, create a Kuadrant AuthPolicy one. The schema of the AuthConfig's spec matches the one of the AuthPolicy's, except spec.host, which is not available in the Kuadrant AuthPolicy. Host names in a Kuadrant AuthPolicy are inferred automatically from the Kubernetes network object referred in spec.targetRef and route selectors declared in the policy.
For more about using Kuadrant to enforce authorization, check out Kuadrant auth.
-
- Kuadrant users –
- Remember to create an AuthPolicy instead of an AuthConfig.
- For more, see Kuadrant auth.
- |
-
| Using Kuadrant | -
|---|
|
- If you are a user of Kuadrant and already have your workload cluster configured and sample service application deployed, as well as your Gateway API network resources applied to route traffic to your service, skip straight to step ❺. -At step ❺, instead of creating an For more about using Kuadrant to enforce authorization, check out Kuadrant auth. - |
-
- Kuadrant users –
- Remember to create an AuthPolicy instead of an AuthConfig.
- For more, see Kuadrant auth.
- |
-
If you are a user of Kuadrant and already have your workload cluster configured and sample service application deployed, as well as your Gateway API network resources applied to route traffic to your service, skip straight to step ❺.
-At step ❺, instead of creating an AuthConfig custom resource, create a Kuadrant AuthPolicy one. The schema of the AuthConfig's spec matches the one of the AuthPolicy's, except spec.host, which is not available in the Kuadrant AuthPolicy. Host names in a Kuadrant AuthPolicy are inferred automatically from the Kubernetes network object referred in spec.targetRef and route selectors declared in the policy.
For more about using Kuadrant to enforce authorization, check out Kuadrant auth.
-
- Kuadrant users –
- Remember to create an AuthPolicy instead of an AuthConfig.
- For more, see Kuadrant auth.
- |
-
If you are a user of Kuadrant and already have your workload cluster configured and sample service application deployed, as well as your Gateway API network resources applied to route traffic to your service, skip straight to step ❺.
-At step ❺, instead of creating an AuthConfig custom resource, create a Kuadrant AuthPolicy one. The schema of the AuthConfig's spec matches the one of the AuthPolicy's, except spec.host, which is not available in the Kuadrant AuthPolicy. Host names in a Kuadrant AuthPolicy are inferred automatically from the Kubernetes network object referred in spec.targetRef and route selectors declared in the policy.
For more about using Kuadrant to enforce authorization, check out Kuadrant auth.
-
- Kuadrant users –
- Remember to create an AuthPolicy instead of an AuthConfig.
- For more, see Kuadrant auth.
- |
-
If you are a user of Kuadrant and already have your workload cluster configured and sample service application deployed, as well as your Gateway API network resources applied to route traffic to your service, skip straight to step ❻.
-At step ❻, instead of creating an AuthConfig custom resource, create a Kuadrant AuthPolicy one. The schema of the AuthConfig's spec matches the one of the AuthPolicy's, except spec.host, which is not available in the Kuadrant AuthPolicy. Host names in a Kuadrant AuthPolicy are inferred automatically from the Kubernetes network object referred in spec.targetRef and route selectors declared in the policy.
For more about using Kuadrant to enforce authorization, check out Kuadrant auth.
-
- Kuadrant users –
- Remember to create an AuthPolicy instead of an AuthConfig.
- For more, see Kuadrant auth.
- |
-
If you are a user of Kuadrant and already have your workload cluster configured and sample service application deployed, as well as your Gateway API network resources applied to route traffic to your service, skip straight to step ❺.
-At step ❺, instead of creating an AuthConfig custom resource, create a Kuadrant AuthPolicy one. The schema of the AuthConfig's spec matches the one of the AuthPolicy's, except spec.host, which is not available in the Kuadrant AuthPolicy. Host names in a Kuadrant AuthPolicy are inferred automatically from the Kubernetes network object referred in spec.targetRef and route selectors declared in the policy.
For more about using Kuadrant to enforce authorization, check out Kuadrant auth.
-
- Kuadrant users –
- Remember to create an AuthPolicy instead of an AuthConfig.
- For more, see Kuadrant auth.
- |
-
If you are a user of Kuadrant and already have your workload cluster configured and sample service application deployed, as well as your Gateway API network resources applied to route traffic to your service, skip straight to step ❺.
-At step ❺, instead of creating an AuthConfig custom resource, create a Kuadrant AuthPolicy one. The schema of the AuthConfig's spec matches the one of the AuthPolicy's, except spec.host, which is not available in the Kuadrant AuthPolicy. Host names in a Kuadrant AuthPolicy are inferred automatically from the Kubernetes network object referred in spec.targetRef and route selectors declared in the policy.
For more about using Kuadrant to enforce authorization, check out Kuadrant auth.
-
- Kuadrant users –
- Remember to create an AuthPolicy instead of an AuthConfig.
- For more, see Kuadrant auth.
- |
-
If you are a user of Kuadrant and already have your workload cluster configured and sample service application deployed, as well as your Gateway API network resources applied to route traffic to your service, skip straight to step ❺.
-At step ❺, instead of creating an AuthConfig custom resource, create a Kuadrant AuthPolicy one. The schema of the AuthConfig's spec matches the one of the AuthPolicy's, except spec.host, which is not available in the Kuadrant AuthPolicy. Host names in a Kuadrant AuthPolicy are inferred automatically from the Kubernetes network object referred in spec.targetRef and route selectors declared in the policy.
For more about using Kuadrant to enforce authorization, check out Kuadrant auth.
-
- Kuadrant users –
- Remember to create an AuthPolicy instead of an AuthConfig.
- For more, see Kuadrant auth.
- |
-
| Using Kuadrant | -
|---|
|
- If you are a user of Kuadrant and already have your workload cluster configured and sample service application deployed, as well as your Gateway API network resources applied to route traffic to your service, skip straight to step ❺. -At step ❺, instead of creating an For more about using Kuadrant to enforce authorization, check out Kuadrant auth. - |
-
- Kuadrant users –
- Remember to create an AuthPolicy instead of an AuthConfig.
- For more, see Kuadrant auth.
- |
-
If you are a user of Kuadrant and already have your workload cluster configured and sample service application deployed, as well as your Gateway API network resources applied to route traffic to your service, skip straight to step ❺.
-At step ❺, instead of creating an AuthConfig custom resource, create a Kuadrant AuthPolicy one. The schema of the AuthConfig's spec matches the one of the AuthPolicy's, except spec.host, which is not available in the Kuadrant AuthPolicy. Host names in a Kuadrant AuthPolicy are inferred automatically from the Kubernetes network object referred in spec.targetRef and route selectors declared in the policy.
For more about using Kuadrant to enforce authorization, check out Kuadrant auth.
-
- Kuadrant users –
- Remember to create an AuthPolicy instead of an AuthConfig.
- For more, see Kuadrant auth.
- |
-
If you are a user of Kuadrant and already have your workload cluster configured and sample service application deployed, as well as your Gateway API network resources applied to route traffic to your service, skip straight to step ❺.
-At step ❺, instead of creating an AuthConfig custom resource, create a Kuadrant AuthPolicy one. The schema of the AuthConfig's spec matches the one of the AuthPolicy's, except spec.host, which is not available in the Kuadrant AuthPolicy. Host names in a Kuadrant AuthPolicy are inferred automatically from the Kubernetes network object referred in spec.targetRef and route selectors declared in the policy.
For more about using Kuadrant to enforce authorization, check out Kuadrant auth.
-
- Kuadrant users –
- Remember to create an AuthPolicy instead of an AuthConfig.
- For more, see Kuadrant auth.
- |
-
If you are a user of Kuadrant and already have your workload cluster configured and sample service application deployed, as well as your Gateway API network resources applied to route traffic to your service, skip straight to step ❺.
-At step ❺, instead of creating an AuthConfig custom resource, create a Kuadrant AuthPolicy one. The schema of the AuthConfig's spec matches the one of the AuthPolicy's, except spec.host, which is not available in the Kuadrant AuthPolicy. Host names in a Kuadrant AuthPolicy are inferred automatically from the Kubernetes network object referred in spec.targetRef and route selectors declared in the policy.
For more about using Kuadrant to enforce authorization, check out Kuadrant auth.
-
- Kuadrant users –
- Remember to create an AuthPolicy instead of an AuthConfig.
- For more, see Kuadrant auth.
- |
-
| - ⚠️ Important: - This feature may not be available to users of Authorino via Kuadrant. - | -
| Using Kuadrant | -
|---|
|
- If you are a user of Kuadrant and already have your workload cluster configured and sample service application deployed, as well as your Gateway API network resources applied to route traffic to your service, skip straight to step ❺. -At step ❺, instead of creating an For more about using Kuadrant to enforce authorization, check out Kuadrant auth. - |
-
- Kuadrant users –
- Remember to create an AuthPolicy instead of an AuthConfig.
- For more, see Kuadrant auth.
- |
-
If you are a user of Kuadrant you may already have Authorino installed and running. In this case, skip straight to step ❸.
-At step ❺, alternatively to creating an AuthConfig custom resource, you may create a Kuadrant AuthPolicy one. The schema of the AuthConfig's spec matches the one of the AuthPolicy's, except spec.host, which is not available in the Kuadrant AuthPolicy. Host names in a Kuadrant AuthPolicy are inferred automatically from the Kubernetes network object referred in spec.targetRef and route selectors declared in the policy.
For more about using Kuadrant to enforce authorization, check out Kuadrant auth.
-
- Kuadrant users –
- For this and other example AuthConfigs below, if you create a Kuadrant AuthPolicy instead, the output of the commands shall differ. The requested AuthPolicy may be initially accepted, but its state will turn ready or not ready depending on whether the corresponding AuthConfig requested by Kuadrant is accepted or rejected, according to the validating webhook rules. Check the state of the resources to confirm.
- For more, see Kuadrant auth.
- |
-