openshift · JStickler · Jul 22, 2020 · Jul 10, 2020
diff --git a/modules/ossm-document-attributes.adoc b/modules/ossm-document-attributes.adoc
@@ -12,7 +12,7 @@
 :ProductName: Red Hat OpenShift Service Mesh
 :ProductShortName: Service Mesh
 :ProductRelease:
-:ProductVersion: 1.1.4
+:ProductVersion: 1.1.5
 :MaistraVersion: 1.1
 :product-build:
 :DownloadURL: registry.redhat.io

diff --git a/modules/ossm-rn-fixed-issues.adoc b/modules/ossm-rn-fixed-issues.adoc
@@ -32,6 +32,12 @@ $ oc delete crd orders.certmanager.k8s.io
 $ oc delete crd challenges.certmanager.k8s.io
 ----
 
+* link:https://issues.redhat.com/projects/MAISTRA/issues/MAISTRA-1649[MAISTRA-1649] Headless services conflict when in different namespaces. When deploying headless services within different namespaces the endpoint configuration is merged and results in invalid Envoy configurations being pushed to the sidecars.
+
+* link:https://issues.redhat.com/browse/MAISTRA-1541[MAISTRA-1541] Panic in kubernetesenv when the controller is not set on owner reference. If a pod has an ownerReference which does not specify the controller, this will cause a panic within the `kubernetesenv cache.go` code.
+
+* link:https://issues.redhat.com/browse/TRACING-1300[TRACING-1300] Failed connection between Agent and Collector when using Istio sidecar. An update of the Jaeger Operator enabled TLS communication by default between a Jaeger sidecar agent and the Jaeger Collector.
+
 * link:https://issues.redhat.com/browse/TRACING-1208[TRACING-1208] Authentication "500 Internal Error" when accessing Jaeger UI. When trying to authenticate to the UI using OAuth, I get a 500 error because oauth-proxy sidecar doesn't trust the custom CA bundle defined at installation time with the additionalTrustBundle.
 
 * link:https://issues.jboss.org/browse/OSSM-99[OSSM-99] Workloads generated from direct Pod without labels may crash Kiali.

diff --git a/modules/ossm-rn-new-features.adoc b/modules/ossm-rn-new-features.adoc
@@ -35,6 +35,10 @@ Result – If changed, describe the current user experience
 |1.0.0
 |===
 
