[HN Gopher] Attack Matrix for Kubernetes
___________________________________________________________________
Attack Matrix for Kubernetes
Author : based2
Score : 231 points
Date : 2020-04-09 20:14 UTC (2 days ago)
(HTM) web link (www.microsoft.com)
(TXT) w3m dump (www.microsoft.com)
| freehunter wrote:
| We use the MITRE ATT&CK framework at my infosec consulting
| company quite heavily. It's the structure we use to define
| security content, allowing us to use the same language with our
| clients that auditors do, and allowing us to use the same
| language between customers to assess client- or industry-specific
| threats across all of our customers.
|
| Having a high level framework to discuss threat helps, but so
| does the process of laying out all the possible threats. It's a
| kind of checklist, have I secured this properly? Have I thought
| about all the attack vectors?
|
| I hope these MITRE-style attack matrices catch on more.
| kitotik wrote:
| The whole industry seems to be standardizing around it. It is
| quite awesome.
|
| The main problem I'm already seeing is CXOs treating it like a
| checklist/dashboard, which of course is futile as it's meant to
| be prioritized similar to a product backlog.
| speculator wrote:
| I agree. The real value comes from incremental improvements
| in each area and measuring these improvements over time.
| Unfortunately, vast majority of security leadership don't
| think in terms of incremental improvements or product
| backlog.
| tmpz22 wrote:
| Is it better to conform natural human mental models to
| security practices or to conform security practices to
| natural human mental models?
| jsty wrote:
| > the MITRE ATT&CK framework
|
| This looks incredibly useful, thanks for pointing it out
|
| For anyone else who's curious: https://attack.mitre.org/
| whycombagator wrote:
| MITRE ATT&CK is mentioned in the article 4x and the article
| itself is about Microsoft developing a similar matrix for
| K8s.
| wronglebowski wrote:
| I was planning to do a "Show HN" but this seems like an
| appropriate time. I work on a free product called VECTR which
| is built to use the MITRE framework.
|
| https://github.com/SecurityRiskAdvisors/VECTR
|
| If you have an interest in being able to track your purple
| team results I highly recommend it.
| unixhero wrote:
| Post it as a "Show HN" as well, this project needs the
| proper publicity and stimulated discussions from HN.
| techwizrd wrote:
| I work for MITRE (though not on ATT&CK), and it's very
| surprising to see it pop up on HN outside of CVE links. Very
| cool!
| jrockway wrote:
| Another thing to be mindful of is the service account token that
| each pod gets. While these rarely have access to the entire
| cluster, it is relatively easy to configure an application to
| bridge HTTP requests to the API server, which would be a minor
| disaster. (I noticed this while writing a small Envoy control
| plane. Everything exists in my config format to pick up the TLS
| certificates that the Envoy pod already has to create a backend
| that points to your API server, automatically giving any HTTP
| requests routed to that backend the credentials of the Envoy pod
| itself. Add a route in the route table, and now you have a
| publicly-available route to your API server. You would have to go
| out of your way to do this, but it's something to keep in mind --
| pods have more privileges than just "run the program in the
| container".)
| chvid wrote:
| Openshift sells itself as a more secure Kubernetes ... anyone
| knows how much of this it mitigates?
| meddlepal wrote:
| OpenShift has way more scope (read: surface area) than
| Kubernetes... I'm skeptical.
| pat2man wrote:
| Sure but a lot of that scope is regularly added on to
| kubernetes clusters (metrics, logging, etc) so unless you
| keep your cluster super lean you will end up with a large
| attach surface anyway.
| jrockway wrote:
| Logging agents don't need to talk to the control plane, so
| shouldn't be able to compromise it. In the case of a per-
| machine log collector ("DaemonSet"), it just reads files in
| a particular location that your container runtime writes.
| In the case of per-pod log collectors ("sidecars"), no
| special privileges are needed. (Your application just opens
| a network connection inside the pod network; the 127.0.0.1
| address that you write log data to doesn't even exist
| outside the pod.)
|
| Prometheus does talk to the control plane, but via a
| service account that only has read and list permissions, so
| shouldn't be able to compromise it. The truly paranoid
| could have static configurations (scrape
| foo.bar.svc.cluster.local:1234, not "foreach pod, scape
| $POD_ID:1234"), but if reading/listing pods can compromise
| the control plane, that would probably be a P0 security bug
| in Kubernetes.
|
| Obviously, anything running in your cluster has the
| potential to exploit a kernel bug to read files on the node
| that it shouldn't have access to, including other service
| accounts. The guidance there should be to be careful about
| what permissions you grant any application.
| cpitman wrote:
| Let me take a stab at this, as a Red Hat architect that spends
| a lot of time on OpenShift(OCP) implementations:
|
| OpenShift _helps_ mitigate the following, by providing secure
| defaults. It is totally possible for someone (a cluster level
| admin) to un-configure these security controls, so keep that in
| mind.
|
| These are partially mitigated by Red Hat providing trusted
| image content and having a well oiled machine for patching/CVE
| response:
|
| * Compromised images in registry (use Red Hat base images, and
| in-cluster source or docker builds to lock down registry
| access. Registry not exposed by default.) * Application
| vulnerability/Application exploit (again, Red Hat base images
| for runtime, regularly patched by Red Hat. Images have to run
| as non-root user. Doesn't solve self-created app
| vulnerabilities)
|
| These are mitigated by OCP's locked down default RBAC:
|
| * Writable host-path (host-path locked down by default. Not
| sure why host-path is special here though, seems like any PV
| could be used for persistence) * Privileged container (also
| locked down, admin must enable for a user/service account) *
| host-path mount (specifically for getting access to the file
| system, OCP locks down this via RBAC by default. Layer on
| SELinux to prevent an escalation from allowing file-system
| access) * list kubernetes secrets (RBAC to limit scope, and
| additionally a node can only access secrets for pods scheduled
| to it, in case node is exploited) * access container service-
| account (default service-account has pretty limited
| permissions) * access Kubernetes dashboard (containers have no
| special access to the console, which requires auth)
|
| These are just miscellaneous config/security controls:
|
| * Exposed dashboard (OCP console has authentication by default,
| no default passwords) * clear container-logs (built in log
| aggregation would require an additional exploit to defeat) *
| cluster internal networking (depends on the sdn plugin, but
| most installs limit networking to containers in the same
| namespace by default) * access tiller endpoint (No Helm 2,
| support for Helm 3 without tiller coming soon. Driven by tiller
| security/RBAC concerns)
| chrisfosterelli wrote:
| I haven't administered an OpenShift cluster but I've used one
| and you notice the difference in policy approach. OpenShift
| seems to have a lot of default policies that are more
| aggressive than Kubernetes. A lot of container images from
| Docker Hub just don't run at all on OpenShift without
| modification due to this.
|
| The biggest thing is that they don't allow containers to run as
| root, but they also have other features like blocking hostPath
| mounts and offering SELinux integration. Nearly all of this can
| be turned off (if you have permissions to do that in the RBAC)
| but they generally take the "secure by default" approach.
| freedomben wrote:
| Correct. OpenShift by default will start your container with
| a "random" UID (it's not technically random but to a user it
| will feel that way), so not only is root disallowed but you
| also can't anticipate being any specific user. This can feel
| annoying at times but has important implications for running
| on the host. you can read more here if interested:
| https://cookbook.openshift.org/users-and-role-based-
| access-c...
|
| OpenShift also moves to CRI-O and rootless containers in
| later version, which further protects hosts.
| pat2man wrote:
| OpenShift also has some features that help with known attacks
| (easy cluster upgrades, image vulnerability scanning, etc).
| Alukart wrote:
| thewayofmph@gmail.com
| Svip wrote:
| Is it Hacker News that re-edits the headlines? At first I thought
| the headline meant "attack Matrix", i.e. matrix.org, for the
| purpose of helping Kubernetes. Like a call to arms. But then it
| made little sense to me that the origin domain was microsoft.com.
| Man, capitalisation really matters, I guess.
| [deleted]
| Legogris wrote:
| Duplicate of
|
| https://news.ycombinator.com/item?id=22772179
|
| https://news.ycombinator.com/item?id=22784713
|
| https://news.ycombinator.com/item?id=22834195
|
| (Reposting is all good when things get buried, but this is the
| third time I see this on the top front page with no comments)
| empath75 wrote:
| It all the other kubernetes admins are like me, they
| immediately had a panic attack and started writing up Jira
| tickets instead of commenting.
| rvz wrote:
| Well now this lucky poster finally has a discussion around it
| and all the duplicates you posted still have no comments. Only
| links to the same article with no discussion which isn't useful
| as a 'duplicate'.
| merricksb wrote:
| All the submissions are by different people, all of whom have a
| very solid history on HN.
|
| So it doesn't count as self-promotion or manipulation.
|
| It just seems to be an article that multiple users found
| interesting, but that has fallen through the cracks so far.
___________________________________________________________________
(page generated 2020-04-11 23:00 UTC)