adding last stuff

Author: scott coulton

README.md

@@ -39,13 +39,16 @@ To run through the lab start [here](securing-our-pods/securing.md)
 
 ## Rbac, namespaces and cluster roles <a name="roles"></a>
 In this module we will take the application we deployed in pervious module but this time create a namespace and limit  
-the application to only have access to any resource in that namespace using service accounts, roles and role bindings.
+the application to only have access to any resource in that namespace using service accounts, roles and role bindings.  
 To run through the lab start [here](rbac-namespaces-cluterroles/namespaces.md)
 
 ## Introduction to knative <a name="knative"></a>
+In this module we will look at what makes up knative   
+To run through the lab start [here](introduction-into-knative/intro.md)
 
 ## Securing application communication with knative <a name="secknative"></a>
-
+In this module we will look at how to configure engress with istio  
+To run through the lab start [here](securing-application-communication-with-knative/intro.md)
 
 ### Instructors
 If you are giving this workshop there are some instructor notes [here](instructor-notes/notes.md)

introduction-into-knative/intro.md

@@ -1,2 +1,38 @@
 # Introduction into Knative
-![console](images/knative.svg)  
+
+In this module we will look at knative and its components.
+
+![console](images/knative.svg)  
+
+Knative is broken up into three major parts. 
+
+## Knative
+
+Knative extends Kubernetes to provide a set of middleware components that are essential to build modern, source-centric, and container-based applications that can run anywhere: on premises, in the cloud, or even in a third-party data center.
+
+Each of the components under the Knative project attempt to identify common patterns and codify the best practices that are shared by successful real-world Kubernetes-based frameworks and applications
+
+## Istio
+
+Cloud platforms provide a wealth of benefits for the organizations that use them. There’s no denying, however, that adopting the cloud can put strains on DevOps teams. Developers must use microservices to architect for portability, meanwhile operators are managing extremely large hybrid and multi-cloud deployments. Istio lets you connect, secure, control, and observe services.
+
+At a high level, Istio helps reduce the complexity of these deployments, and eases the strain on your development teams. It is a completely open source service mesh that layers transparently onto existing distributed applications. It is also a platform, including APIs that let it integrate into any logging platform, or telemetry or policy system. Istio’s diverse feature set lets you successfully, and efficiently, run a distributed microservice architecture, and provides a uniform way to secure, connect, and monitor microservices.
+
+Istio makes it easy to create a network of deployed services with load balancing, service-to-service authentication, monitoring, and more, without any changes in service code. You add Istio support to services by deploying a special sidecar proxy throughout your environment that intercepts all network communication between microservices, then configure and manage Istio using its control plane functionality, which includes:
+
+Automatic load balancing for HTTP, gRPC, WebSocket, and TCP traffic.
+
+Fine-grained control of traffic behavior with rich routing rules, retries, failovers, and fault injection.
+
+A pluggable policy layer and configuration API supporting access controls, rate limits and quotas.
+
+Automatic metrics, logs, and traces for all traffic within a cluster, including cluster ingress and egress.
+
+Secure service-to-service communication in a cluster with strong identity-based authentication and authorization.
+
+## Kubernetes
+
+We have already covered that :)
+
+Now we know that knatve and what it does we will use one of its components istio to to limit out bound traffic from our pods. 
+

securing-application-communication-with-knative/istio.md

@@ -0,0 +1,97 @@
+# Securing application communication with knative
+
+# Installing knative 
+
+To install knative run the following 
+
+### minikube
+```
+curl -L https://raw.githubusercontent.com/knative/serving/v0.2.0/third_party/istio-1.0.2/istio.yaml \
+          | sed 's/LoadBalancer/NodePort/' \
+            | kubectl apply --filename -
+kubectl label namespace default istio-injection=enabled
+curl -L https://github.com/knative/serving/releases/download/v0.2.0/release-lite.yaml \
+          | sed 's/LoadBalancer/NodePort/' \
+            | kubectl apply --filename -
+```
+
+### Play with kubernetes
+```
+kubectl apply --filename https://raw.githubusercontent.com/knative/serving/v0.2.2/third_party/istio-1.0.2/istio.yaml
+kubectl label namespace default istio-injection=enabled
+kubectl apply --filename https://github.com/knative/serving/releases/download/v0.2.2/release.yaml
+```
+
+# Configuring outbound network access
+
+Knative blocks all outbound traffic by default. To enable outbound access (when you want to connect 
+to the Cloud Storage API, for example), you need to change the scope of the proxy IP range by editing
+the `config-network` map.
+
+## Determining the IP scope of your cluster
+
+To set the correct scope, you need to determine the IP ranges of your cluster. The scope varies 
+depending on your platform:
+
+* For Minikube use `10.0.0.1/24`
+
+## Setting the IP scope  
+
+The `istio.sidecar.includeOutboundIPRanges` parameter in the `config-network` map specifies 
+the IP ranges that Istio sidecar intercepts. To allow outbound access, replace the default parameter  
+value with the IP ranges of your cluster.
+
+Run the following command to edit the `config-network` map:
+
+```shell
+kubectl edit configmap config-network --namespace knative-serving
+```
+
+Then, use an editor of your choice to change the `istio.sidecar.includeOutboundIPRanges` parameter value
+from `*` to the IP range you need. Separate multiple IP entries with a comma. For example: 
+
+```
+# Please edit the object below. Lines beginning with a '#' will be ignored,
+# and an empty file will abort the edit. If an error occurs while saving this file will be
+# reopened with the relevant failures.
+#
+apiVersion: v1
+data:
+  istio.sidecar.includeOutboundIPRanges: '10.16.0.0/14,10.19.240.0/20'
+kind: ConfigMap
+metadata:
+  ...
+```
+
+By default, the `istio.sidecar.includeOutboundIPRanges` parameter is set to `*`, 
+which means that Istio intercepts all traffic within the cluster as well as all traffic that is going 
+outside the cluster. Istio blocks all traffic that is going outside the cluster unless
+you create the necessary egress rules.
+
+When you set the parameter to a valid set of IP address ranges, Istio will no longer intercept 
+traffic that is going to the IP addresses outside the provided ranges, and you don't need to specify
+any egress rules.
+
+If you omit the parameter or set it to `''`, Knative uses the value of the `global.proxy.includeIPRanges` 
+parameter that is provided at Istio deployment time. In the default Knative Serving
+deployment, `global.proxy.includeIPRanges` value is set to `*`.
+
+If an invalid value is passed, `''` is used instead.
+
+If you are still having trouble making off-cluster calls, you can verify that the policy was
+applied to the pod running your service by checking the metadata on the pod.
+Verify that the `traffic.sidecar.istio.io/includeOutboundIPRanges` annotation matches the
+expected value from the config-map.
+
+```shell
+$ kubectl get pod ${POD_NAME} --output yaml
+
+apiVersion: v1
+kind: Pod
+metadata:
+  annotations:
+    serving.knative.dev/configurationGeneration: "2"
+    sidecar.istio.io/inject: "true"
+    ...
+    traffic.sidecar.istio.io/includeOutboundIPRanges: 10.16.0.0/14,10.19.240.0/20
+...