Rewrite training for Istiod and istio 1.6+ changes

[prune998]

Lots of rewrite.
Also migrate all the training on the Hipstershop application

[aditi-Kh]

@prune998, can we update the slides in the new brand theme: https://docs.google.com/presentation/d/12zL-Cl3YK_TAY6FFCz80JJesKvA4vzYB0uwYnK9ifq4/edit?

[ZackButcher]

Reviewing this incrementally, got through the intro and security parts. Continuing as I have time.

Looks great overall, I'm mostly just going through and doing a little clean up. @tetrateio/marketing can y'all help with proof reading throughout?

[ZackButcher]

nit: is there a reason we use hipstershopv1v2 throughout rather than hipstershop?

[prune998]

On the hipstershop app I've created many profiles... hipstershop is a "single version" install while hipstershopv1v2 will deploy some services with v1 and v2 names...
Of course, I can change that to only use hipstershop if you think it is easier...

[ZackButcher]

It might be helpful here to look quickly at the logs on Envoy, and turn up the RBAC logs (istioctl pc log <pod> --level rbac:debug).

It would show exactly what policy failed, for example. Not super useful in these exact cases, but can be helpful for users trying to debug more complex policies.

[prune998]

I added a lot more debug info there. Please review and comment. Maybe I put too much informations there... ?

[tialouden]

When do you need it done by?

…

