Monat: Juli 2020

Preparing Kubernetes for the Real World – Q&A

The post Preparing Kubernetes for the Real World – Q&A appeared first on Mirantis | Pure Play Open Cloud.
Last month we held a webinar where Mirantis and Tigera discussed some of the considerations that arise with regard to networking when you take your Kubernetes cluster out of the lab and into production.  Here we have the questions and answers, but we’d love for you to view the whole webinar!
How do the Tigera and Docker Enterprise solutions integrate?
Docker Enterprise has what we call a “batteries included but swappable” model. With Calico, our customers get out-of-the-box networking for Windows and Linux workloads and a policy-driven security model and other features that Docker Enterprise doesn’t provide by itself.
Is it possible to configure Calico policies with Cisco infrastructure?
With the increasing adoption of container technologies and Cisco Application Centric Infrastructure (Cisco ACI) as a pervasive data-center fabric technology, it is only natural to see customers trying to integrate these two solutions. There are best practices for integrating Calico with Cisco ACI-based top of rack (ToR) routers in a robust dual ToR architecture. The result is a high performance non-overlay Calico network, with Calico network policy enforcement, where pods are first class citizens within the underlying fabric.
Cisco has developed a white paper that lays out detailed instructions for the required ACI configurations, plus associated Calico configuration to make the two work together seamlessly. You can read the full white paper here: Cisco Application Centric Infrastructure Calico Design White Paper
How do I upgrade Calico OSS to Calico Enterprise?
Tigera provides a phased approach to moving from the open source to the enterprise version of Calico. If you’re using the open source version of Calico we would recommend that you migrate to Calico Essentials, which provides support capabilities from the Tigera team to help you prepare for that migration.
We would also recommend that you take a look at a trial version of Calico Enterprise, which is available on the Tigera website, just to familiarize yourself with it, so that you’re aware of how the environment is going to change when you migrate from the OSS version to the enterprise version. Tigera’s customer success team can help you make a smooth transition from open source Calico to the Enterprise version.
What does “defend against lateral movement” refer to?
“Detect and defend against lateral movement” refers to the ability to detect when traffic is coming from a compromised container that may be scanning for other weaknesses or accessing other containers on the same network. Calico Enterprise provides this capability. Check out this Tigera blog that discusses lateral movement detection and defence in more detail, along with an associated webinar.
Egress access control can be achieved by using network policies in Kubernetes. How is Calico Enterprise different?
We’ve actually gone beyond what network policies can do in open source Kubernetes to provide customers with a couple of different options in terms of managing egress access control. We talked about the ability to control egress access on a per-app basis to any external endpoint, whether it’s a database or cloud service, and make that very granular. The other solution that we have, which is certainly unique to Calico Enterprise, is our ability to actually use external endpoints or control points as a way to manage egress access in the Kubernetes environment.
We can work with external firewalls and use the firewall as a control point. What we do is assign a pod inside a namespace as an egress access pod, and we use that pod that has access, with an IP address assigned to it, to connect to a control point like a firewall. It could be an API as well.  So somebody who’s using any kind of Fortinet or Palo Alto Networks firewall, for example, can then use that firewall as a control point for those pods, with the IP egress access that are destined for an external endpoint outside of the cluster. With that IP address attached to that egress pod, it means that if you have a monitoring system outside of Kubernetes that’s tracking network traffic, you’ll be able to see that pod and you’ll be able to track that pod as part of a workload. So those are some additional capabilities that we provide beyond network policies.
Check out this Tigera blog that discusses egress access control using Calico Enterprise.
How is monitoring different from SignalFX and Prometheus?
This is a really important topic. There are lots of ways to do monitoring, and there’s really no one-size-fits-all method. 
SignalFx is a Splunk-owned tool, so it’s licensed and has many important features for monitoring, many of which are centered around performance monitoring. For example, how is your Kubernetes performing? Where are there issues, and why? It taps into the intelligence that you get from having access to logs, events, and so on.
Prometheus, on the other hand, is a great open source tool. In fact, our solution within Mirantis, called Mirantis Cloud Platform (MCP), is based on the Prometheus monitoring tool. But one thing to note about Prometheus is that it’s not natively aware of all of the nuances of a container environment. Over time, we’ve “trained” our implementation of Prometheus to be opinionated about IaaS and container environments.
So those are two different approaches. You’re going to need to have a team with Prometheus, for example, that will know what to look for in a container environment and then how to translate that in terms of your data collection. How you store it, how you prune and rotate the data, how will you expose it, what visual interfaces are you going to use? We use Grafana as a front end to our Prometheus solution.
So the question being how monitoring is different from SignalFx and Prometheus, it’s not so much different, it’s just the big topic, and it has to be very carefully approached. We’ve had customers that have tried to roll their own in terms of even a Prometheus-based example, and one challenge that some customers have is that the data that’s been collected, to be done correctly, has to push meaningful alerts. If you’re collecting a bunch of data but you don’t know what the context is for that data, you’re not going to be able to produce the right alerts. If you can’t produce the right alerts, you’re going to struggle with your operations. You’re going to struggle knowing where and why some issues are happening, and what to do about it. So those are some of the cautions I would have about that.
Is Calico Enterprise included with Docker Enterprise?
Calico Enterprise is a separate, complementary solution that provides additional Kubernetes network and security capabilities for Docker Enterprise users.
Is Calico Enterprise available for doing a Proof of Concept in our own environment?
Yes, absolutely. If you go to the Tigera website on the homepage, you’ll find in the upper right hand corner an icon for a free trial. Anyone who’s interested in experiencing Calico Enterprise can access that. What we do is we set you up in an existing Kubernetes environment that’s already up and running, so you don’t have to invest any effort in getting infrastructure set up in your own environment. We take care of that for you, and you have access to that environment, so you can experiment and try out a full version of Calico Enterprise and see if it’s something that you think will fit in with your plans to expand your Kubernetes environment.
Where do developers get source images for use as inputs into the secure supply chain?
I’ll just use Docker Hub as an example. Docker Hub has certified images that are provided by various vendors. So if you’re looking to build a specific application using images that run specific vendor services, you might look at where those certified images can be found and Docker Hub is a great resource. It’s not just Docker related images if you will, but a variety of different images. It’s a good source for images that other groups have provided, and again, you can take into consideration the organization’s “certification label” however you want. You might still want to look at what’s in it and/or create your own. So you don’t always have to go get images for everything that you’re doing from somewhere else. You can compose your own and have more control over how it’s composed using what inputs.
Once you start building in your environment, you’ll have your known collection of trusted images. That’s where a tool like Docker Trusted Registry (DTR) comes in. DTR gives you a common, trusted place that you can go to for all of your image inputs. You can replicate it across sites so that your global team is able to reuse common certified images that also align with some of the features I was describing earlier. Things like signing the images, promoting them… I didn’t mention any of the other tags and characteristics of an image that can be used but with DTR, but you can promote only images that don’t exceed a certain age for example, or that have certain tags. There’s a very granular way of managing those images within DTR, but it requires either building your own images, signing them, and hosting them in your own registry, or acquiring certified images that come from outside your organization.
One feature I mentioned about DTR that’s important to keep in mind is the vulnerability scanning. The engine behind the DTR vulnerability scanning is the CVE database, and if you’ve been working in security you’ll know what CVE means — the industry source, if you will, of signatures that you want to know about. You want to be able to scan your images against those known industry signatures and make corrections.
What are key things to keep in mind when preparing to migrate a Kubernetes cluster from pilot to production?
Do you have the necessary tools to provide visibility into cluster activity, such as traffic flows?
Do you have troubleshooting tools that understand the Kubernetes context, such as  namespace and pod?
Are you able to securely connect the cluster to external resources such as databases and APIs?
Does your Kubernetes toolbox provide ways to protect against cyber-threats?
Are Dev, Ops, Network and Security teams in alignment with the plan to move to production?
Take a look at NIST’s 800-190 publication covering containers for a really good set of security best practices to start with.
Do you have an example of a typical compliance requirement that cannot be met with Kubernetes alone, and would require third party software?
I’m answering that one with a smile on my face, because it accurately describes most of Kubernetes. As I mentioned earlier, Kubernetes on its own has no inherent security capabilities. All pods are exposed and accessible. For a compliance requirement of only allowing access only from known origins. Kubernetes provides ways of implementing that. Doing network policy of course, there are ways of satisfying that compliance requirement with Kubernetes, but to do it at scale in a visual way, the visualization is really not what native Kubernetes has.
If you had to prove to an auditor that you have a way of detecting a rogue traffic flow and identifying where that is and correcting that, that’s not something that native Kubernetes is going to provide. You’re going to need a solution like Calico Enterprise to provide that information and visualization. Lateral movement is another good example. Lateral movement means you’ve got a container that’s been compromised, for example, and that compromised container is looking at neighboring containers on the same network in an effort to gain access to sensitive resources, such as mail systems, shared folders, and legitimate credentials. You need to have a way of detecting and defending against threats like that. That cyber-defense capability is not something that’s natively part of Kubernetes, but it is part of the Calico Enterprise solution.
Can multiple Calico instances be tied together or sent to a northbound interface?
The short answer is “yes”. You assign a workload/app/instance to a namespace, designate one pod in that namespace as the egress pod, then assign a routable IP address to that pod. You can do that with multiple namespaces, each with a different workload/app/instance.
Using this approach, egress access for northbound traffic can be managed from an external control such as a firewall or API, and can be also managed using policy controls. Another advantage of this approach is that because you only need to assign one routable IP per namespace, you are able to preserve the limited number of routable IPs in your IP pool.
You mentioned NIST guidelines. In specific audits, are those enumerated if/when compliant?
Each audit is different, but your own security organization will typically have already defined a system security plan detailing what security compliance looks like for your environment. Your security and IT team will then have to show the auditor that you do in fact have all the processes, methods and configurations in place to implement the plan. An auditor will document any deviation from the plan. You may or may not have a list of NIST controls. That will be up to your team to define whether controls come from NIST or some other set of standards.
The post Preparing Kubernetes for the Real World – Q&A appeared first on Mirantis | Pure Play Open Cloud.
Quelle: Mirantis