diff --git a/images/connectivity-link-app-dev-dashboard.png b/images/connectivity-link-app-dev-dashboard.png deleted file mode 100644 index 1e10ec80c827..000000000000 Binary files a/images/connectivity-link-app-dev-dashboard.png and /dev/null differ diff --git a/images/connectivity-link-app-dev-flow.png b/images/connectivity-link-app-dev-flow.png deleted file mode 100644 index 373a5767e682..000000000000 Binary files a/images/connectivity-link-app-dev-flow.png and /dev/null differ diff --git a/images/connectivity-link-business-user-dashboard.png b/images/connectivity-link-business-user-dashboard.png deleted file mode 100644 index ce0f7e55511c..000000000000 Binary files a/images/connectivity-link-business-user-dashboard.png and /dev/null differ diff --git a/images/connectivity-link-gateway-api.png b/images/connectivity-link-gateway-api.png deleted file mode 100644 index 7b5d96a036a0..000000000000 Binary files a/images/connectivity-link-gateway-api.png and /dev/null differ diff --git a/images/connectivity-link-grafana-trace.png b/images/connectivity-link-grafana-trace.png deleted file mode 100644 index bc9d32a4f37c..000000000000 Binary files a/images/connectivity-link-grafana-trace.png and /dev/null differ diff --git a/images/connectivity-link-platform-eng-dashboard.png b/images/connectivity-link-platform-eng-dashboard.png deleted file mode 100644 index ff983331db97..000000000000 Binary files a/images/connectivity-link-platform-eng-dashboard.png and /dev/null differ diff --git a/images/connectivity-link-platform-eng-gateway-flow.png b/images/connectivity-link-platform-eng-gateway-flow.png deleted file mode 100644 index de4f98ce4a02..000000000000 Binary files a/images/connectivity-link-platform-eng-gateway-flow.png and /dev/null differ diff --git a/images/connectivity-link-platform-eng-policy-flow.png b/images/connectivity-link-platform-eng-policy-flow.png deleted file mode 100644 index 131d970d35ce..000000000000 Binary files a/images/connectivity-link-platform-eng-policy-flow.png and /dev/null differ diff --git a/modules/con-connectivity-link-app-dev-work.adoc b/modules/con-connectivity-link-app-dev-work.adoc index 93733966173b..cf263c6695ff 100644 --- a/modules/con-connectivity-link-app-dev-work.adoc +++ b/modules/con-connectivity-link-app-dev-work.adoc @@ -7,18 +7,22 @@ = Application developer workflow [role="_abstract"] -As an application developer, you can use {prodname} to deploy applications and APIs on {ocp} clusters and gateways that are set up by platform engineers. You can also monitor workloads and the status of {ocp} resource metrics and tracing by using Grafana-based observability dashboards and alerts. +As an application developer, you can use {prodname} to deploy applications and APIs on {ocp} clusters and gateways that are set up by platform engineers. You can also monitor workloads and the status of {ocp} resource metrics and tracing by using observability dashboards and alerts. -Protect applications:: -You can route to applications from the gateway, configure protection for your services with root-level authentication, external authorization, and rate limiting. +Example tasks:: -Create application routes and definitions:: -Set up application routes and API definitions and publish them to the cluster. +* Configure routes +** Set up application routes and API definitions and publish them to the cluster. -Observe application and API performance:: -You can also monitor workloads and the status of {ocp} resource metrics and tracing by using Grafana-based observability dashboards and alerts. View API metrics, such as uptime, requests per second, latency, and errors per minute, to ensure that APIs meet performance and availability benchmarks achieved by other data centers. +* Protect applications with Auth policies +** OAuth 2 +** JWT authorization policies +** API keys +** Kubernetes tokens +** Role-based access (RBAC) +** Relationship-based access control (ReBAC) +** Open Policy Agent (OPA) -The following diagram shows a high-level overview of the {prodname} application developer workflow: - -.{prodname} application developer configures policies for applications and APIs -image::connectivity-link-app-dev-flow.png[{prodname} application developer workflow] +* Observe application and API performance +** Monitor workloads and the status of {ocp} resource metrics and tracing by using observability dashboards and alerts. +** Ensure that APIs meet performance and availability benchmarks achieved by other data centers by viewing API metrics, such as uptime, requests per second, latency, and errors per minute. diff --git a/modules/con-connectivity-link-platform-eng-work.adoc b/modules/con-connectivity-link-platform-eng-work.adoc index cfd1fc26d3bc..6b18a1c47233 100644 --- a/modules/con-connectivity-link-platform-eng-work.adoc +++ b/modules/con-connectivity-link-platform-eng-work.adoc @@ -7,25 +7,26 @@ = Platform engineer workflow [role="_abstract"] -As a platform engineer or infrastructure provider, you can use {prodname} to set up ingress gateways on {ocp} clusters in specific regions. You can ensure that all policies are configured identically on all gateways for consistency. +As a platform engineer or infrastructure provider, you can use {prodname} to set up ingress gateways on {ocp} clusters in specific regions. You can configure all policies identically on all gateways for consistency. -For example, configure DNS policies to ensure that customers in Brazil are routed to the South American data center, and that other customers around the world are routed to the appropriate environment. You can also configure TLS, authentication and authorization, and rate-limiting policies to ensure that gateway security, performance, and monitoring all conform to your standards. - -The following diagrams show a high-level overview of the {prodname} platform engineer workflow: - -.{prodname} platform engineer sets up gateways -image::connectivity-link-platform-eng-gateway-flow.png[{prodname} platform engineer sets up gateway workflow] +For example, configure DNS policies to ensure that customers in Brazil are routed to the South American data center and so on. You can also configure TLS, authentication and authorization, and rate-limiting policies to ensure that gateway security, performance, and monitoring all conform to your standards. +Connect gateways and load balance:: As a platform engineer, you must start by creating at least one gateway. If gateways exist, you can move on to configuring policies for your gateways. -.{prodname} platform engineer configures gateway policies -image::connectivity-link-platform-eng-policy-flow.png[{prodname} platform engineer configures gateway policies workflow] +You can connect gateways by creating a DNS policy and configuring a global load balancing strategy. DNS records are reconciled with your cloud DNS provider automatically, whether in a single-cluster or multicluster environment. You can use the following features: -Connect gateways:: -You can connect gateways by creating a DNS policy and configuring a global load balancing strategy. DNS records are reconciled with your cloud DNS provider automatically, whether in a single-cluster or multicluster environment. +* Automatic DNS configuration +* Mutiple DNS providers +* DNS-based load balancing, such as round-robin, weighted, and geo-based +* Single or multi-cluster ready Secure gateways:: -You can secure gateways by using a TLS policy that automatically generates certificate requests for the hostnames specified in your gateway. This includes support for the main ACME providers such as Let's Encrypt. You can also set up application security defaults and overrides by using authentication and authorization policies and rate-limiting policies. +After you create your gateways, secure them. You can secure gateways by using a TLS policy that automatically generates certificate requests for the host names specified in your gateway. You can also set up application security defaults and overrides by using authentication and authorization policies and rate-limiting policies. You can use the following features: + +* TLS: Automatic certificate requests and ACME providers +* Auth policies +* Rate-limiting: Global rate-limiting, external IDPs, default and overrides Observe gateways:: -In addition, you can observe your connectivity and runtime metrics by using Grafana-based dashboards and alerts. For example, this includes metrics for policy compliance and governance, resource consumption, error rates, request latency and throughput, multicluster split, and so on. +After your gateways are created and secured, you can configure your observability stack. Observe your connectivity and runtime metrics by using dashboards and alerts. For example, configure metrics for policy compliance and governance, resource consumption, error rates, request latency and throughput. diff --git a/modules/proc-app-dev-flow.adoc b/modules/proc-app-dev-flow.adoc index 4bf736836435..fbad40ade865 100644 --- a/modules/proc-app-dev-flow.adoc +++ b/modules/proc-app-dev-flow.adoc @@ -4,37 +4,39 @@ :_mod-docs-content-type: PROCEDURE [id="proc-app-developer-workflow_{context}"] -= Override your Gateway policies for auth and rate limiting += Override your gateway policies for auth and rate limiting [role="_abstract"] -As an application developer, you can override your existing Gateway-level policies to configure your application-level auth and rate limiting requirements. +As an application developer, you can override your existing gateway-level policies to configure your application-level auth and rate limiting requirements. You can allow authenticated access to the Toystore API by defining a new `AuthPolicy` that targets the `HTTPRoute` resource created in the previous section. [IMPORTANT] ==== -Any new HTTPRoutes are affected by the existing Gateway-level policy. Because you want users to now access this API, you must override that Gateway policy. For simplicity, you can use API keys to authenticate the requests, but other options such as OpenID Connect are also available. +Any new `HTTPRoutes` are affected by the existing gateway-level policy. Because you want users to now access this API, you must override that gateway policy. For simplicity, you can use API keys to authenticate the requests, but other options such as OpenID Connect are also available. ==== .Prerequisites -* Your {prodname} policies are configured as described in xref:platform-engineer-workflow_{context}[]. -//TODO FIXME +* {prodname} is installed. +* You configured {prodname} policies. +* The {oc-first} is installed. +* You are logged into {ocp} as a cluster administrator. .Procedure -. Ensure that your {prodname} system namespace is set correctly as follows: +. Ensure that your {prodname} system namespace is set correctly by running the following command: + -[source,bash] +[source,terminal] ---- -$ export KUADRANT_SYSTEM_NS=$(kubectl get kuadrant -A -o jsonpath="{.items[0].metadata.namespace}") +$ export KUADRANT_SYSTEM_NS=$(oc get kuadrant -A -o jsonpath="{.items[0].metadata.namespace}") ---- . Define API keys for *bob* and *alice* users as follows: + -[source,bash] +[source,terminal] ---- -$ kubectl apply -f - < /local/path/to/azure.json { diff --git a/modules/proc-configure-dns-provider-google.adoc b/modules/proc-configure-dns-provider-google.adoc index 2da0fae974ac..ab1c338082a6 100644 --- a/modules/proc-configure-dns-provider-google.adoc +++ b/modules/proc-configure-dns-provider-google.adoc @@ -50,7 +50,7 @@ $ export PROJECT_ID=xxxxxxx . Create a `Secret` resource for your credentials by running the following command: + -[source,bash] +[source,terminal] ---- $ oc create secret generic test-gcp-credentials \ --namespace=api-gateway \ diff --git a/modules/proc-configure-obs-monitoring.adoc b/modules/proc-configure-obs-monitoring.adoc index 7328422fa1cf..a29af1beab46 100644 --- a/modules/proc-configure-obs-monitoring.adoc +++ b/modules/proc-configure-obs-monitoring.adoc @@ -54,7 +54,7 @@ kubectl apply -k config/observability/openshift/grafana . Configure the example Grafana dashboards as follows: + -[source,bash,subs="attributes+"] +[source,terminal,subs="attributes+"] ---- $ kubectl apply -k https://github.com/Kuadrant/kuadrant-operator/examples/dashboards?ref=v{operator-version} ---- diff --git a/modules/proc-install-on-openshift-cmd.adoc b/modules/proc-install-on-openshift-cmd.adoc index f880c31ea638..603ab4431dd8 100644 --- a/modules/proc-install-on-openshift-cmd.adoc +++ b/modules/proc-install-on-openshift-cmd.adoc @@ -68,7 +68,7 @@ $ oc wait --for=jsonpath={.status.installPlanRef.name} subscription rhcl-operato ip=$(oc get subscription rhcl-operator -o=jsonpath={.status.installPlanRef.name}) ---- + -[source,bash] +[source,terminal] ---- $ oc wait --for=condition=Installed installplan ${ip} --timeout=60s ---- @@ -77,7 +77,7 @@ Expect the status of `installplan.operators.coreos.com/install-4rql7` when {prod . To create your {prodname} CR, enter the following command: + -[source,bash] +[source,terminal] ---- $ oc apply -f - <