Hacker News Reader

Comment by beprogrammed | Hacker News Reader

- Scan containers and Pods for vulnerabilities or misconfigurations.

- Run containers and Pods with the least privileges possible.

- Use network separation to control the amount of damage a compromise can cause.

- Use firewalls to limit unneeded network connectivity and encryption to protect confidentiality.

- Use strong authentication and authorization to limit user and administrator access as well as to limit the attack surface.

- Use log auditing so that administrators can monitor activity and be alerted to potential malicious activity.

- Periodically review all Kubernetes settings and use vulnerability scans to help ensure risks are appropriately accounted for and security patches are applied.

View on HN

> and encryption to protect confidentiality

Probably the hardest part about this. Private networks with private domains. Who runs the private CA, updates DNS records, issues certs, revokes, keeps the keys secure, embeds the keychain in every container's cert stack, and enforces validation?

That is a shit-ton of stuff to set up (and potentially screw up) which will take a small team probably months to complete. How many teams are actually going to do this, versus just terminating at the load balancer and everything in the cluster running plaintext?

> That is a shit-ton of stuff to set up (and potentially screw up) which will take a small team probably months to complete.

Agree! This is why that "Kubernetes Hardening Guidance" is for NSA, not for startups.

Resource needs aside, keeping basic AppSec/InfoSec hygiene is a strong recommendation. Also there are tons of startups that are trying to provide solutions/services to solve that also. A lot of times, it's worth the money.

I wonder about that. What are the attack vectors within a K8s cluster to necessitate inter-cluster transport encryption?

Most (but not all) overlay networks are implemented in kernel. If you compromise one node in a cluster, you can fairly trivially snoop traffic, bias other nodes to send traffic through you, or listen via various mechanisms such that you can intercept traffic flowing between workloads not actually located on the compromised node.

So always encrypt everything unless you’re in a very rare environment with central network control that cannot be compromised or intercepted from a given machine.

And if you've been in that kind of rare environment, those people encrypt everything. They'd encrypt their license plate if they could. You want paranoid, look up laser microphones.

This would be less of a concern if the cluster's pods were Firecrackers, yes?

AWS EKS on Fargate has a dedicated ENI and kernel per pod; the only way to intercept the traffic is when it crosses a network, or with flow control logs. Or if somebody hacked the control plane, but that's always "Game over man, game over!"

Although with many clusters, compromising a single node is likely to lead to cluster compromise as it allows for all the service account tokens assigned to workloads running on the compromised node to be used by the attacker :)

This guidance is provided by the NSA, not for the NSA.

From the doc:

>It includes hardening strategies to avoid common misconfigurations and guide system administrators and developers of National Security Systems on how to deploy Kubernetes...

Also:

> Purpose > NSA and CISA developed this document in furtherance of their respective cybersecurity missions, including their responsibilities to develop and issue cybersecurity specifications and mitigations. This information may be shared broadly to reach all appropriate stakeholders.

NSA has multiple mandates and many stakeholders.

Looks like there's actually a "summary of the key recommendations from each section" on page 2.

> Works cited:

> [1] Center for Internet Security, "Kubernetes," 2021. [Online]. Available: https://cisecurity.org/resources/?type=benchmark&search=kube... .

> [2] DISA, "Kubernetes STIG," 2021. [Online]. Available: https://dl.dod.cyber.mil.wp- content/uploads/stigs/zip/U_Kubernetes_V1R1_STIG.zip. [Accessed 8 July 2021]

> [3] The Linux Foundation, "Kubernetes Documentation," 2021. [Online]. Available: https://kubernetes.io/docs/home/ . [Accessed 8 July 2021].

> [4] The Linux Foundation, "11 Ways (Not) to Get Hacked," 18 07 2018. [Online]. Available: https://kubernetes.io/blog/2018/07/18/11-ways-not-to-get-hac... . [Accessed 8 July 2021].

> [5] MITRE, "Unsecured Credentials: Cloud Instance Metadata API." MITRE ATT&CK, 2021. [Online]. Available: https://attack.mitre.org/techniques/T1552/005/. [Accessed 8 July 2021].

> [6] CISA, "Analysis Report (AR21-013A): Strengthening Security Configurations to Defend Against Attackers Targeting Cloud Services." Cybersecurity and Infrastructure Security Agency, 14 January 2021. [Online]. Available:https://us- cert.cisa.gov/ncas/analysis-reports/ar21-013a [Accessed 8 July 2021].

