wording tweaks

slides/k8s/authn-authz.md

@@ -22,7 +22,7 @@
 
 - When the API server receives a request, it tries to authenticate it
 
-  (it examines headers, certificates ... anything available)
+  (it examines headers, certificates... anything available)
 
 - Many authentication methods are available and can be used simultaneously
 
@@ -34,7 +34,7 @@
   - the user ID
   - a list of groups
 
-- The API server doesn't interpret these; it'll be the job of *authorizers*
+- The API server doesn't interpret these; that'll be the job of *authorizers*
 
 ---
 
@@ -50,7 +50,7 @@
 
 - [HTTP basic auth](https://en.wikipedia.org/wiki/Basic_access_authentication)
 
-  (carrying user and password in a HTTP header)
+  (carrying user and password in an HTTP header)
 
 - Authentication proxy
 
@@ -88,7 +88,7 @@
 
   (i.e. they are not stored in etcd or anywhere else)
 
-- Users can be created (and given membership to groups) independently of the API
+- Users can be created (and added to groups) independently of the API
 
 - The Kubernetes API can be set up to use your custom CA to validate client certs
 
@@ -193,7 +193,7 @@ class: extra-details
 
   (the kind that you can view with `kubectl get secrets`)
 
-- Service accounts are generally used to grant permissions to applications, services ...
+- Service accounts are generally used to grant permissions to applications, services...
 
   (as opposed to humans)
 
@@ -217,7 +217,7 @@ class: extra-details
 
 .exercise[
 
-- The resource name is `serviceaccount` or `sa` in short:
+- The resource name is `serviceaccount` or `sa` for short:
   ```bash
   kubectl get sa
   ```
@@ -309,7 +309,7 @@ class: extra-details
 
 - The API "sees" us as a different user
 
-- But neither user has any right, so we can't do nothin'
+- But neither user has any rights, so we can't do nothin'
 
 - Let's change that!
 
@@ -339,9 +339,9 @@ class: extra-details
 
 - A rule is a combination of:
 
-  - [verbs](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb) like create, get, list, update, delete ...
+  - [verbs](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb) like create, get, list, update, delete...
 
-  - resources (as in "API resource", like pods, nodes, services ...)
+  - resources (as in "API resource," like pods, nodes, services...)
 
   - resource names (to specify e.g. one specific pod instead of all pods)
 
@@ -375,13 +375,13 @@ class: extra-details
 
 - We can also define API resources ClusterRole and ClusterRoleBinding
 
-- These are a superset, allowing to:
+- These are a superset, allowing us to:
 
   - specify actions on cluster-wide objects (like nodes)
 
   - operate across all namespaces
 
-- We can create Role and RoleBinding resources within a namespaces
+- We can create Role and RoleBinding resources within a namespace
 
 - ClusterRole and ClusterRoleBinding resources are global
 
@@ -389,13 +389,13 @@ class: extra-details
 
 ## Pods and service accounts
 
-- A pod can be associated to a service account
+- A pod can be associated with a service account
 
-  - by default, it is associated to the `default` service account
+  - by default, it is associated with the `default` service account
 
-  - as we've seen earlier, this service account has no permission anyway
+  - as we saw earlier, this service account has no permissions anyway
 
-- The associated token is exposed into the pod's filesystem
+- The associated token is exposed to the pod's filesystem
 
   (in `/var/run/secrets/kubernetes.io/serviceaccount/token`)
 
@@ -460,7 +460,7 @@ class: extra-details
 
 ]
 
-It's important to note a couple of details in these flags ...
+It's important to note a couple of details in these flags...
 
 ---
 
@@ -493,13 +493,13 @@ It's important to note a couple of details in these flags ...
 
   - again, the command would have worked fine (no error)
 
-  - ... but our API requests would have been denied later
+  - ...but our API requests would have been denied later
 
 - What's about the `default:` prefix?
 
   - that's the namespace of the service account
 
-  - yes, it could be inferred from context, but ... `kubectl` requires it
+  - yes, it could be inferred from context, but... `kubectl` requires it
 
 ---
 
@@ -590,7 +590,7 @@ class: extra-details
 
 *In many situations, these roles will be all you need.*
 
-*You can also customize them if needed!*
+*You can also customize them!*
 
 ---
 
@@ -652,7 +652,7 @@ class: extra-details
   kubectl describe clusterrolebinding cluster-admin
   ```
 
-- This binding associates `system:masters` to the cluster role `cluster-admin`
+- This binding associates `system:masters` with the cluster role `cluster-admin`
 
 - And the `cluster-admin` is, basically, `root`:
   ```bash
@@ -667,7 +667,7 @@ class: extra-details
 
 - For auditing purposes, sometimes we want to know who can perform an action
 
-- Here is a proof-of-concept tool by Aqua Security, doing exactly that:
+- There is a proof-of-concept tool by Aqua Security which does exactly that:
 
   https://github.com/aquasecurity/kubectl-who-can
 

slides/k8s/cni.md

@@ -489,8 +489,8 @@ What does that mean?
 
 - First, get the container ID, with `docker ps` or like this:
   ```bash
-  CID=$(docker ps
-        --filter label=io.kubernetes.pod.namespace=kube-system
+  CID=$(docker ps -q \
+        --filter label=io.kubernetes.pod.namespace=kube-system \
         --filter label=io.kubernetes.container.name=kube-router)
   ```
 

slides/k8s/csr-api.md

@@ -46,7 +46,7 @@
 
   (and vice versa)
 
-- If I use someone's public key to encrypt / decrypt their messages,
+- If I use someone's public key to encrypt/decrypt their messages,
   <br/>
   I can be certain that I am talking to them / they are talking to me
 
@@ -60,7 +60,7 @@ This is what I do if I want to obtain a certificate.
 
 1. Create public and private key.
 
-2. Create a Certificate Signing Request (CSR).
+2. Create a Certificate Signing Request (CSR) using this private key.
 
    (The CSR contains the identity that I claim and an expiration date.)
 
@@ -84,7 +84,7 @@ The CA (or anyone else) never needs to know my private key.
 
   (= upload a CSR to the Kubernetes API)
 
-- Then, using the Kubernetes API, we can approve / deny the request
+- Then, using the Kubernetes API, we can approve/deny the request
 
 - If we approve the request, the Kubernetes API generates a certificate
 
@@ -122,7 +122,7 @@ The CA (or anyone else) never needs to know my private key.
 
 - Users can then retrieve their certificate from their CSR object
 
-- ... And use that certificate for subsequent interactions
+- ...And use that certificate for subsequent interactions
 
 ---
 
@@ -387,7 +387,7 @@ The command above generates:
 
 ## What's missing?
 
-We shown, step by step, a method to issue short-lived certificates for users.
+We have just shown, step by step, a method to issue short-lived certificates for users.
 
 To be usable in real environments, we would need to add:
 
@@ -417,7 +417,7 @@ To be usable in real environments, we would need to add:
 
 - This provides enhanced security:
 
-  - the long-term credentials can use long passphrases, 2FA, HSM ...
+  - the long-term credentials can use long passphrases, 2FA, HSM...
 
   - the short-term credentials are more convenient to use
 

slides/k8s/kubercoins.md

@@ -209,7 +209,7 @@ https://@@GITREPO@@/blob/8279a3bce9398f7c1a53bdd95187c53eda4e6435/dockercoins/wo
 
 ## Our application at work
 
-- We can check the logs our application pods
+- We can check the logs of our application's pods
 
 .exercise[
 

slides/k8s/logs-centralized.md

@@ -73,12 +73,12 @@ and a few roles and role bindings (to give fluentd the required permissions).
 
 - Fluentd runs on each node (thanks to a daemon set)
 
-- It binds-mounts `/var/log/containers` from the host (to access these files)
+- It bind-mounts `/var/log/containers` from the host (to access these files)
 
 - It continuously scans this directory for new files; reads them; parses them
 
 - Each log line becomes a JSON object, fully annotated with extra information:
-  <br/>container id, pod name, Kubernetes labels ...
+  <br/>container id, pod name, Kubernetes labels...
 
 - These JSON objects are stored in ElasticSearch
 

slides/k8s/logs-cli.md

@@ -1,6 +1,6 @@
 # Accessing logs from the CLI
 
-- The `kubectl logs` commands has limitations:
+- The `kubectl logs` command has limitations:
 
   - it cannot stream logs from multiple pods at a time
 
@@ -12,7 +12,7 @@
 
 ## Doing it manually
 
-- We *could* (if we were so inclined), write a program or script that would:
+- We *could* (if we were so inclined) write a program or script that would:
 
   - take a selector as an argument
 
@@ -72,11 +72,11 @@ Exactly what we need!
 
 ## Using Stern
 
-- There are two ways to specify the pods for which we want to see the logs:
+- There are two ways to specify the pods whose logs we want to see:
 
   - `-l` followed by a selector expression (like with many `kubectl` commands)
 
-  - with a "pod query", i.e. a regex used to match pod names
+  - with a "pod query," i.e. a regex used to match pod names
 
 - These two ways can be combined if necessary
 

slides/shared/sampleapp.md

@@ -80,7 +80,7 @@ and displays aggregated logs.
 
 - DockerCoins is *not* a cryptocurrency
 
-  (the only common points are "randomness", "hashing", and "coins" in the name)
+  (the only common points are "randomness," "hashing," and "coins" in the name)
 
 ---