Kubernetes security policy design: 10 critical best practices

In this blog post, I will be looking at 10 best practices for Kubernetes security policy design. Application modernization is a strategic initiative that changes the way enterprises are doing business. The journey requires a significant investment in people, processes, and technology in order to achieve the desired business outcomes of accelerating the pace of innovation, optimizing cost, and improving an enterprise’s overall security posture. It is crucial to establish the right foundation from the beginning, to avoid the high cost of re-architecture. Developing a standard and scalable security design for your Kubernetes environment helps establish the framework for implementing the necessary checks, enforcement, and visibility to enable your strategic business objectives.

High-level design

 

Building a scalable Kubernetes security policy design requires that you adopt a fully cloud-native mindset that takes into account how your streamlined CI/CD process should enable security policy provisioning. A sound design would enable your enforcement and policy provisioning requirements in Day-N, while accommodating Day-1 requirements. The following list summarizes the fundamental requirements that a cloud-native security policy design should include:

  1. Segmentation of the control, management, and data planes
  2. Segmentation of deployment environments
  3. Multi-tenancy controls
  4. Application microsegmentation
  5. Cluster hardening
  6. Ingress access control
  7. Egress access control
  8. Continue reading

Heavy Strategy 008: Five Core Issues for IT Architects in 2021

I’ve just published the latest episode of Heavy Strategy with Johna Til-Johnson. In this episode we discuss five issues that we think IT Architects should be considered for 2021. The discussion on why and why not should be helpful for your own thinking and prepare you for discussions in your own organisations. You can find […]

Heavy Strategy 008: Five Core Issues for IT Architects in 2021

What five issues would be top of mind for IT architects ? Security, Backup.Recovery, Cloud, Skills Development and Distributed/Hybrid Work. Listen in on why and how these issues are our choices. If you have feedback or want us to followup then head over to our Follow Up page and send us your anonymous (or not) feedback.

The post Heavy Strategy 008: Five Core Issues for IT Architects in 2021 appeared first on Packet Pushers.

Authorize Better: Istio Traffic Policies with OPA, Styra DAS

Adam Sandor Adam is a solution architect at Styra, helping companies to adopt OPA and Styra DAS. He has been working in the cloud native space for the past six years, focusing on Kubernetes adoption and software delivery. In his free time, Adam is a dedicated DCS World pilot and happy cyclist roaming the cycle paths of the Netherlands. Cloud native tooling for authorization is an emerging trend poised to revolutionize the way we approach this oft-neglected part of our applications. Styra DAS offer. When services are connected using the Istio service mesh, all those sidecar proxies running Envoy are great places to make authorization decisions. All HTTP requests flow through them with metadata included about the source and destination services. The capabilities of Envoy are exposed by Istio in the form of the

Automatic Remediation of Kubernetes Nodes

Automatic Remediation of Kubernetes Nodes
Automatic Remediation of Kubernetes Nodes

We use Kubernetes to run many of the diverse services that help us control Cloudflare’s edge. We have five geographically diverse clusters, with hundreds of nodes in our largest cluster. These clusters are self-managed on bare-metal machines which gives us a good amount of power and flexibility in the software and integrations with Kubernetes. However, it also means we don’t have a cloud provider to rely on for virtualizing or managing the nodes. This distinction becomes even more prominent when considering all the different reasons that nodes degrade. With self-managed bare-metal machines, the list of reasons that cause a node to become unhealthy include:

  • Hardware failures
  • Kernel-level software failures
  • Kubernetes cluster-level software failures
  • Degraded network communication
  • Software updates are required
  • Resource exhaustion1
Automatic Remediation of Kubernetes Nodes

Unhappy Nodes

We have plenty of examples of failures in the aforementioned categories, but one example has been particularly tedious to deal with. It starts with the following log line from the kernel:

unregister_netdevice: waiting for lo to become free. Usage count = 1

The issue is further observed with the number of network interfaces on the node owned by the Container Network Interface (CNI) plugin getting out of proportion with the number of running pods:

$  Continue reading

Ransomware: Quis custodiet ipsos custodes

Many claim that "ransomware" is due to cybersecurity failures. It's not really true. We are adequately protecting users and computers. The failure is in the inability of cybersecurity guardians to protect themselves. Ransomware doesn't make the news when it only accesses the files normal users have access to. The big ransomware news events happened because ransomware elevated itself to that of an "administrator" over the network, giving it access to all files, including online backups.

