mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-07 09:46:53 +01:00
Merge pull request #68302 from mburke5678/service-mesh-fix-errors-2
Service Mesh docs fixes during ROSA review 2
This commit is contained in:
Michael Burke
@@ -14,7 +14,7 @@ When updating from Elasticsearch 5 to 6, you must delete your {JaegerShortName}
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc get jaeger -n <istio-system>
|
||||
$ oc get jaeger -n istio-system
|
||||
----
|
||||
+
|
||||
You will see output similar to the following:
|
||||
@@ -29,21 +29,21 @@ jaeger Running 1.24.1 production elasticsearch d21h
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc get jaeger jaeger -oyaml -n <istio-system> > /tmp/jaeger-cr.yaml
|
||||
$ oc get jaeger jaeger -oyaml -n istio-system > /tmp/jaeger-cr.yaml
|
||||
----
|
||||
|
||||
. Delete the {JaegerShortName} instance by running the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc delete jaeger jaeger -n <istio-system>
|
||||
$ oc delete jaeger jaeger -n istio-system
|
||||
----
|
||||
|
||||
. Recreate the {JaegerShortName} instance from your copy of the custom resource file by running the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc create -f /tmp/jaeger-cr.yaml -n <istio-system>
|
||||
$ oc create -f /tmp/jaeger-cr.yaml -n istio-system
|
||||
----
|
||||
|
||||
. Delete the copy of the generated custom resource file by running the following command:
|
||||
|
||||
@@ -23,7 +23,7 @@ search for the Jaeger route, which is the URL listed under *Location*.
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ export JAEGER_URL=$(oc get route -n istio-system jaeger -o jsonpath='{.spec.host}')
|
||||
$ oc get route -n istio-system jaeger -o jsonpath='{.spec.host}'
|
||||
----
|
||||
+
|
||||
. Launch a browser and navigate to ``\https://<JAEGER_URL>``, where `<JAEGER_URL>` is the route that you discovered in the previous step.
|
||||
|
||||
@@ -12,15 +12,7 @@ You can install the `cert-manager` tool to manage the lifecycle of TLS certifica
|
||||
|
||||
. Create the root cluster issuer:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc apply -f cluster-issuer.yaml
|
||||
----
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc apply -n istio-system -f istio-ca.yaml
|
||||
----
|
||||
.. Create the `cluster-issuer` object as in the following example:
|
||||
+
|
||||
.Example `cluster-issuer.yaml`
|
||||
[source, yaml]
|
||||
@@ -60,6 +52,20 @@ spec:
|
||||
secretName: root-ca
|
||||
----
|
||||
+
|
||||
====
|
||||
[NOTE]
|
||||
The namespace of the `selfsigned-root-issuer` issuer and `root-ca` certificate is `cert-manager` because `root-ca` is a cluster issuer, so the cert-manager looks for a referenced secret in its own namespace. The namespace is called `cert-manager` in the case of the {cert-manager-operator}.
|
||||
====
|
||||
|
||||
.. Create the object by using the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc apply -f cluster-issuer.yaml
|
||||
----
|
||||
|
||||
.. Create the `istio-ca` object as in the following example:
|
||||
+
|
||||
.Example `istio-ca.yaml`
|
||||
[source, yaml]
|
||||
----
|
||||
@@ -90,11 +96,13 @@ spec:
|
||||
ca:
|
||||
secretName: istio-ca
|
||||
----
|
||||
|
||||
.. Use the following command to create the object:
|
||||
+
|
||||
====
|
||||
[NOTE]
|
||||
The namespace of the `selfsigned-root-issuer` issuer and `root-ca` certificate is `cert-manager` because `root-ca` is a cluster issuer, so the cert-manager looks for a referenced secret in its own namespace. Its own namespace is `cert-manager` in the case of the {cert-manager-operator}.
|
||||
====
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc apply -n istio-system -f istio-ca.yaml
|
||||
----
|
||||
|
||||
. Install `istio-csr`:
|
||||
+
|
||||
|
||||
@@ -321,6 +321,13 @@ In the following example, the administrator is configuring the SMCP for federati
|
||||
.Sample SMCP for NodePort
|
||||
[source,yaml]
|
||||
----
|
||||
apiVersion: maistra.io/v2
|
||||
kind: ServiceMeshControlPlane
|
||||
metadata:
|
||||
name: green-mesh
|
||||
namespace: green-mesh-system
|
||||
spec:
|
||||
# ...
|
||||
gateways:
|
||||
additionalIngress:
|
||||
ingress-green-mesh:
|
||||
|
||||
@@ -103,22 +103,11 @@ $ oc create -n red-mesh-system -f export-to-green-mesh.yaml
|
||||
----
|
||||
+
|
||||
. Create additional `ExportedServiceSets` as needed for each mesh peer in your federated mesh.
|
||||
|
||||
.Verification
|
||||
|
||||
//TODO - Add sample output after the validation
|
||||
. To validate the services you've exported from `red-mesh` to share with `green-mesh`, run the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc get exportedserviceset <PeerMeshExportedTo> -o yaml
|
||||
----
|
||||
+
|
||||
For example:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc get exportedserviceset green-mesh -o yaml
|
||||
----
|
||||
+
|
||||
. Run the following command to validate the services the red-mesh exports to share with green-mesh:
|
||||
* Run the following command to validate the services the red-mesh exports to share with green-mesh:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
|
||||
@@ -41,7 +41,7 @@ Follow this procedure to create an `ImportedServiceSet` with the web console. Th
|
||||
////
|
||||
|
||||
|
||||
.Procedure from the CLI
|
||||
.Procedure
|
||||
|
||||
Follow this procedure to create an `ImportedServiceSet` from the command line.
|
||||
|
||||
@@ -96,29 +96,19 @@ $ oc create -n green-mesh-system -f import-from-red-mesh.yaml
|
||||
----
|
||||
+
|
||||
. Create additional `ImportedServiceSet` resources as needed for each mesh peer in your federated mesh.
|
||||
|
||||
.Verification
|
||||
|
||||
//TODO - Add sample output after the validation
|
||||
. To validate the services you've imported into `green-mesh`, run the following command:
|
||||
|
||||
* Run the following command to verify that the services were imported into `green-mesh`:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc get importedserviceset <PeerMeshImportedInto> -o yaml
|
||||
----
|
||||
+
|
||||
For example:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc get importedserviceset green-mesh -o yaml
|
||||
----
|
||||
+
|
||||
. Run the following command to validate the services imported into a mesh.
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc get importedserviceset <PeerMeshImportedInto> -o yaml
|
||||
----
|
||||
+
|
||||
.Example validating that the services exported from the red mesh have been imported into the green mesh using the status section of the `importedserviceset/red-mesh' object in the 'green-mesh-system` namespace:
|
||||
.Example verifying that the services exported from the red mesh have been imported into the green mesh using the status section of the `importedserviceset/red-mesh' object in the 'green-mesh-system` namespace:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
|
||||
@@ -50,7 +50,7 @@ $ oc login --username=<NAMEOFUSER> https://<HOSTNAME>:6443
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ export JAEGER_URL=$(oc get route -n istio-system jaeger -o jsonpath='{.spec.host}')
|
||||
$ oc get route -n istio-system jaeger -o jsonpath='{.spec.host}'
|
||||
----
|
||||
+
|
||||
. Launch a browser and navigate to ``\https://<JAEGER_URL>``, where `<JAEGER_URL>` is the route that you discovered in the previous step.
|
||||
|
||||
@@ -13,7 +13,7 @@ In previous versions of {SMProductName}, Mixer's policy enforcement was enabled
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
The examples use `<istio-system>` as the control plane namespace. Replace this value with the namespace where you deployed the Service Mesh Control Plane (SMCP).
|
||||
The examples use `istio-system` as the control plane namespace. Replace this value with the namespace where you deployed the Service Mesh Control Plane (SMCP).
|
||||
====
|
||||
|
||||
.Procedure
|
||||
@@ -24,14 +24,14 @@ The examples use `<istio-system>` as the control plane namespace. Replace this v
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc get cm -n <istio-system> istio -o jsonpath='{.data.mesh}' | grep disablePolicyChecks
|
||||
$ oc get cm -n istio-system istio -o jsonpath='{.data.mesh}' | grep disablePolicyChecks
|
||||
----
|
||||
|
||||
. If `disablePolicyChecks: true`, edit the {SMProductShortName} ConfigMap:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc edit cm -n <istio-system> istio
|
||||
$ oc edit cm -n istio-system istio
|
||||
----
|
||||
|
||||
. Locate `disablePolicyChecks: true` within the ConfigMap and change the value to `false`.
|
||||
|
||||
@@ -13,7 +13,7 @@ In previous versions of {SMProductName}, Mixer's policy enforcement was enabled
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
The examples use `<istio-system>` as the {SMProductShortName} control plane namespace. Replace this value with the namespace where you deployed the Service Mesh Control Plane (SMCP).
|
||||
The examples use `istio-system` as the {SMProductShortName} control plane namespace. Replace this value with the namespace where you deployed the Service Mesh Control Plane (SMCP).
|
||||
====
|
||||
|
||||
.Procedure
|
||||
@@ -24,14 +24,14 @@ The examples use `<istio-system>` as the {SMProductShortName} control plane name
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc get cm -n <istio-system> istio -o jsonpath='{.data.mesh}' | grep disablePolicyChecks
|
||||
$ oc get cm -n istio-system istio -o jsonpath='{.data.mesh}' | grep disablePolicyChecks
|
||||
----
|
||||
|
||||
. If `disablePolicyChecks: true`, edit the {SMProductShortName} ConfigMap:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc edit cm -n <istio-system> istio
|
||||
$ oc edit cm -n istio-system istio
|
||||
----
|
||||
|
||||
. Locate `disablePolicyChecks: true` within the ConfigMap and change the value to `false`.
|
||||
|
||||
@@ -76,4 +76,6 @@ spec:
|
||||
+
|
||||
.. Click *Save*.
|
||||
|
||||
. Click *Reload* to verify the `ServiceMeshControlPlane` resource was configured correctly.
|
||||
.Verification
|
||||
|
||||
* Click *Reload* to verify that the `ServiceMeshControlPlane` resource was configured correctly.
|
||||
|
||||
@@ -101,10 +101,14 @@ In the following example, the `oc label` command removes the `ignore-namespace`
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc label namespace <istio_system> maistra.io/ignore-namespace-
|
||||
$ oc label namespace istio-system maistra.io/ignore-namespace-
|
||||
----
|
||||
+
|
||||
In the example above, <istio_system> represents the name of the `ServiceMeshControlPlane` namespace.
|
||||
where:
|
||||
+
|
||||
--
|
||||
istio_system :: Specified the name of the `ServiceMeshControlPlane` namespace.
|
||||
--
|
||||
|
||||
* https://issues.redhat.com/browse/OSSM-2053[OSSM-2053] Using {SMProductName} Operator 2.2 or 2.3, during SMCP reconciliation, the SMMR controller removed the member namespaces from `SMMR.status.configuredMembers`. This caused the services in the member namespaces to become unavailable for a few moments.
|
||||
+
|
||||
@@ -174,7 +178,7 @@ Now, the Operator ignores resources that does not also include the `app.kubernet
|
||||
|
||||
* link:https://issues.jboss.org/browse/MAISTRA-2411[MAISTRA-2411] When the Operator creates a new ingress gateway using `spec.gateways.additionaIngress` in the `ServiceMeshControlPlane`, Operator is not creating a `NetworkPolicy` for the additional ingress gateway like it does for the default istio-ingressgateway. This is causing a 503 response from the route of the new gateway.
|
||||
+
|
||||
Workaround: Manually create the `NetworkPolicy` in the <istio-system> namespace.
|
||||
Workaround: Manually create the `NetworkPolicy` in the `istio-system` namespace.
|
||||
|
||||
* link:https://issues.redhat.com/browse/MAISTRA-2401[MAISTRA-2401] CVE-2021-3586 servicemesh-operator: NetworkPolicy resources incorrectly specified ports for ingress resources. The NetworkPolicy resources installed for {SMProductName} did not properly specify which ports could be accessed. This allowed access to all ports on these resources from any pod. Network policies applied to the following resources are affected:
|
||||
|
||||
|
||||
@@ -25,7 +25,7 @@ Without virtual services, {SMProductName} distributes traffic using least reques
|
||||
. Create a YAML file using the following example to route requests to different versions of the Bookinfo sample application service depending on which user connects to the application.
|
||||
+
|
||||
.Example VirtualService.yaml
|
||||
[source,YAML]
|
||||
[source,yaml]
|
||||
----
|
||||
apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
|
||||
@@ -46,7 +46,7 @@ spec:
|
||||
rules:
|
||||
- from:
|
||||
- source:
|
||||
ipBlocks: ["1.2.3.4"]
|
||||
ipBlocks: ["1.2.3.4"]
|
||||
----
|
||||
+
|
||||
. Run the following command after you write your resource to create your resource in your namespace. The namespace must match your `metadata.namespace` field in your `AuthorizationPolicy` resource.
|
||||
|
||||
@@ -47,7 +47,9 @@ spec:
|
||||
|
||||
. Ensure your security certificates are production ready by installing security certificates from an external certificate authority. For more information, see the Security section.
|
||||
|
||||
. Verify the results. Enter the following command to verify that the `ServiceMeshControlPlane` resource updated properly. In this example, `basic` is the name of the `ServiceMeshControlPlane` resource.
|
||||
.Verification
|
||||
|
||||
. Enter the following command to verify that the `ServiceMeshControlPlane` resource updated properly. In this example, `basic` is the name of the `ServiceMeshControlPlane` resource.
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
|
||||
@@ -16,7 +16,7 @@ The custom resources (CRs) set up the service entries and destination rules for
|
||||
.. Add the `ServiceEntry` CR to a file called `service-entry-threescale-saas-backend.yml`:
|
||||
+
|
||||
.ServiceEntry CR
|
||||
[source,terminal]
|
||||
[source,yaml]
|
||||
----
|
||||
apiVersion: networking.istio.io/v1beta1
|
||||
kind: ServiceEntry
|
||||
@@ -35,7 +35,7 @@ spec:
|
||||
.. Add the `DestinationRule` CR to a file called `destination-rule-threescale-saas-backend.yml`:
|
||||
+
|
||||
.DestinationRule CR
|
||||
[source,terminal]
|
||||
[source,yaml]
|
||||
----
|
||||
apiVersion: networking.istio.io/v1beta1
|
||||
kind: DestinationRule
|
||||
|
||||
@@ -15,12 +15,12 @@ You might want to check whether the 3scale Istio adapter is working as expected.
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc get pods -n <istio-system>
|
||||
$ oc get pods -n istio-system
|
||||
----
|
||||
. Check that the _3scale-adapter_ pod has printed out information about itself booting up, such as its version:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc logs <istio-system>
|
||||
$ oc logs istio-system
|
||||
----
|
||||
. When performing requests to the services protected by the 3scale adapter integration, always try requests that lack the right credentials and ensure they fail. Check the 3scale adapter logs to gather additional information.
|
||||
|
||||
@@ -23,7 +23,7 @@ metadata:
|
||||
spec:
|
||||
pluginConfig:
|
||||
api: v1
|
||||
...
|
||||
# ...
|
||||
----
|
||||
|
||||
The `api` entry defines the rest of the values for the configuration. The only accepted value is `v1`. New settings that break compatibility with the current configuration or need more logic that modules using `v1` cannot handle, will require different values.
|
||||
|
||||
@@ -15,11 +15,11 @@ metadata:
|
||||
name: <threescale_wasm_plugin_name>
|
||||
spec:
|
||||
pluginConfig:
|
||||
...
|
||||
# ...
|
||||
backend:
|
||||
name: backend
|
||||
upstream: <object>
|
||||
...
|
||||
# ...
|
||||
----
|
||||
|
||||
.`backend` object fields
|
||||
|
||||
@@ -17,13 +17,13 @@ metadata:
|
||||
name: <threescale_wasm_plugin_name>
|
||||
spec:
|
||||
pluginConfig:
|
||||
...
|
||||
# ...
|
||||
services:
|
||||
- credentials:
|
||||
user_key: <array_of_lookup_queries>
|
||||
app_id: <array_of_lookup_queries>
|
||||
app_key: <array_of_lookup_queries>
|
||||
...
|
||||
# ...
|
||||
----
|
||||
|
||||
.`credentials` object fields
|
||||
|
||||
@@ -17,14 +17,23 @@ The following example looks up a `user_key` in a query string parameter or heade
|
||||
|
||||
[source,yaml]
|
||||
----
|
||||
credentials:
|
||||
user_key:
|
||||
- query_string:
|
||||
keys:
|
||||
- user_key
|
||||
- header:
|
||||
keys:
|
||||
- user_key
|
||||
apiVersion: extensions.istio.io/v1alpha1
|
||||
kind: WasmPlugin
|
||||
metadata:
|
||||
name: <threescale_wasm_plugin_name>
|
||||
spec:
|
||||
# ...
|
||||
services:
|
||||
# ...
|
||||
credentials:
|
||||
user_key:
|
||||
- query_string:
|
||||
keys:
|
||||
- <user_key>
|
||||
- header:
|
||||
keys:
|
||||
- <user_key>
|
||||
# ...
|
||||
----
|
||||
|
||||
[id="application-id-and-key_{context}"]
|
||||
@@ -33,21 +42,30 @@ The following example looks up `app_key` and `app_id` credentials in a query or
|
||||
|
||||
[source,yaml]
|
||||
----
|
||||
credentials:
|
||||
app_id:
|
||||
- header:
|
||||
keys:
|
||||
- app_id
|
||||
- query_string:
|
||||
keys:
|
||||
- app_id
|
||||
app_key:
|
||||
- header:
|
||||
keys:
|
||||
- app_key
|
||||
- query_string:
|
||||
keys:
|
||||
- app_key
|
||||
apiVersion: extensions.istio.io/v1alpha1
|
||||
kind: WasmPlugin
|
||||
metadata:
|
||||
name: <threescale_wasm_plugin_name>
|
||||
spec:
|
||||
# ...
|
||||
services:
|
||||
# ...
|
||||
credentials:
|
||||
app_id:
|
||||
- query_string:
|
||||
keys:
|
||||
- <app_id>
|
||||
- header:
|
||||
keys:
|
||||
- <app_id>
|
||||
app_key:
|
||||
- query_string:
|
||||
keys:
|
||||
- <app_key>
|
||||
- header:
|
||||
keys:
|
||||
- <app_key>
|
||||
# ...
|
||||
----
|
||||
|
||||
[id="authorization-header_{context}"]
|
||||
@@ -66,26 +84,35 @@ You must use lower case header field names as shown in the following example:
|
||||
|
||||
[source,yaml]
|
||||
----
|
||||
credentials:
|
||||
app_id:
|
||||
- header:
|
||||
keys:
|
||||
- authorization
|
||||
ops:
|
||||
- split:
|
||||
separator: " "
|
||||
max: 2
|
||||
- length:
|
||||
min: 2
|
||||
- drop:
|
||||
head: 1
|
||||
- base64_urlsafe
|
||||
- split:
|
||||
max: 2
|
||||
app_key:
|
||||
- header:
|
||||
keys:
|
||||
- app_key
|
||||
apiVersion: extensions.istio.io/v1alpha1
|
||||
kind: WasmPlugin
|
||||
metadata:
|
||||
name: <threescale_wasm_plugin_name>
|
||||
spec:
|
||||
# ...
|
||||
services:
|
||||
# ...
|
||||
credentials:
|
||||
app_id:
|
||||
- header:
|
||||
keys:
|
||||
- authorization
|
||||
ops:
|
||||
- split:
|
||||
separator: " "
|
||||
max: 2
|
||||
- length:
|
||||
min: 2
|
||||
- drop:
|
||||
head: 1
|
||||
- base64_urlsafe
|
||||
- split:
|
||||
max: 2
|
||||
app_key:
|
||||
- header:
|
||||
keys:
|
||||
- app_key
|
||||
# ...
|
||||
----
|
||||
|
||||
The previous example use case looks at the headers for an `authorization`:
|
||||
@@ -98,46 +125,55 @@ The previous example use case looks at the headers for an `authorization`:
|
||||
+
|
||||
[source,yaml]
|
||||
----
|
||||
credentials:
|
||||
app_id:
|
||||
- header:
|
||||
keys:
|
||||
- authorization
|
||||
ops:
|
||||
- split:
|
||||
separator: " "
|
||||
max: 2
|
||||
- length:
|
||||
min: 2
|
||||
- reverse
|
||||
- glob:
|
||||
- Basic
|
||||
- drop:
|
||||
tail: 1
|
||||
- base64_urlsafe
|
||||
- split:
|
||||
max: 2
|
||||
- test:
|
||||
if:
|
||||
length:
|
||||
min: 2
|
||||
then:
|
||||
- strlen:
|
||||
max: 63
|
||||
- or:
|
||||
- strlen:
|
||||
min: 1
|
||||
- drop:
|
||||
tail: 1
|
||||
- assert:
|
||||
- and:
|
||||
- reverse
|
||||
- or:
|
||||
- strlen:
|
||||
min: 8
|
||||
apiVersion: extensions.istio.io/v1alpha1
|
||||
kind: WasmPlugin
|
||||
metadata:
|
||||
name: <threescale_wasm_plugin_name>
|
||||
spec:
|
||||
# ...
|
||||
services:
|
||||
# ...
|
||||
credentials:
|
||||
app_id:
|
||||
- header:
|
||||
keys:
|
||||
- authorization
|
||||
ops:
|
||||
- split:
|
||||
separator: " "
|
||||
max: 2
|
||||
- length:
|
||||
min: 2
|
||||
- reverse
|
||||
- glob:
|
||||
- aladdin
|
||||
- admin
|
||||
- Basic
|
||||
- drop:
|
||||
tail: 1
|
||||
- base64_urlsafe
|
||||
- split:
|
||||
max: 2
|
||||
- test:
|
||||
if:
|
||||
length:
|
||||
min: 2
|
||||
then:
|
||||
- strlen:
|
||||
max: 63
|
||||
- or:
|
||||
- strlen:
|
||||
min: 1
|
||||
- drop:
|
||||
tail: 1
|
||||
- assert:
|
||||
- and:
|
||||
- reverse
|
||||
- or:
|
||||
- strlen:
|
||||
min: 8
|
||||
- glob:
|
||||
- aladdin
|
||||
- admin
|
||||
# ...
|
||||
----
|
||||
+
|
||||
. After picking up the `authorization` header value, you get a `Basic` `credential`-type by reversing the stack so that the type is placed on top.
|
||||
@@ -188,18 +224,27 @@ To get `app_id` field from Envoy's native `JWT` authentication filter, see the f
|
||||
|
||||
[source,yaml]
|
||||
----
|
||||
credentials:
|
||||
app_id:
|
||||
- filter:
|
||||
path:
|
||||
- envoy.filters.http.jwt_authn
|
||||
- "0"
|
||||
keys:
|
||||
- azp
|
||||
- aud
|
||||
ops:
|
||||
- take:
|
||||
head: 1
|
||||
apiVersion: extensions.istio.io/v1alpha1
|
||||
kind: WasmPlugin
|
||||
metadata:
|
||||
name: <threescale_wasm_plugin_name>
|
||||
spec:
|
||||
# ...
|
||||
services:
|
||||
# ...
|
||||
credentials:
|
||||
app_id:
|
||||
- filter:
|
||||
path:
|
||||
- envoy.filters.http.jwt_authn
|
||||
- "0"
|
||||
keys:
|
||||
- azp
|
||||
- aud
|
||||
ops:
|
||||
- take:
|
||||
head: 1
|
||||
# ...
|
||||
----
|
||||
|
||||
The example instructs the module to use the `filter` source type to look up filter metadata for an object from the `Envoy`-specific `JWT` authentication native plugin. This plugin includes the `JWT` token as part of a structure object with a single entry and a preconfigured name. Use `0` to specify that you will only access the single entry.
|
||||
@@ -219,17 +264,26 @@ To get the `app_id`, see the following example:
|
||||
|
||||
[source,yaml]
|
||||
----
|
||||
credentials:
|
||||
app_id:
|
||||
- header:
|
||||
keys:
|
||||
- x-jwt-payload
|
||||
ops:
|
||||
- base64_urlsafe
|
||||
- json:
|
||||
- keys:
|
||||
- azp
|
||||
- aud
|
||||
- take:
|
||||
head: 1
|
||||
apiVersion: extensions.istio.io/v1alpha1
|
||||
kind: WasmPlugin
|
||||
metadata:
|
||||
name: <threescale_wasm_plugin_name>
|
||||
spec:
|
||||
# ...
|
||||
services:
|
||||
# ...
|
||||
credentials:
|
||||
app_id:
|
||||
- header:
|
||||
keys:
|
||||
- x-jwt-payload
|
||||
ops:
|
||||
- base64_urlsafe
|
||||
- json:
|
||||
- keys:
|
||||
- azp
|
||||
- aud
|
||||
- take:
|
||||
head: 1
|
||||
# ,,,
|
||||
----
|
||||
|
||||
@@ -19,18 +19,17 @@ metadata:
|
||||
name: <threescale_wasm_plugin_name>
|
||||
spec:
|
||||
pluginConfig:
|
||||
...
|
||||
# ...
|
||||
services:
|
||||
- credentials:
|
||||
user_key:
|
||||
- <source_type>: <object>
|
||||
- <source_type>: <object>
|
||||
...
|
||||
# ...
|
||||
app_id:
|
||||
- <source_type>: <object>
|
||||
...
|
||||
# ...
|
||||
app_key:
|
||||
- <source_type>: <object>
|
||||
...
|
||||
...
|
||||
# ...
|
||||
----
|
||||
|
||||
@@ -53,7 +53,7 @@ metadata:
|
||||
name: <threescale_wasm_plugin_name>
|
||||
spec:
|
||||
pluginConfig:
|
||||
...
|
||||
# ...
|
||||
mapping_rules:
|
||||
- method: GET
|
||||
pattern: /
|
||||
@@ -72,7 +72,7 @@ spec:
|
||||
delta: 1
|
||||
- name: products
|
||||
delta: 1
|
||||
...
|
||||
# ...
|
||||
----
|
||||
|
||||
All `usages` get added to the request the module performs to 3scale with usage data as follows:
|
||||
|
||||
@@ -19,7 +19,7 @@ metadata:
|
||||
name: <threescale_wasm_plugin_name>
|
||||
spec:
|
||||
pluginConfig:
|
||||
...
|
||||
# ...
|
||||
services:
|
||||
- id: "2555417834789"
|
||||
token: service_token
|
||||
@@ -29,7 +29,7 @@ spec:
|
||||
- "0.0.0.0:8443"
|
||||
credentials: <object>
|
||||
mapping_rules: <object>
|
||||
...
|
||||
# ...
|
||||
----
|
||||
|
||||
Each element in the `services` array represents a 3scale service.
|
||||
|
||||
@@ -22,7 +22,7 @@ spec:
|
||||
upstream: <object>
|
||||
token: <my_account_token>
|
||||
ttl: 300
|
||||
...
|
||||
# ...
|
||||
----
|
||||
|
||||
.`system` object fields
|
||||
|
||||
@@ -14,7 +14,7 @@ upstream:
|
||||
name: outbound|443||multitenant.3scale.net
|
||||
url: "https://myaccount-admin.3scale.net/"
|
||||
timeout: 5000
|
||||
...
|
||||
# ...
|
||||
----
|
||||
|
||||
.`upstream` object fields
|
||||
|
||||
@@ -40,6 +40,11 @@ $ oc edit smcp <smcp_name>
|
||||
+
|
||||
[source,yaml]
|
||||
----
|
||||
apiVersion: maistra.io/v2
|
||||
kind: ServiceMeshControlPlane
|
||||
metadata:
|
||||
name: basic
|
||||
namespace: istio-system
|
||||
spec:
|
||||
proxy:
|
||||
accessLogging:
|
||||
|
||||
@@ -32,28 +32,28 @@ You view the Jaeger components under the {JaegerName} Operator and the Elasticse
|
||||
You can verify the {SMProductShortName} control plane installation in the {product-title} web console.
|
||||
|
||||
. Navigate to *Operators* -> *Installed Operators*.
|
||||
. Select the `<istio-system>` namespace.
|
||||
. Select the `istio-system` namespace.
|
||||
. Select the {SMProductName} Operator.
|
||||
.. Click the *Istio Service Mesh Control Plane* tab.
|
||||
.. Click the name of your control plane, for example `basic`.
|
||||
.. To view the resources created by the deployment, click the *Resources* tab. You can use the filter to narrow your view, for example, to check that all the *Pods* have a status of `running`.
|
||||
.. If the SMCP status indicates any problems, check the `status:` output in the YAML file for more information.
|
||||
.. Navigate back to *Operators* -> *Installed Operators*.
|
||||
|
||||
. Navigate back to *Operators* -> *Installed Operators*.
|
||||
. Select the OpenShift Elasticsearch Operator.
|
||||
.. Click the *Elasticsearch* tab.
|
||||
.. Click the name of the deployment, for example `elasticsearch`.
|
||||
.. To view the resources created by the deployment, click the *Resources* tab. .
|
||||
.. If the `Status` column any problems, check the `status:` output on the *YAML* tab for more information.
|
||||
.. Navigate back to *Operators* -> *Installed Operators*.
|
||||
|
||||
. Navigate back to *Operators* -> *Installed Operators*.
|
||||
. Select the {JaegerName} Operator.
|
||||
.. Click the *Jaeger* tab.
|
||||
.. Click the name of your deployment, for example `jaeger`.
|
||||
.. To view the resources created by the deployment, click the *Resources* tab.
|
||||
.. If the `Status` column indicates any problems, check the `status:` output on the *YAML* tab for more information.
|
||||
.. Navigate to *Operators* -> *Installed Operators*.
|
||||
|
||||
. Navigate to *Operators* -> *Installed Operators*.
|
||||
. Select the Kiali Operator.
|
||||
.. Click the *Istio Service Mesh Control Plane* tab.
|
||||
.. Click the name of your deployment, for example `kiali`.
|
||||
@@ -86,7 +86,7 @@ prometheus-5c579dfb-6qhjk 2/2 Running 0 115s
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc get smcp -n <istio-system>
|
||||
$ oc get smcp -n istio-system
|
||||
----
|
||||
+
|
||||
The installation has finished successfully when the STATUS column is `ComponentsReady`.
|
||||
@@ -126,7 +126,7 @@ $ oc describe smcp basic -n istio-system
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc get jaeger -n <istio-system>
|
||||
$ oc get jaeger -n istio-system
|
||||
----
|
||||
+
|
||||
.Example output
|
||||
@@ -140,7 +140,7 @@ jaeger Running 1.30.0 allinone memory 15m
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc get kiali -n <istio-system>
|
||||
$ oc get kiali -n istio-system
|
||||
----
|
||||
+
|
||||
.Example output
|
||||
|
||||
Reference in New Issue
Block a user