How can k8s and zero-trust cooccur?

> CISA encourages administrators and organizations review NSA’s guidance on Embracing a Zero Trust Security Model to help secure sensitive data, systems, and services.

"Embracing a Zero Trust Security Model" (2021, as well) https://media.defense.gov/2021/Feb/25/2002588479/-1/-1/0/CSI...

In addition to "zero [trust]", I also looked for the term "SBOM". From p.32//39:

> As updates are deployed, administrators should also keep up with removing any old components that are no longer needed from the environment. Using a managed Kubernetes service can help to automate upgrades and patches for Kubernetes, operating systems, and networking protocols. *However, administrators must still patch and upgrade their containerized applications.*

"Existing artifact vuln scanners, databases, and specs?" https://github.com/google/osv/issues/55

I agree there is a shit-ton of stuff to set up but based on the recent Pipeline and other Hacks where the Companies had to pay millions I would expect more companies to take stuff like this seriously.

For historical context:

https://www.washingtonpost.com/world/national-security/nsa-i...

(Google has since added encryption to its internal entworks.)

Entwork uses a tree topology with stepping roots

Encryption today is pretty much requirement for any regulated businesses and required practice for any sane shop, with or without Kubernetes. The only difference is that those services are communicating within the cluster internal network and not across different machines in the servers vlans.

If anything, setting up the whole things within Kubernetes ecosystem can be much easier with the available operators and automation frameworks like cert manager and/or Istio.

That sounds like work for a prime contractor with at least two subs under it. And consultants to help them implement SAFe AGILE.

We do this right now in a totally disconnected env. We have process in place to get images and manifests into our env. All containers have to go through scanning pipelines and have to be approved through a process.

We also for any container that makes requests that does not have the mechanisms for adding certificates we have to rebuild the containers in the disconnected env to insert certificates to allow communication.

Makes daily life really interesting

Do you use a proprietary tool to filter containers lacking the certificate mechanisms or is this handled as part of the manifests?

It's all handled as part of the manifests as well as we can have our clusters pulled if we are caught using non approved containers and they are all scanned when they are brought into the disconnected environment.

Opportunity is knocking

For as fundamental and important as encryption-in-transit is, it's always baffled me that there isn't a simpler, easier solution to accomplishing it on private networks. Everyone knows its important, and everyone wants to do it, but it's just such a pain in the ass and so prone to error that even some top security leaders will tell you not to bother because it's such a footgun.

We really need something to help make the process simpler, like how Let's Encrypt made public HTTPS so much easier to do for even the smallest of websites.

Smallstep attempts this, but I agree with everything you have said.

In some senses it’s differently complex, but WireGuard or similar may be simpler since it’s lower on the OSI and every application gets it “for free”.

I would argue that if you have services then the right place to put encryption and authentication is at the service level. Building secure channels between IP addresses is all good, but do you really want to map roles/identities/privileges to specific IP addresses if those roles/identities/privileges really represent services?

Why not? The IPs are cryptographically mapped to a specific client. Doesn’t stop one from using DNS to find the IP.

Like I said: differently complex but it’s a general solution to the problem and doesn’t require changing more “inner” things as much.

What if you end up spinning more than one container for that service?

How are these containers getting the different secrets they need to identify themselves? Are you attaching IAM roles to them to get secrets from some secret store?

Said it twice before: differently complex. There are plenty of potential “solutions” to the specific scenario you’re describing, but my original comment was more “generally consider X instead of Y so you don’t have to care about Z” rather than “use X in this specific way and it will simply solve every problem with Y”.

Well, there are encrypted CNIs like Weave. I've used Calico over ZeroTier to similar effect. The network is 'encrypted' and there isn't much effort required past initial configuration.

But that's not really the issue. You still have a big plaintext network with a bunch of random stuff talking, no mutual auth and no security controls other than segmentation. That's the tricky problem that mTLS and service meshes attempt to solve.

First, I’ll respond this w.r.t. k8s CNI specifically: all inter-node traffic is encrypted, the only plaintext is localhost. If you’re worried about network snooping on localhost you’ve got bigger problems. As for security controls, that’s what Network Policies are for.

Outside of k8s (where one has greater control over how specifically e.g. Wireguard is deployed). Again, there is no plaintext outside of localhost. Wireguard is mutual auth, I’m not sure why you think it isn’t. Wireguard + firewall is security control since, well, you have mutual auth so rules can be applied per-client.

