I watched all the security talks at KubeCon NA 2020. This is what I learned

### PK with Tabitha Sable Link: [https://kccncna20.sched.com/event/ekES/pki-the-wrong-way-simple-tls-mistakes-and-surprising-consequences-tabitha-sable-datadog](https://kccncna20.sched.com/event/ekES/pki-the-wrong-way-simple-tls-mistakes-and-surprising-consequences-tabitha-sable-datadog) - Certificate with the `O` value set to `system:masters` is great to pillage, because it is available even if the cert is deleted - Demo of Privilege Escalation with Vault misconfiguration - especially with CA Access Control - Etcd Pillaging with PKI compromise because Etcd relies on the API Server Cert ⇒ Really cool exploit - etcd RBAC makes this attacker harder to do - grant user with etcd - root role with no password ⇒ restrict access to only the api server. The objective is to bind access only to the Kubernetes API Server - **Prevention:** - Separate PKI for etcd and k8s - Network Policy - etcd Authorization ⇒ Relatively uncommon - RequestAuth Proxy Rowdiness ⇒ Essentially trying to masquerade as a Proxy Server to be able to bypass auth checks by declaring that I am an "admin" - Prevention: - Separate PKI with Strict Access Control - Pass All RequestHeader Args - Pass No requestheader args: Proxy/Extension API Servers wont autoconfigure - PKI Chain Attacks - Basically if the ClusterCA has been signed by the same root cert (with an intermediate cert), then we can submit certs from any signed cert even from a different cluster (but signed with the same cert) - `PermissionDenied` still means that the cert was accepted but the user is not, which can still be gotten around with `x-remote-user` - Prevention - Standalone CAs - If you need to use chained CAs, then only trust the Leaf CA - tight CA Permissions - Set `client-auth` and `server-auth` cert flags - etcd authentication Talk Mitigations - 3 Separate CAs per cluster - Use Standalone CAs ### Using OPA to meet Evolving Policy Requirements - Jeremy Rickard Link: [https://kccncna20.sched.com/event/ekEP/using-open-policy-agent-to-meet-evolving-policy-requirements-jeremy-rickard-vmware](https://kccncna20.sched.com/event/ekEP/using-open-policy-agent-to-meet-evolving-policy-requirements-jeremy-rickard-vmware) - Multi-tenant clusters that they ran for SaaS teams with RBAC - Moved to Dedicated Clusters - Entirely on AWS - RBAC wasnt meeting their requirements - Hence, Mutating and Validating Webhooks: - Mutating ⇒ Adds Sidecar pod, labels, etc - Requirements: - PCI - FedRAMP ⇒ 400 odd controls - (and Dedicated clusters) - They went with the concept of "Policies per cluster" - Because there are specific security controls for each of these tenants/clusters - Other Requirements: - Something that doesn't require new "code" - Easy for the team to learn - Testable - They went with `kube-mgmt` instead of Gatekeeper - because it was early days for Gatekeeper - Gatekeeper still doesn't support `MutatingWebhook` . Its coming soon - OPA's `patch` function allows you to mutate - Interesting Use-cases for Container Scanning and then validating severity values with OPA - They've used `kube-mgmt` as a Mutating Webhook with OPA `patch()` calls ### Seccomp - What it can do for you? Link: [https://kccncna20.sched.com/event/ekEJ/seccomp-what-can-it-do-for-you-justin-cormack-docker](https://kccncna20.sched.com/event/ekEJ/seccomp-what-can-it-do-for-you-justin-cormack-docker) - Initially it was only used for processes that `read, write` , `exit` and `sigreturn` - Rarely used until BPF entered the scene - Syscalls ⇒ Interface between the App and Kernel - Can only make decisions based on syscalls, and not only files. You can't follow pointers - Cannot inspect a file descriptor like a network connection or a local file - Kubernetes Implementation for seccomp: - You have to add it to context in Kube 1.19 - Else you can use RuntimeDefault - for something like Docker (to get the seccomp profile of the underlying runtime) - Seccomp in OCI ⇒ JSON ⇒ JSON ⇒ Go (libseccomp) ⇒ C ⇒ BPF - Linux kernels have syscalls that have large attack surface ⇒ `perf_event_open, etc` - They can also disable security features ⇒ `ADDR_NO_RANDOMIZE` which disables ASLR - Syscalls are Allowlisted and not blocklisted. So the list of syscalls are really long - List is long and it has an IO Perf issues for certain types of application - Kubernetes by default automatically disables Docker seccomp Options: - Don't use it - Smaller blocklists - May be push it to runtime? - gVisor ⇒ Interesting implementing much of Linux in Go and intercepting syscalls. But very successful security cut-off

Видео I watched all the security talks at KubeCon NA 2020. This is what I learned автора PythonMagic