diff --git a/slides/k8s/authn-authz.md b/slides/k8s/authn-authz.md index 30c77d3c..a2c0c431 100644 --- a/slides/k8s/authn-authz.md +++ b/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 diff --git a/slides/k8s/cni.md b/slides/k8s/cni.md index 78ef9f06..3970f119 100644 --- a/slides/k8s/cni.md +++ b/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) ``` diff --git a/slides/k8s/csr-api.md b/slides/k8s/csr-api.md index aec66fdc..f0ea0d59 100644 --- a/slides/k8s/csr-api.md +++ b/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,
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 diff --git a/slides/k8s/kubercoins.md b/slides/k8s/kubercoins.md index 4d05f031..3220f5fa 100644 --- a/slides/k8s/kubercoins.md +++ b/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[ diff --git a/slides/k8s/logs-centralized.md b/slides/k8s/logs-centralized.md index 6cdddda8..07af0ce3 100644 --- a/slides/k8s/logs-centralized.md +++ b/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: -
container id, pod name, Kubernetes labels ... +
container id, pod name, Kubernetes labels... - These JSON objects are stored in ElasticSearch diff --git a/slides/k8s/logs-cli.md b/slides/k8s/logs-cli.md index aa7ffdc2..fe12f466 100644 --- a/slides/k8s/logs-cli.md +++ b/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 diff --git a/slides/shared/sampleapp.md b/slides/shared/sampleapp.md index 8b001b4c..0636d2de 100644 --- a/slides/shared/sampleapp.md +++ b/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) ---