Generic improvements in cybersecurity will help only a little, because they don't specifically address this problem. Likewise, blaming ransomware on how it breached perimeter defenses (phishing, patches, password reuse) will only produce marginal improvements. Ransomware solutions need to instead focus on looking at the typical human-operated ransomware killchain, identify how they typically achieve "administrator" credentials, and fix those problems. In particular, large organizations need to redesign how they handle Windows "domains" and "segment" networks.

I read a lot of lazy op-eds on ransomware. Most of them claim that the problem is due to some sort of moral weakness (laziness, stupidity, greed, slovenliness, lust). They suggest things like "taking cybersecurity more seriously" or "do better at basic cyber hygiene". These are "unfalsifiable" -- things that nobody Continue reading

Hedge 91: Leslie Daigle and IP Addresses Acting Badly

What if you could connect a lot of devices to the Internet—without any kind of firewall or other protection—and observe attackers trying to find their way “in?” What might you learn from such an exercise? One thing you might learn is a lot of attacks seem to originate from within a relatively small group of IP addresses—IP addresses acing badly. Listen in as Leslie Daigle of Thinking Cat and the Techsequences podcast, Tom Ammon, and Russ White discuss just such an experiment and its results.

download

Automation Savings Planner

Pre-plan your automation savings with Red Hat Insights for Red Hat Ansible Automation Platform

Enterprise organizations understand that to be leaders in their industries, they must change the way they deliver applications, improve their relationships with customers and gain competitive advantages.

Positioning those advantages to have a positive return on investment often starts with proper planning and automation.

But what does proper planning of your automation even look like?

For some enterprises, proper planning includes reducing automation costs. For others, it’s reducing time spent to open new opportunities.

With this in mind, Red Hat is excited to introduce Automation Savings Planner, a new enhancement that puts automation planning in the forefront within the hosted services on console.redhat.com.

The Automation Savings Planner is designed to provide a one stop shop to plan, track and analyze potential efficiency improvements and cost savings of your automation initiatives.

 

How does it work?

Users can create an automation savings plan within Red Hat Insights for Red Hat Ansible Automation Platform by defining how long and often the work is done manually, as well as a list of tasks needed to successfully automate this job.

Once defined, you can integrate your newly Continue reading

Day Two Cloud 106: Towards A More Open Cloud

On today's Day Two Cloud we discuss the notion of open cloud. The premise is about reducing or minimizing costs of migrating from a public cloud. In theory, open cloud lets organizations keep their options open to make changes and reduces lock-in. But is open cloud even feasible? Our guest is Chris Psaltis, co-founder and CEO of Mist.io, a startup building an open-source, multi-cloud management platform.

Day Two Cloud 106: Towards A More Open Cloud

On today's Day Two Cloud we discuss the notion of open cloud. The premise is about reducing or minimizing costs of migrating from a public cloud. In theory, open cloud lets organizations keep their options open to make changes and reduces lock-in. But is open cloud even feasible? Our guest is Chris Psaltis, co-founder and CEO of Mist.io, a startup building an open-source, multi-cloud management platform.

The post Day Two Cloud 106: Towards A More Open Cloud appeared first on Packet Pushers.

Free Speech is More than Words

A couple of weeks ago, I joined Leslie Daigle and Alexa Reid on Techsequences to talk about free speech and the physical platform—does the right to free speech include the right to build and operate physical facilities like printing presses and web hosting? I argue it does. Listen in if you want to hear my argument, and how this relates to situations such as the “takedown” of Parler.

Listen here

NATs, PATs, and Network Hygiene

While reading a research paper on address spoofing from 2019, I ran into this on NAT (really PAT) failures—

In the first failure mode, the NAT simply forwards the packets with the spoofed source address (the victim) intact … In the second failure mode, the NAT rewrites the source address to the NAT’s publicly routable address, and forwards the packet to the amplifier. When the server replies, the NAT system does the inverse translation of the source address, expecting to deliver the packet to an internal system. However, because the mapping is between two routable addresses external to the NAT, the packet is routed by the NAT towards the victim.

The authors state 49% of the NATs they discovered in their investigation of spoofed addresses fail in one of these two ways. From what I remember way back when the first NAT/PAT device (the PIX) was deployed in the real world (I worked in TAC at the time), there was a lot of discussion about what a firewall should do with packets sourced from addresses not indicated anywhere.

If I have an access list including 192.168.1.0/24, and I get a packet sourced from 192.168.2.24, Continue reading

1 … 704 705 706 707 708 … 3,849