You mean like kuma or cert manager?

I think both of those focus on ingress? I suppose you could just create your CA with cert manager and manually issue cert requests, but securing in-cluster traffic (automagically) will need some other moving piece, like a sidecar proxy that the service meshes use.

As far as a service mesh, check out Linkerd! I find Istio much harder to setup and manage. Linkerd is super simple and has always worked pretty much out of the box for me.

https://linkerd.io/

One thing to keep in mind is that Linkerd is pretty much strictly k8s only one while Istio and Consul Connect have first-class support for out-of-cluster services as well as e.g. Nomad. Relying on linkerd digs you waaay deeper into k8s lock-in.

This may be fully acceptable for you, but should not be glossed over.

From my experience, linkerd had the most seamless deployment to get to the most feature-complete out-of-the box experience with monitoring etc. But as it goes with these things there’s a much bigger amortized cost in terms of magic to unwind if you need to integrate it.

Mesh expansion is on the Linkerd roadmap, which will make it possible to run the data plane outside of Kubernetes.

The thing is you can use Let’s Encrypt for private networks too. For example, I use a dns challenge to get a wildcard certificate for a sub domain on my personal site, but those domains only resolve in my house. The wildcard cert isn’t essential for this - you could get individual ones - but it was easier for my home lab.

If Operating Systems had TLS built into the TCP/IP stack exposed by the kernel/system, you would never need to shim it in anywhere. You would just make a system call and use an open file descriptor/socket. One of the many programming-in-1970s-style things we still have not fixed.

But 1) kernel hackers won't implement it, 2) app devs are too possessive of their stack/codebase to just use one standard implementation/interface, and 3) security people are too paranoid to leave something "so important" up to the OS so they'd rather everyone implement it poorly/fragmentedly.

I doubt it’s a coincidence.

We learned recently that for a long time, the primary producers of cryptographic telephones was a single Swiss company. Owned by the CIA.

If security were easy, a lot of intelligence agencies would have a bad day.

Security doesn’t have to be this hard. But the powers that be seem to prefer complex, complicated systems, like DNS or SELinux.

It could be easier. Much easier.

Service mesh solutions like Istio / Consul Connect+Vault can help a lot with this.

Depending on the existing size and complexity of your stack those months can be cut down to weeks or even days.

I don't mean to trivialize the time and expertise needed to set up and manage, but if you can afford to run a microservice architecture on k8s already it's definitely not untenable.

Isn't this exactly what hashicorps "consul" can do? Specific services, and setup keys/certs so that all internal traffic is also 'blindly' encrypted? End point services don't care or know about it because it's transparent, but over the internal network it's encrypted?

TLS terminating is fine for most use cases (basic web services), but if you are protecting PII information you need to/should protect from external and internal threats.

Maybe a disgruntled sys admin decides to capture data coming in from the load balancer between the service(s) and sell it to the highest bidder. If traffic is encrypted between the load balancer and underlying service, it makes it much harder to do.

like protecting from three letter agency

Who scans the vulnerability scanners? Genuine question. How does the community/ecosystem solve this problem of auditability?

If your threat profile says you need to audit your vulnerability scanners, you audit your vulnerability scanners. There's not really a problem there right?

I've never had to. I wanted feedback from people who have.

NIST also says: if your scanner finds a vulnerability, it's up to you to VALIDATE that it's not a false-positive.

False-positives abound on these scanners.

For anyone who hasn't read it:

https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...

Are there any people working seriously on this? I'm aware of efforts for OCaml (http://gallium.inria.fr/~scherer/drafts/camlboot.pdf), but that's it.

https://dwheeler.com/trusting-trust/

'dwheeler is now the Linux Foundation's Director of Open Source Supply Chain Security.

The Bootstrappable Builds community (which camlboot is part of) are working on a lot of different efforts in this area. The main one is going from a small amount of machine code to an entire Linux distro, which is in-progress.

https://bootstrappable.org/ https://bootstrapping.miraheze.org/

Here's the original resource on Diverse Double Compilation to counter Trusting Trust Attacks: https://dwheeler.com/trusting-trust/

Notably I know the Rust compiler has been verified in this way (or at least certain versions of it have been verified), but it shouldn't be hard to do the same for any language with multiple independent implementations.