On Tue, 11 Aug 2020 at 10:49 am, Zack Butcher ***@***.***> wrote: ***@***.**** commented on this pull request. Reviewing this incrementally, got through the intro and security parts. Continuing as I have time. Looks great overall, I'm mostly just going through and doing a little clean up. @tetrateio/marketing <https://github.com/orgs/tetrateio/teams/marketing> can y'all help with proof reading throughout? ------------------------------ In modules/install/README.md <#142 (comment)>: > @@ -8,6 +8,11 @@ This section covers initial cluster creation and the deployment of Istio and our If you want to skip all of that, you can use the abbreviated guide below to create and initialize a cluster that's ready to start the workshop. +## Needed tools + +stern ⬇️ Suggested change -stern +- [stern](https://github.com/wercker/stern/releases) ------------------------------ In modules/install/README.md <#142 (comment)>: > @@ -8,6 +8,11 @@ This section covers initial cluster creation and the deployment of Istio and our If you want to skip all of that, you can use the abbreviated guide below to create and initialize a cluster that's ready to start the workshop. +## Needed tools + +stern +kubectx/kubens ⬇️ Suggested change -kubectx/kubens +- [kubectx/kubens](https://github.com/ahmetb/kubectx#installation) ------------------------------ In modules/install/app/README.md <#142 (comment)>: > Let's deploy our entire microservices application. ```shell -cd training -kubectl apply -f modules/install/app/config +kubectl create namespace hipstershopv1v2 nit: is there a reason we use hipstershopv1v2 throughout rather than hipstershop? ------------------------------ In modules/observability/README.md <#142 (comment)>: > -metadata: - name: promhttp - namespace: istio-system -spec: - match: (context.protocol == "http" || context.protocol == "grpc") && - (match((request.useragent| "-"), "kube-probe*") == false) - actions: - - handler: prometheus - instances: - - requestcount.metric - - requestduration.metric - - requestsize.metric - - responsesize.metric -``` +--- +Next step: [Traffic Management](/modules/traffic) Thanks so much for adding these, makes navigation *so much* easier! ------------------------------ In modules/install/cluster/gcp.md <#142 (comment)>: > @@ -2,6 +2,7 @@ Kubernetes Cluster Access === For this, we'll be using a Kubernetes cluster in GKE that we control in cloud shell. We'll provide credentials and a cluster name that you can use. +Cluster must be K8s 1.15 or newer (1.16+ recommended) ⬇️ Suggested change -Cluster must be K8s 1.15 or newer (1.16+ recommended) +Your cluster must be K8s 1.15 or newer (1.16+ recommended) ------------------------------ In modules/security/ingress/README.md <#142 (comment)>: > ``` + Now the error changed. We have an `unknown CA`. + + This is perfectly true as we are using a self-signed certificate and `curl` is trying to validate it by default. We can test again using the `-k` option to skip the verrification: ⬇️ Suggested change - This is perfectly true as we are using a self-signed certificate and `curl` is trying to validate it by default. We can test again using the `-k` option to skip the verrification: + This is perfectly true as we are using a self-signed certificate and `curl` is trying to validate it by default. We can test again using the `-k` option to skip the verification: ------------------------------ In modules/security/mtls/README.md <#142 (comment)>: > @@ -1,94 +1,119 @@ Establish mTLS throughout the mesh ==== -Enable mTLS for service-to-service ----- +By default, Istio's mesh is automatically configure as `permissive`, which means Istio will use mTLS between workloads with a Sidecar and will revert to plain protocol (plaintext HTTP for example) if not. This is a great way to onboard new clusters and workload. ⬇️ Suggested change -By default, Istio's mesh is automatically configure as `permissive`, which means Istio will use mTLS between workloads with a Sidecar and will revert to plain protocol (plaintext HTTP for example) if not. This is a great way to onboard new clusters and workload. +By default, Istio's _authentication policy_, which controls mTLS, is automatically configure as `permissive`. This means Istio will use mTLS between workloads that both have a Sidecar and will revert to plaintext otherwise (HTTP instead of HTTPS, for example). This is a great way to onboard new clusters and workloads. ------------------------------ In modules/security/mtls/README.md <#142 (comment)>: > @@ -1,94 +1,119 @@ Establish mTLS throughout the mesh ==== -Enable mTLS for service-to-service ----- +By default, Istio's mesh is automatically configure as `permissive`, which means Istio will use mTLS between workloads with a Sidecar and will revert to plain protocol (plaintext HTTP for example) if not. This is a great way to onboard new clusters and workload. +Still, at some point, you're going to need to limit the non mTLS traffic. ⬇️ Suggested change -Still, at some point, you're going to need to limit the non mTLS traffic. +Permissive mode is not really secure because any client can request to downgrade to clear text - it exists only to help transition your mesh into mTLS without breaking existing applications. At some point, you're going to need to limit non-mTLS traffic. ------------------------------ In modules/security/mtls/README.md <#142 (comment)>: > -Apply strict policy ----- + You should get the full HTML page of the shop. + + +## Applying strict policy + +You can enable full-mesh mTLS by setting a global `PeerAuthentication` in the Istio ROOT namespace, `istio-system` by default: ⬇️ Suggested change -You can enable full-mesh mTLS by setting a global `PeerAuthentication` in the Istio ROOT namespace, `istio-system` by default: +You can disable permissive mode and enforce mTLS across the entire mesh by setting a global `PeerAuthentication` in the Istio ROOT namespace (`istio-system` by default): ------------------------------ In modules/security/mtls/README.md <#142 (comment)>: > curl: (56) Recv failure: Connection reset by peer command terminated with exit code 56 ``` - If everything worked correctly, we should see curl return an error code 56, indicating if failed to establish a TLS connection. + As you can see, we are now allowed to reach the `frontend` micro-service but we are still denied to reach others as our client can't enforce the required mTLS. + Note that this can't be considered a security mesure. We never denied traffic to go to the `adservice`. It's just that the `adservice` sidecar does not know us, and don't let us in. + + This is called Authentication (AuthN) and just ensure we all know each other before allowing to communicate. ⬇️ Suggested change - This is called Authentication (AuthN) and just ensure we all know each other before allowing to communicate. + This is called Authentication (AuthN) policy and ensures we all know each other before allowing communication. In other words, we use the certificates from Istio mutual TLS to identify services to each other in a verifiable way (i.e. we _authenticate_ them). ------------------------------ In modules/security/mtls/README.md <#142 (comment)>: > curl: (56) Recv failure: Connection reset by peer command terminated with exit code 56 ``` - If everything worked correctly, we should see curl return an error code 56, indicating if failed to establish a TLS connection. + As you can see, we are now allowed to reach the `frontend` micro-service but we are still denied to reach others as our client can't enforce the required mTLS. + Note that this can't be considered a security mesure. We never denied traffic to go to the `adservice`. It's just that the `adservice` sidecar does not know us, and don't let us in. + + This is called Authentication (AuthN) and just ensure we all know each other before allowing to communicate. + + In the next chapter we are going to dive into Authorization (AuthZ), where we set the rules deciding `who` can talk `to` who, and how (`when`). ⬇️ Suggested change - In the next chapter we are going to dive into Authorization (AuthZ), where we set the rules deciding `who` can talk `to` who, and how (`when`). + In the next chapter we are going to dive into Authorization (AuthZ), where we set the rules deciding `who` can talk `to` whom, and `when` they're allowed to. ------------------------------ In modules/security/rbac/README.md <#142 (comment)>: > @@ -1,99 +1,227 @@ -Istio RBAC for Service to Service Communication -=== +# Istio RBAC for Service to Service Communication ⬇️ Suggested change -# Istio RBAC for Service to Service Communication +# Istio Authorization for Service to Service Communication ------------------------------ In modules/security/rbac/README.md <#142 (comment)>: > @@ -1,99 +1,227 @@ -Istio RBAC for Service to Service Communication -=== +# Istio RBAC for Service to Service Communication + +Istio provides every workload with a strong identity - in Kubernetes, the pod's `ServiceAccount` is used to establish mTLS connections between services in the mesh. While establishing mTLS connections, sidecars in the mesh will validate certificates according to [SPIFFE's X.509 SVID spec](https://github.com/spiffe/spiffe/blob/master/standards/X509-SVID.md), which means that after the connection is established we have an authenticated identity of the other party. Then, Istio allows you to write access control policies using those identities to describe which services can communicate. ⬇️ Suggested change -Istio provides every workload with a strong identity - in Kubernetes, the pod's `ServiceAccount` is used to establish mTLS connections between services in the mesh. While establishing mTLS connections, sidecars in the mesh will validate certificates according to [SPIFFE's X.509 SVID spec](https://github.com/spiffe/spiffe/blob/master/standards/X509-SVID.md), which means that after the connection is established we have an authenticated identity of the other party. Then, Istio allows you to write access control policies using those identities to describe which services can communicate. +Istio provides every workload with a strong identity which is used to establish mTLS connections between services in the mesh. In Kubernetes, the workload's identity is the pod's `ServiceAccount`. While establishing mTLS connections, sidecars in the mesh will validate certificates according to [SPIFFE](https://github.com/spiffe/spiffe/blob/master/standards/X509-SVID.md), which means that after the connection is established we have the _authenticated principal_ of the other party. Then, Istio allows you to write access control policies using those identities to describe which services can communicate. ------------------------------ In modules/security/rbac/README.md <#142 (comment)>: > @@ -1,99 +1,227 @@ -Istio RBAC for Service to Service Communication -=== +# Istio RBAC for Service to Service Communication + +Istio provides every workload with a strong identity - in Kubernetes, the pod's `ServiceAccount` is used to establish mTLS connections between services in the mesh. While establishing mTLS connections, sidecars in the mesh will validate certificates according to [SPIFFE's X.509 SVID spec](https://github.com/spiffe/spiffe/blob/master/standards/X509-SVID.md), which means that after the connection is established we have an authenticated identity of the other party. Then, Istio allows you to write access control policies using those identities to describe which services can communicate. + +Note that it means that you have to enforce mTLS between your apps for the Authorization Policies to work. ⬇️ Suggested change -Note that it means that you have to enforce mTLS between your apps for the Authorization Policies to work. +Note that it means that you have to enforce mTLS between your apps for Authorization Policies to work. ------------------------------ In modules/security/rbac/README.md <#142 (comment)>: > @@ -1,99 +1,227 @@ -Istio RBAC for Service to Service Communication -=== +# Istio RBAC for Service to Service Communication + +Istio provides every workload with a strong identity - in Kubernetes, the pod's `ServiceAccount` is used to establish mTLS connections between services in the mesh. While establishing mTLS connections, sidecars in the mesh will validate certificates according to [SPIFFE's X.509 SVID spec](https://github.com/spiffe/spiffe/blob/master/standards/X509-SVID.md), which means that after the connection is established we have an authenticated identity of the other party. Then, Istio allows you to write access control policies using those identities to describe which services can communicate. + +Note that it means that you have to enforce mTLS between your apps for the Authorization Policies to work. + +## Setup a deny-all policy + ⬇️ Suggested change - +First, let's start by locking down our application: ------------------------------ In modules/security/rbac/README.md <#142 (comment)>: > + methods: + - GET +EOF +``` + +If you browser the Hipstershop store now, you can access the frontend. Sadly, you are still getting an error: + +```yaml +Uh, oh! +Something has failed. Below are some details for debugging. + +HTTP Status: 500 Internal Server Error +``` + +If we look at the logs of the `frontend` service, we can see we still have a DENY: `could not retrieve currencies: rpc error: code = PermissionDenied desc = RBAC: access denied` + It might be helpful here to look quickly at the logs on Envoy, and turn up the RBAC logs (istioctl pc log <pod> --level rbac:debug). It would show exactly what policy failed, for example. Not super useful in these exact cases, but can be helpful for users trying to debug more complex policies. ------------------------------ In modules/security/rbac/README.md <#142 (comment)>: > - A `Role` by itself doesn't do us any good, we have to assign the role to ourselves to get the permissions it lists. We'll do this by creating a `ServiceRoleBinding` which lets anyone see the UI: +Once mTLS is enforced, we can use Istio create RBAC policies to tontrol the traffic in the mesh. While this is powerfull, it may also lead to unattended traffic break. Plane, review and tests your rules before applying them in production. ⬇️ Suggested change -Once mTLS is enforced, we can use Istio create RBAC policies to tontrol the traffic in the mesh. While this is powerfull, it may also lead to unattended traffic break. Plane, review and tests your rules before applying them in production. +Once mTLS is enforced, we can use Istio create Authorization Policies to control the traffic in the mesh. While this is powerful, it may also lead to unintended traffic breaks. Plan, review and tests your rules before applying them in production! ------------------------------ In modules/security/rbac/README.md <#142 (comment)>: > @@ -1,99 +1,227 @@ -Istio RBAC for Service to Service Communication -=== +# Istio RBAC for Service to Service Communication can we rename the file too? — You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub <#142 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJHYUO5FFIZ7JKNJIFYWR4DSAGACRANCNFSM4PZ36KQQ> .

[ZackButcher]

Before the upcoming training with Freddie later this month - I'm not sure the exact dates.

[prune998]

Before the upcoming training with Freddie later this month - I'm not sure the exact dates.

Isn't freddie training only about TSB ?

I'll apply your review ASAP @ZackButcher
The goal would also to have 2/3 Tetrands with mixed istio knowledge go through the training from A to Z and make comments... I posted that in general slack channel but maybe someone should organize that.

[ZackButcher]

Ah good call - yes, so reviewing this is not urgent.