github/container.training
1
0
Fork 0
mirror of https://github.com/jpetazzo/container.training.git synced 2026-07-28 17:21:11 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'master' into kadm-2019-06

Browse Source
This commit is contained in:
Jerome Petazzoni
2019-06-09 18:17:18 -05:00
parent ad1c32bd7f 8492524798
commit 8b5f105448
7 changed files with 37 additions and 37 deletions
Download Patch File Download Diff File Expand all files Collapse all files

42
slides/k8s/authn-authz.md
View File

@@ -22,7 +22,7 @@
- When the API server receives a request, it tries to authenticate it - 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 - Many authentication methods are available and can be used simultaneously
@@ -34,7 +34,7 @@
- the user ID - the user ID
- a list of groups - 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) - [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 - Authentication proxy
@@ -88,7 +88,7 @@
(i.e. they are not stored in etcd or anywhere else) (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 - 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`) (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) (as opposed to humans)
@@ -217,7 +217,7 @@ class: extra-details
.exercise[ .exercise[
- The resource name is `serviceaccount` or `sa` in short: - The resource name is `serviceaccount` or `sa` for short:
```bash ```bash
kubectl get sa kubectl get sa
``` ```
@@ -309,7 +309,7 @@ class: extra-details
- The API "sees" us as a different user - 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! - Let's change that!
@@ -339,9 +339,9 @@ class: extra-details
- A rule is a combination of: - 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) - 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 - 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) - specify actions on cluster-wide objects (like nodes)
- operate across all namespaces - 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 - ClusterRole and ClusterRoleBinding resources are global
@@ -389,13 +389,13 @@ class: extra-details
## Pods and service accounts ## 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`) (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) - 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? - What's about the `default:` prefix?
- that's the namespace of the service account - 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.* *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 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`: - And the `cluster-admin` is, basically, `root`:
```bash ```bash
@@ -667,7 +667,7 @@ class: extra-details
- For auditing purposes, sometimes we want to know who can perform an action - 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 https://github.com/aquasecurity/kubectl-who-can

4
slides/k8s/cni.md
View File

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

12
slides/k8s/csr-api.md
View File

@@ -46,7 +46,7 @@
(and vice versa) (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/> <br/>
I can be certain that I am talking to them / they are talking to me I can be certain that I am talking to them / they are talking to me
@@ -58,7 +58,7 @@
This is what I do if I want to obtain a certificate. This is what I do if I want to obtain a certificate.
1. Create public and private key. 1. Create public and private keys.
2. Create a Certificate Signing Request (CSR). 2. Create a Certificate Signing Request (CSR).
@@ -84,7 +84,7 @@ The CA (or anyone else) never needs to know my private key.
(= upload a CSR to the Kubernetes API) (= 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 - 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 - 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? ## 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: 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: - 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 - the short-term credentials are more convenient to use

2
slides/k8s/kubercoins.md
View File

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

4
slides/k8s/logs-centralized.md
View File

@@ -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) - 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 - It continuously scans this directory for new files; reads them; parses them
- Each log line becomes a JSON object, fully annotated with extra information: - 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 - These JSON objects are stored in ElasticSearch

8
slides/k8s/logs-cli.md
View File

@@ -1,6 +1,6 @@
# Accessing logs from the CLI # 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 - it cannot stream logs from multiple pods at a time
@@ -12,7 +12,7 @@
## Doing it manually ## 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 - take a selector as an argument
@@ -72,11 +72,11 @@ Exactly what we need!
## Using Stern ## 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) - `-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 - These two ways can be combined if necessary

2
slides/shared/sampleapp.md
View File

@@ -80,7 +80,7 @@ and displays aggregated logs.
- DockerCoins is *not* a cryptocurrency - 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)
--- ---