+== New features {ProductName} 1.1.5
+
+This release of {ProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes.
+
 == New features {ProductName} 1.1.4
 
 This release of {ProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes.

diff --git a/modules/ossm-security-mtls.adoc b/modules/ossm-security-mtls.adoc
@@ -13,7 +13,7 @@ By default, {ProductName} is set to permissive mode, where the sidecars in {Prod
 
 == Enabling strict mTLS across the mesh
 
-If your workloads do not communicate with services outside your mesh and communication will not be interrupted by only accepting encrypted connections, you can enable mTLS across your mesh quickly. Set `spec.istio.global.mtls.enabled` to `true` in your ServiceMeshControlPlane resource. The operator creates the required resources.
+If your workloads do not communicate with services outside your mesh and communication will not be interrupted by only accepting encrypted connections, you can enable mTLS across your mesh quickly. Set `spec.istio.global.mtls.enabled` to `true` in your `ServiceMeshControlPlane` resource. The operator creates the required resources.
 
 [source,yaml]
 ----
@@ -61,3 +61,41 @@ spec:
     tls:
       mode: ISTIO_MUTUAL
 ----
+
+[id="ossm-security-min-max-tls_{context}"]
+== Setting the minimum and maximum protocol versions
+
+If your environment has specific requirements for encrypted traffic in your service mesh, you can control the cryptographic functions that are allowed by setting the `spec.istio.global.tls.minProtocolVersion` or `spec.istio.global.tls.maxProtocolVersion` in your `ServiceMeshControlPlane` resource. Those values, configured in your control plane resource, define the minimum and maximum TLS version used by mesh components when communicating securely over TLS.
+
+[source,yaml]
+----
+apiVersion: maistra.io/v1
+kind: ServiceMeshControlPlane
+spec:
+  istio:
+    global:
+      tls:
+        minProtocolversion: TLSv1_0
+----
+
+The valid values correspond to TLS versions. The default is `auto` and does not specify a version of TLS.
+
+.Valid values
+|===
+|Value|Description
+
+| `TLS_AUTO`
+| default
+
+|`TLSv1_0`
+|TLS version 1.0
+
+|`TLSv1_1`
+|TLS version 1.1
+
+|`TLSv1_2`
+|TLS version 1.2
+
+|`TLSv1_3`
+|TLS version 1.3
+|===
diff --git a/modules/ossm-sidecar-injection.adoc b/modules/ossm-sidecar-injection.adoc
@@ -13,3 +13,25 @@ The upstream version of Istio injects the sidecar by default if you have labeled
 
 The webhook checks the configuration of pods deploying into all projects to see if they are opting in to injection with the appropriate annotation.
 ====
+
+[id="ossm-sidecar-injection-env-var_{context}"]
+== Setting environment variables on the proxy in applications through annotations
+
+You can set environment variables on the sidecar proxy for applications by adding pod annotations in the deployment in the `injection-template.yaml` file. The environment variables are injected to the sidecar.
+
+[source,yaml]
+----
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: resource
+spec:
+  replicas: 7
+  selector:
+    matchLabels:
+      app: resource
+  template:
+    metadata:
+      annotations:
+        sidecar.maistra.io/proxyEnv: "{ \"maistra_test_env\": \"env_value\", \"maistra_test_env_2\": \"env_value_2\" }"
+----
diff --git a/modules/ossm-vs-istio.adoc b/modules/ossm-vs-istio.adoc
@@ -90,7 +90,30 @@ spec:
 
 {ProductName} includes CNI plug-in, which provides you with an alternate way to configure application pod networking. The CNI plug-in replaces the `init-container` network configuration eliminating the need to grant service accounts and projects access to Security Context Constraints (SCCs) with elevated privileges.
 
+The Istio CNI plugin is enabled through Multus CNI. The Istio operator creates a
+`NetworkAttachmentDefinition` object in each project that is part of the mesh.
+This object is referenced in the `k8s.v1.cni.cncf.io/networks` annotation, which
+is added to a pod during injection.
+
+== Using Istio CNI with other Multus CNI plugins
+
+By default, if a pod contains an existing `k8s.v1.cni.cncf.io/networks` annotation, such as when using Multus CNI to add a macvlan network to the pod, the value of the annotation is overwritten. To preserve the value and instead append Istio CNI to the end, the field `spec.istio.sidecarInjectorWebhook.injectPodRedirectAnnot` must be set to `true` in the `ServiceMeshControlPlane` object as shown in the following example.
+
+----
+kind: ServiceMeshControlPlane
+...
+spec:
+  istio:
+    sidecarInjectorWebhook:
+      injectPodRedirectAnnot: true
+...
+----
+
+The link:https://intel.github.io/multus-cni/doc/how-to-use.html#lauch-pod-with-json-annotation[JSON form] support was
+introduced in {ProductName} version 1.1.5. In previous {ProductName} versions, only the link:https://intel.github.io/multus-cni/doc/how-to-use.html#lauch-pod-with-text-annotation-with-interface-name[text form]
+of the `k8s.v1.cni.cncf.io/networks` annotation was supported.
+
 = Envoy, Secret Discovery Service, and Certificates
 
 * {ProductName} does not support QUIC-based services. 
-* Deployment of TLS certificates using the Secret Discovery Service (SDS) functionality of Istio is not currently supported in {ProductName}. The Istio implementation depends on a nodeagent container that uses hostPath mounts.
+* Deployment of TLS certificates using the Secret Discovery Service (SDS) functionality of Istio is not currently supported in {ProductName}. The Istio implementation depends on a nodeagent container that uses hostPath mounts.