[HN Gopher] NSA Kubernetes Hardening Guidance [pdf]
___________________________________________________________________
NSA Kubernetes Hardening Guidance [pdf]
Author : kennethko
Score : 375 points
Date : 2021-08-03 15:55 UTC (7 hours ago)
(HTM) web link (media.defense.gov)
(TXT) w3m dump (media.defense.gov)
| pletnes wrote:
| What yields the lowest risk - spending a ton of time hardening
| one cluster, or building multiple clusters to reduce the blast
| radius of bugs and misconfigurations?
| outworlder wrote:
| > What yields the lowest risk - spending a ton of time
| hardening one cluster, or building multiple clusters to reduce
| the blast radius of bugs and misconfigurations?
|
| Not sure this is a valid dichotomy.
|
| If you are spinning up multiple clusters, you are presumably
| doing so in an automated fashion. If so, then the effort of
| hardening is very similar. It doesn't really matter where you
| do it.
|
| Multiple clusters may have a smaller blast radius, but will
| have a larger attack surface. Things may be shared between them
| (accounts? network tunnels? credentials to a shared service?)
| in which case an intrusion in one puts everyone else at risk.
| kortilla wrote:
| > If so, then the effort of hardening is very similar. It
| doesn't really matter where you do it.
|
| Nope. If the clusters are separate it limits how damaging a
| compromise of the cluster is. This is why cloud providers
| don't stick you on the same k8s cluster as another tenant.
|
| > Multiple clusters may have a smaller blast radius, but will
| have a larger attack surface. Things may be shared between
| them (accounts? network tunnels? credentials to a shared
| service?) in which case an intrusion in one puts everyone
| else at risk.
|
| It's not really clear what you're trying to say here. If
| someone compromises credentials shared between all clusters
| that's the same as compromising credentials used by one mega
| cluster.
| RandomThrow321 wrote:
| > Nope. If the clusters are separate it limits how damaging
| a compromise of the cluster is.
|
| But if the clusters are configured similarly, a flaw in one
| is likely present in the others. GPs point is that if you
| invest in hardening, you can easily apply it to multiple
| clusters.
|
| > It's not really clear what you're trying to say here.
|
| I assume they mean having more clusters present means there
| are more opportunities to be compromised (e.g. more
| credentials to leak, more API servers to target, possible
| version skew, etc.).
| kortilla wrote:
| > But if the clusters are configured similarly, a flaw in
| one is likely present in the others.
|
| That doesn't matter. The point is that you isolate
| applications/tenants into different clusters. So if
| someone exploits their own, they haven't gained access to
| some other application.
|
| > assume they mean having more clusters present means
| there are more opportunities to be compromised (e.g. more
| credentials to leak, more API servers to target, possible
| version skew, etc.).
|
| That doesn't even make sense though. In our strawman
| scenario these are cookie cutter things. Many is not more
| vulnerable than one in this case.
| tamalsaha001 wrote:
| Both for different reasons!
| raesene9 wrote:
| with the usual caveat that it depends on your threat model, I'd
| say that having separate clusters is likely to provide better
| segregation.
|
| Of course that reduces the benefits of Kubernetes from a cost
| perspective, and increases administrative overhead, so it's a
| trade-off.
| dharmab wrote:
| At our very large org we do both. At least two clusters per
| region to isolate platform changes, all hardened to the same
| standards using automated tooling.
| zzyzxd wrote:
| You can't skip "spending a ton of time hardening one cluster"
| anyways.
|
| Having multiple clusters may help reduce the blast radius of
| _certain_ attacks, to some degree. However, managing multiple
| clusters is a lot more difficult than managing one, and you
| will potentially replicate bad practices, vulnerabilities to
| multiple places and increase maintenance burden.
| kenm47 wrote:
| what about tooling that hardens it across clusters?
| joncp wrote:
| Hmm... seems to call for a tool for a cluster-of-clusters.
|
| If "kubernetes" is Greek for the ship's pilot, what's the name
| for the captain or maybe the admiral of the armada?
| boilerupnc wrote:
| Cluster-as-a-Service :-)
|
| Hive for OpenShift [0] - Provisioning of the K8s Fleet
|
| Advanced Cluster Management [1] - Management of the K8s Fleet
|
| [0] https://cloud.redhat.com/blog/openshift-hive-cluster-as-
| a-se...
|
| [1] https://cloud.redhat.com/products/advanced-cluster-
| managemen...
|
| [Disclosure: I'm an IBMer]
| baq wrote:
| "Nauarch, in ancient Greece, an admiral or supreme commander
| of the navy, used as an official title primarily in Sparta in
| the late 5th and early 4th centuries bc." - google cites
| britannica (!)
| sascha_sl wrote:
| It exists, sort of.
|
| https://cluster-api.sigs.k8s.io/
| antonvs wrote:
| More directly relevant is Cluster Federation:
|
| https://github.com/kubernetes-sigs/kubefed
| CorralPeltzer wrote:
| https://github.com/karmada-io/karmada
| cmckn wrote:
| Rancher.
| antonvs wrote:
| One of the several tools in this space is called Admiralty:
|
| https://caylent.com/kubernetes-cluster-federation-with-
| admir...
|
| Google says the Greek for that is Nauarkheio. Now if you see
| a product named Navarxeio or Navarcheio, you'll know what it
| is.
| bsamuels wrote:
| If I could go back, single cluster. Any benefits you get from
| going multi-cluster can be achieved by configuring a single
| cluster correctly.
| agilob wrote:
| >a single cluster correctly
|
| Can you elaborate?
| antonvs wrote:
| At a high level, almost anything you would want to use
| multiple clusters for can be done on a single cluster,
| using e.g. node pools, affinity, and taints to ensure that
| workloads only run on the machines you want them to. As a
| simple example, you can set up a separate node pool for
| production, and use node affinity and/or taints to ensure
| that only production workloads can run there.
|
| One exception, as other have mentioned, is blast radius -
| with a single cluster, a problem with Kubernetes itself
| could take down everything.
| dharmab wrote:
| Another issue is scaling limits. We've found a few dozen
| ways to break a cluster by scaling along a certain axis.
| (Most are not related to "vanilla" Kubernetes but the
| backing cloud provider or specific add-on components.)
| kelseyhightower wrote:
| The one benefit you get is protection from bugs in Kubernetes
| itself and a reduced blast radius. Even if you could produce
| a secure and H/A cluster, you still leave yourself open to
| Kubernetes bugs and configuration mistakes such as adding a
| network policy that blocks all communication across all
| namespaces.
|
| Multiple clusters protects you from these types of
| configuration mistakes by reducing the blast radius and
| providing an additional landing zone to roll out changes over
| time.
| smarterclayton wrote:
| And making it so that "many clusters" look exactly like
| "one cluster" is one of the goals the kcp prototype was
| exploring (although still early) because I hear this ALL
| the time:
|
| 1. 1 cluster was awesome
|
| 2. Many clusters means I rebuild the world
|
| 3. I wish there was a way to get the benefits of one
| cluster across multiples.
|
| Which I believe is a solvable problem and partially what
| we've been poking at at https://github.com/kcp-dev/kcp
| (although it's still so early that I don't want to get
| hopes up).
| dylan604 wrote:
| If you have 2 clusters, wouldn't you just blue/green them
| for rolling changes?
| kortilla wrote:
| Except for security and fault isolation of course.
| debarshri wrote:
| This is really helpful. I wonder if there is curated list of k8s
| hardening guidelines for various organisations.
| raesene9 wrote:
| Some useful guidance here, although worth noting that some of it
| is a bit dated (k8s security can move quickly).
|
| Most notably from a scan through, they're mentioning
| PodSecurityPolicy, but that's deprecated and scheduled to be
| removed in 1.25.
|
| There will be an in-tree replacement but it won't work the same
| way. Out of tree open source options would be things like OPA,
| Kyverno, jsPolicy, k-rail or Kubewarden.
| nonameiguess wrote:
| We've actually already moved the official guidance from PSPs to
| OPA and that's what the primary DevSecOps reference
| implementation has used for about two months now.
|
| "We" being the DoD, but our guidance is the NSA guidance. I'm
| not sure why it hasn't made it into the policy pdf, but the
| actual official IAC has been using OPA since April.
| xxpor wrote:
| > Some useful guidance here, although worth noting that some of
| it is a bit dated.
|
| Is there any digital security guidance from the feds that
| doesn't apply to? :)
| sslayer wrote:
| Everybody wants small gov, until they don't.
| xxpor wrote:
| This is why I think big vs little government is really
| missing the forest for the trees in a lot of contexts
| (unless your overall goal is to minimize taxes and
| regulations at all costs). It's really a debate about the
| nature of bureaucracy. Process vs nimble. You can organize
| things to promote either, depending on your actual goals.
|
| Unfortunately small government activists have recognized
| this and have enacted policies that promote incompetence as
| much as possible. "Good enough for government work" is a
| choice, not an inevitability.
| herodoturtle wrote:
| I wonder if there's a third option, a decentralized
| government of small nodes, which can orchestrate their
| activity to rapidly scale in the need of large resource
| projects.
| smichel17 wrote:
| I think we tried that once, "in order to form a more
| perfect union".
| sleepybrett wrote:
| PaaS solutions can't cover everything that PSP was covering
| though.
| raesene9 wrote:
| Out of curiousity, which bits were you thinking of? OPA,
| Kyverno et all have policies which (AFAIK) hit all the bits
| of Kubernetes PSS.
| __app_dev__ wrote:
| I used to study and focus on security a lot more and keep up with
| trends. After several interviews this year I realize a lot of
| jobs prioritize leetcode over everything else. It's pretty
| annoying and makes me wonder if the focus for tech works is
| leetcode above all else then no wonder so many companies have
| insecure apps and servers.
| stillbourne wrote:
| I applied for a job that wanted someone who has experience with
| SAML. I've actually written my own hobby IDP, and I can diagram
| the handshake off the top of my head. I've spent a lot of time
| learning how to write custom decorators to handle access
| restrictions. I failed my interview because they wanted me to
| leetcode some shit with 3d geometric volumes. I'm sorry but
| what does this have to do with SAML or security?
| xpe wrote:
| This sucks -- it is a lose-lose situation. I've seen this
| kind of thing happen all too often.
| Gene_Parmesan wrote:
| Wow that's dumb. I've done some reading on 3d computational
| geometry for hobbyist game engine reasons, and in my
| admittedly limited experience, very few of the algorithms
| involved are intuitive enough to be derivable in an interview
| setting.
| nuclearnice1 wrote:
| You are correct. Especially at big companies, programmers
| program and security is just some rules dropped on them from
| above.
|
| You might be playing the long game. I think a CTO might benefit
| from knowing both app dev and security.
| herodoturtle wrote:
| At my company the head of security is also the chief
| programmer. Not sure if that's a good thing but he's got 30
| years experience and likes to tell war stories.
| __app_dev__ wrote:
| Thanks! Yeah, articles like this I would have studies in
| greater detail in the past but this year I realize In need to
| improve my leetcode/algo times so long term I'll keep focused
| on security and important topics. But in the meantime ...
| time to zig-zag a binary tree :(
| unixhero wrote:
| What do you mean prioritize leetcode? Do you feel that roles
| within information security require you to write "leetcode"?
| What even is leetcode?
| herodoturtle wrote:
| leetcode is a website that acts as a programming dojo of
| sorts where programmers can prove their skill in a measurable
| way and thus increase their odds of being hired.
|
| Employers use it to loosely gauge a programmer's basic skill
| level, as well as their competency to think clearly and
| cleverly.
|
| It has its pros and cons.
| the_doctah wrote:
| Leetcode is an algorithm-driven hiring preparation website
| __app_dev__ wrote:
| There was a famous case about 6 years ago where Google didn't
| hire the author of Homebrew because he couldn't whiteboard a
| leetcode type question. He posted to Twitter, then it was
| discussed heavily on tech sites:
|
| https://www.reddit.com/r/programming/comments/39d0u1/google_.
| ..
|
| In my opinion the problem has gotten worse. I spoke with a
| former Microsoft Product Manager early this year and he
| mentioned "Highly experienced engineers give the worst
| interviews" .. based on the current environment. He mentioned
| it's because the questions that come up are stuff people
| learned 20 years ago and never used in real-life.
|
| I was invited by several FAANG companies this year to
| interview and did one interview (and turned down others) but
| had to cram for 2 months doing leetcode.
|
| I realize it's a game but have mixed feelings. I think the
| interviews are bad if it's the only option but part of me
| knows the interview process is so bad it will likely
| discourage people from being Software Engineers and keep
| salaries high for many more years.
| icedchai wrote:
| Consider the typical company is running servers/instances that
| haven't been updated or rebooted in 6 months to 3 years. Never
| mind the multiple year old software dependencies in their
| apps...
| tra3 wrote:
| If you can't reverse a doubly linked binary prefix tree in O(1)
| then how can you be trusted with security?! /s :(
| herodoturtle wrote:
| Yes but in most circumstances, _quick security_ is better
| than _linear security_ ; not sure about _bubble security_
| though.
| dkersten wrote:
| Bubble security sounds like a good idea. You know, put
| everything into its own isolated little bubble.
| Rd6n6 wrote:
| What protects the companies and freelancers who write these
| insecure systems from liability? Is it just a blanket "we are
| not liable" clause in every contract?
| flerovium wrote:
| > A powerful example is the use of hypervisors to provide
| container isolation. Hypervisors rely on hardware to enforce the
| virtualization boundary rather than the operating system.
| Hypervisor isolation is more secure than traditional container
| isolation.
|
| The more things change, the more they stay the same.
| kenm47 wrote:
| so... a lot of this can be done with Fairwind's OSS tool
| Polaris... https://github.com/FairwindsOps/polaris
|
| feels good that we've been addressing this for a bit already tbh.
| (disclaimer, I work for fairwinds)
| herodoturtle wrote:
| How did you (/they) come up with the name Polaris?
| EamonnMR wrote:
| If I had to guess it's a nautical theme, following Kubes.
| Fair Winds (sailing), Polaris (North Star, used for
| navigation.)
| kchoudhu wrote:
| Somehow the text is not just... kubectl -n my-ns
| delete pod,svc --all
| [deleted]
| legrande wrote:
| We all know it's the National Insecurity Agency[0], and that the
| NSA hoards & stockpiles 0day. They very rarely release tools and
| research papers designed to strengthen our IT infra, since they
| sit on so much 0day. There's no balance.
|
| I don't buy that they're 50% red team, and 50% blue team. More
| like 99% red team and 1% blue team.
|
| [0] https://en.wikipedia.org/wiki/Doublespeak
| Closi wrote:
| > We all know it's the National Insecurity Agency[0], and that
| the NSA hoards & stockpiles 0day. They very rarely release
| tools and research papers designed to strengthen our IT infra,
| since they sit on so much 0day. There's no balance.
|
| Well if the NSA does have loads of 0day then it's still better
| for them to give good security advice to strengthen infra,
| because it will limit the access adversary's have while they
| still have all the 0day's anyway.
|
| i.e. they are advanced enough to not need to walk through an
| open door, so they might as well encourage others to close the
| doors because that will increase national security (while
| presumably not limiting their own access).
| nceqs3 wrote:
| ^HN Cancer. Says a bunch of crazy stuff without citing any
| sources with a throwaway account.
| imwillofficial wrote:
| One of their missions is infrastructure security of nationally
| important assets. Usually this is military stuff. But think
| power grids, etc... NSA ironically puts out some good security
| stuff. Their "manageable network plan" pdf is a must read for
| anyone hacking to wrangle a new environment, even if it isn't
| followed by the owners of said environment.
|
| I've been recommending it to various localities after my
| security assessments for years now.
| https://apps.nsa.gov/iaarchive/library/ia-guidance/security-...
| texasbigdata wrote:
| Have absolutely zero background knowledge here, but just to be
| pendantic your argument is structured as a logical fallacy [1].
|
| While we maybe could estimate the relative sizes of the groups
| you mention and compare them relative to each other to guess
| the strategy/policy/tactics it's not clear that would be
| accurate; or maybe we could infer based on some heuristic or
| metric (like budget being a proxy for headcount), and even then
| it's not clear how certain that guess would be, so it's not
| obvious how "we all know" it's 99/1 vs 50/50, vs any other
| permutation.
|
| Push come to shove would probably agree with your premise and
| conclusion, and really have no idea, so apologies for being
| nitpicky; without a background on the technical details it's
| likely I'm wrong.
|
| [1]
| https://www.logicallyfallacious.com/logicalfallacies/Alleged...
| bredren wrote:
| To add to this, GP: it is enough to simply state facts and
| how they influence your opinion.
|
| No individual can speak for all readers here on how they view
| this agency. Attempting to weakens the comment.
| beprogrammed wrote:
| - 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.
| sound1 wrote:
| 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?
| Meandering wrote:
| SELinux
| sound1 wrote:
| 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 :-)
| remram wrote:
| You're describing a firewall? How could it be more "UNIX-
| like"?
| zeroxfe wrote:
| Think of them as a defence-in-depth that protect from
| accidental misconfiguration, software bugs, local exploits,
| etc.
| bennysaurus wrote:
| 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.
| pavs wrote:
| Firewalls does a lot more than block ports and services.
| haolez wrote:
| Who scans the vulnerability scanners? Genuine question. How
| does the community/ecosystem solve this problem of
| auditability?
| knownjorbist wrote:
| For anyone who hasn't read it:
|
| https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref.
| ..
| Zababa wrote:
| 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.
| LukeShu wrote:
| https://dwheeler.com/trusting-trust/
|
| 'dwheeler is now the Linux Foundation's Director of Open
| Source Supply Chain Security.
| nonameiguess wrote:
| 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.
| herodoturtle wrote:
| 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.
| jhawk28 wrote:
| that was the issue in the solar winds hack:
| https://www.npr.org/2021/04/16/985439655/a-worst-
| nightmare-c...
| tinco wrote:
| 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?
| haolez wrote:
| I've never had to. I wanted feedback from people who have.
| throwaway984393 wrote:
| > 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?
| zaat wrote:
| 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.
| __app_dev__ wrote:
| 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.
| sdenton4 wrote:
| For historical context:
|
| https://www.washingtonpost.com/world/national-
| security/nsa-i...
|
| (Google has since added encryption to its internal entworks.)
| devy wrote:
| > 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.
| throwaway984393 wrote:
| I wonder about that. What are the attack vectors within a
| K8s cluster to necessitate inter-cluster transport
| encryption?
| smarterclayton wrote:
| 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.
| throwaway984393 wrote:
| 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!"_
| killjoywashere wrote:
| 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.
| zeckalpha wrote:
| This guidance is provided by the NSA, not for the NSA.
| Rd6n6 wrote:
| Do they have a version for ordinary web app servers?
| andrewmcwatters wrote:
| Well that's... curious. Not sure I've ever read the NSA providing
| hardening guidance on anything before.
| endymi0n wrote:
| For what it's worth, SELinux originated from the R&D Labs of
| the NSA.
| antonvs wrote:
| They've been doing that for at least a decade, but probably
| quite a bit longer. Here are their hardening guidelines for
| RHEL 5, from 2011:
|
| https://apps.nsa.gov/iaarchive/library/ia-guidance/security-...
|
| They have similar guidance for Windows, web browsers,
| industrial control systems, etc.
| andrewmcwatters wrote:
| Interesting! Thank you for sharing this.
| samstave wrote:
| I used them back at lockheed as early as ~2005? Although they
| were mostly around hardening BSD IIRC... (which became SElinux?
| I can't recall) and at the time, they were really "best
| practices" (things that you want to make sure you have done if
| you expect to pass any sort of audit (SOX, SAS70, etc).
|
| Sarcastically, we would say "they already have back doors in
| everything, they just don't want any other Bad Actors getting
| in their yard"
| Gene_Parmesan wrote:
| If you take the name National Security Agency at face value, it
| makes sense.
| HWR_14 wrote:
| > Not sure I've ever read the NSA providing hardening guidance
| on anything before.
|
| The NSA made SELinux, SHA-1, and SHA-256.
|
| SHA-1 was specifically a slight change to SHA-0 that was
| unjustified at the time but over the next 3-5 years some
| attacks on SHA-0 that SHA-1 was not vulnerable to surfaced.
| beprogrammed wrote:
| It's fine to trust them right up until they give you a magic
| number.
| tablespoon wrote:
| > It's fine to trust them right up until they give you a
| magic number.
|
| IIRC, DES had NSA-provided magic numbers in it that made it
| _more_ secure against a then-not-publicly-known
| cryptoanalytic attack.
| sdmike1 wrote:
| In general the NSA functions more like 2 agencies, one focused
| on the "red" side (hacking, breaking crypto, sigint stuff) and
| one focused on the "blue" side (protecting US assets from being
| hacked, developing better/new crypto, providing guidance on
| security).
|
| Both sides are good at their jobs and for what it's worth, my
| understanding is that the blue side really does want to keep
| your shit from being hacked.
| nwmcsween wrote:
| The elephant in the room here is almost all containers according
| to artifacthub.io, etc are a complete tire fire
| kenm47 wrote:
| there are good free/oss container scanners. check out Trivy.--
| no reason not to use one.
| nonameiguess wrote:
| The DoD maintains its own registry of hardened container images
| they call the Iron Bank. I guess they can't issue guidelines to
| the general public that you should use these, but the DoD has
| to use them. Which kind of sucks, because they may be hardened,
| but they also break all the time because the people responsible
| for hardening them can't possibly understand all the myriad
| subleties involved in building and deploying software packaged
| with dependencies in the same way the actual software vendors
| do. They make some serious rookie mistakes, like just straight
| copying executables out of a Fedora image into a UBI images,
| which works perfectly fine when a brand-new UBI release happens
| and it's on the same glibc as Fedora, then immediately stops
| working and all your containers break when Fedora updates.
| throwaway984393 wrote:
| They may suck at building containers, but this also sounds
| like a release management issue. Both the producers and
| consumers of the release need a test suite to validate the
| new artifacts before they can make it into a pipeline to
| eventually deliver to a customer use case. (But also they
| should 100% not be copying random binaries)
|
| For what it's worth I've seen worse from corporations. Bad
| hires lead to bad systems.
| soheil wrote:
| I keep forgetting NSA's job is to protect instead of maliciously
| eavesdropping on Americans. Given their prior probability of
| being a bad actor I'd take any security "guidance" they issue
| with a huge grain of salt.
| buggeryorkshire wrote:
| Reasonable. But then again they did come up with selinux and I
| haven't seen any backdoors in that.
| reacharavindh wrote:
| Yet.
| wvh wrote:
| It's perfectly possible, laudable even, to read things with a
| healthy dose of salt and still expand your understanding.
|
| I think this document gives a good general overview, often
| missing in the fast-paced, crowded and noisy Kubernetes
| landscape.
| lazide wrote:
| Like many large organizations, The government has many groups,
| often with many of them working to some extent against each
| other.
|
| AES also has been blessed by the NSA, and I bet you use that
| extensively too - if you want to or not?
___________________________________________________________________
(page generated 2021-08-03 23:00 UTC)