We deal with this by having multiple vulnerability scanners. Product A and Product B both scan your active environment. Product A scans Product B. Product B scans Product A. Additionally, make the vendors of those products sign NDAs so your threat actors, other than insiders, don't necessarily even know who they are. An attacker then needs to not only compromise both, but figure out who they are in the first place.

To this I'd add what is colloquialy referred to as a "Chinese wall", so that even insiders aren't aware of the full picture.

that was the issue in the solar winds hack: https://www.npr.org/2021/04/16/985439655/a-worst-nightmare-c...

I am mostly non technical person but why do we need to resort to firewalls etc. if we can employ UNIX like file permission system for network access? Wouldn't it be awesome if we can allow any installed software to contact ONLY whitelisted domains? Of course this excludes web browsers but you get the idea.

How about our mainstream OSes incorporate that kind of permission system similar to what we have in mobile OSes already have today?

SELinux

I didn't know that, learnt somthing today, Thank You!

Again, as a non technical person, why a software needs access to entire internet instead of whitelisted domains specific to its requirements is beyond me, since we already know how UNIX permission system works. Is it so hard to extend that to networks? Especially since everything is file in UNIX? Kindly pardon my ignorance :-)

You are right. Software doesn't need access to everything and it shouldn't. Unfortunately, it is easier on the consumer end to leave software access somewhat "open ended". The domain for updates may change or it may need to connect to different plugin sources. Unnecessary constrictions on a software's ability to function would fuel software issues. So, more sensitive networks will have administrators define these permissions. However, providing constrictive defaults to a regular consumer wouldn't be worth the customer service burden.

You're describing a firewall? How could it be more "UNIX-like"?

Think of them as a defence-in-depth that protect from accidental misconfiguration, software bugs, local exploits, etc.

It's a fair question and certainly is possible to have firewalls on a per-server basis. We do that for incoming traffic primarily. The catch is if that server itself gets compromised then you can't count on those rules still being enforced.

Having dedicated network appliances acting as firewalls means from a security perspective you need to compromise the local machine and then also compromise a dedicated, hardened external system as well. It vastly ups the difficulty barrier.

Firewalls does a lot more than block ports and services.

> - Use network separation to control the amount of damage a compromise can cause.

> - Use firewalls to limit unneeded network connectivity and encryption to protect confidentiality.

Are we still on this? Why isn't anyone pushing for zero trust? A concept made significantly easier to achieve thanks to container orchestration.

I do all those things in the pro version of my RBI (remote browser isolation) product, but i don't use k8s.

- Scan for vulns and misconfigs: I regularly update the underlying distro images, and use security scanning software to monitor dependencies, and regularly update them.

- Run with least privilege: I create a separate, temporary user account (no login, no shell) for each browser and service which has no elevated privileges, as well as run that browser and its service in a group and cgroup that restricts disk, bandwidth, CPU, and memory using block quotas, cgroups, tc, iptables and active monitoring and termination.

- Use network separation to isolate: RBI is basically a network isolation layer between the client (where the human interacts), and the server (where the browser actually runs.) I also don't have any privileges (service accounts, SSH keys, trusted IPs) on any of the machines and they're all single tenant and run inside GCE.

- Use firewalls to lock down connectivity + encryption: I use GCE firewall rules and iptables drop rules to block access to GCP metadata endpoints, as well as to other machines in the subnet. Also, every network request is encrypted (HTTP is https/TLS, WebSocket is wss/TLS, WebRTC is encrypted by default).

- Use strong auth to limit user access: For running the processes I use temporary users. For persistent browser sessions I use persistent users (either system native, or in a DB, always with bcrypt salted hashed passwords). For SaaS and resource control I use high entropy random API keys between each service layer. But I could improve my game for keeping secrets out of private git repos and separating code and config, ideally automatically. I could also improve my game to limit administrator access (right now I just have a single role, with God power, but I should create an admin role with power limited to a project, ideally even on a per-customer level).

- Use log autditing: I do this, but only manually, using various grepping and inspection of various logs, including last and lastb, as well as the service internal logs. This is likely something I could improve as well.

- Review all k8s settings: I don't use k8s or docker, just run services in this custom sandbox on GCE instances. I see that as both a way to limit attack service and complexity as well as minimize some overheads for maintenance and performance. In the longer term these things are worth exploring.

Thanks a lot for the TLDR. For more info on my RBI work check out https://github.com/i5ik/ViewFinder

Reply on news.ycombinator.com