The Kubernetes open source container orchestration engine is not a management platform, nor should it be mistaken for one. The whole point of orchestration is to reliably enable an automated system to facilitate the deployment and management of applications at scale, without the need for human intervention at each and every step. If the tools you use with and for Kubernetes don’t enable automation, then you’re not truly taking advantage of the benefits of orchestration.
To that end, here are seven ways you can and should be automating your Kubernetes cluster in production.
1) Logging
Any Kubernetes production environment will rely heavily on logs.
If you’ve never used Git, you may be nervous about it. There’s nothing to worry about—just follow along with this step-by-step getting-started guide, and you will soon have a new Git repository hosted on GitHub.
Before we dive in, let’s clear up a common misconception: Git isn’t the same thing as GitHub. Git is a version-control system (i.e., a piece of software) that helps you keep track of your computer programs and files and the changes that are made to them over time. It also allows you to collaborate with your peers on a program, code, or file. GitHub and similar services (including GitLab and BitBucket) are websites that host a Git server program to hold your code.
Spectre and Meltdown aren’t anomalies. They represent a new area to look for vulnerabilities and a new avenue of attack. They’re the future of security — and it doesn’t look good for the defenders.
Modern computers do lots of things at the same time. Your computer and your phone simultaneously run several applications — or apps. Your browser has several windows open. A cloud computer runs applications for many different computers. All of those applications need to be isolated from each other. For security, one application isn’t supposed to be able to peek at what another one is doing, except in very controlled circumstances. Otherwise, a malicious advertisement on a website you’re visiting could eavesdrop on your banking details, or the cloud service purchased by some foreign intelligence organization could eavesdrop on every other cloud customer, and so on. The companies that write browsers, operating systems, and cloud infrastructure spend a lot of time making sure this isolation works.
When it comes to which programming languages are in demand by employers, JavaScript, Java, Python, C++, and C—in that order—came out on top in a recent developer survey. Developers, however, want to learn languages like Python, Go, and Kotlin.
A survey of developers by technical recruiter HackerRank, conducted in October, found no gap between languages employers want and what developers actually know, with JavaScript barely edging out Java. But as far as which languages developers prefer, Python is the language developers most want to learn—and many already know it, HackerRank found.
In a previous post, I outlined emerging applications of reinforcement learning (RL) in industry. I began by listing a few challenges facing anyone wanting to apply RL, including the need for large amounts of data, and the difficulty of reproducing research results and deriving the error estimates needed for mission-critical applications. Nevertheless, the success of RL in certain domains has been the subject of much media coverage. This has sparked interest, and companies are beginning to explore some of the use cases and applications I described in my earlier post. Many tasks and professions, including software development, are poised to incorporate some forms of AI-powered automation. In this post, I’ll describe how RISE Lab’s Ray platform continues to mature and evolve just as companies are examining use cases for RL.
This week in open source/Linux news, The Linux Foundation announced a restructuring of their networking projects under one umbrella, Slack launches on Linux, and more!
1) The Linux Foundation consolidated its networking project under one umbrella this week.
4) Hyperledger has set in motion plans to give select startups access to some of the benefits accessed only by companies that are officially recognized.”
By design, Linux is a very secure operating system. In fact, after 20 years of usage, I have personally experienced only one instance where a Linux machine was compromised. That instance was a server hit with a rootkit. On the desktop side, I’ve yet to experience an attack of any kind. That doesn’t mean exploits and attacks on the Linux platform don’t exist. They do. One only need consider Heartbleed and Wannacry, to remember that Linux is not invincible.
With the Linux desktop popularity on the rise, you can be sure desktop malware and ransomware attacks will also be on the increase. That means Linux users, who have for years ignored such threats, should begin considering that their platform of choice could get hit.
What do you do?
If you’re a Linux desktop user, you might think about adopting a distribution like Subgraph. Subgraph is a desktop computing and communication platform designed to be highly resistant to network-borne exploits and malware/ransomware attacks. But unlike other platforms that might attempt to achieve such lofty goals, Subgraph makes this all possible, while retaining a high-level of user-friendliness. Thanks to the GNOME desktop, Subgraph is incredibly easy to use.
What Subgraph does differently
It all begins at the core of the OS. Subgraph ships with a kernel built with grsecurity/PaX (a system-wide patch for exploit and privilege escalation mitigation), and RAP (designed to prevent code-reuse attacks on the kernel to mitigate against contemporary exploitation techniques). For more information about the Subgraph kernel, check out the Subgraph kernel configs on GitHub.
Subgraph also runs exposed and vulnerable applications within unique environments, known as Oz. Oz is designed to isolate applications from one another and only grant resources to applications that need them. The technologies that make up Oz include:
It is important to remember that Subgraph is in alpha release, so you shouldn’t consider this platform as a daily driver. Because it’s in alpha, there are some interesting hiccups regarding the installation. The first oddity I experienced is that Subgraph cannot be installed as a VirtualBox virtual machine. No matter what you do, it will not work. This is a known bug and, hopefully, the developers will get it worked out.
The second issue is that installing Subgraph by way of a USB device is very tricky. You cannot use tools like Unetbootin or Multiboot USB to create a bootable flash drive. You can use GNOME Disks to create a USB drive, but your best bet is the dd command. Download the ISO image, insert your USB drive into the computer, open a terminal window, and locate the name of the newly inserted USB device (the commandlsblkworks fine for this. Finally, write the ISO image to the USB device with the command:
where XXX is the Subgraph release number and SDX is the name of your USB device.
Once the above command completes, you can reboot your machine and install Subgraph. The installation process is fairly straightforward, with a few exceptions. The first is that the installation completely erases the entire drive, before it installs. This is a security measure and cannot be avoided. This process takes quite some time (Figure 1), so let it do its thing and go take care of another task.
Figure 1: The Subgraph installation includes erasing your drive.
Next, you must create a passphrase for the encryption of the drive (Figure 2).
Figure 2: Creating a disk encryption passphrase.
This passphrase is used when booting your device. If you lose (or forget) the passphrase, you won’t be able to boot into Subgraph. This passphrase is also the first line of defence against anyone who might try to get to your data, should they steal your device… so choose wisely.
The last difference between Subgraph and most other distributions, is that you aren’t given the opportunity to create a username. You do create a user password, which is used for the default user… named user. You can always create a new user (once the OS is installed), either by way of the command line or the GNOME Settings tool.
Once installed, your Subgraph system will reboot and you’ll be prompted for the disk encryption passphrase. Upon successful authentication, Subgraph will boot and land on the GNOME login screen. Login with username user and the password you created during installation.
Usage
There are two important things to remember when using Subgraph. First, as I mentioned earlier, this distribution is in alpha development, so things will go wrong. Second, all applications are run within sandboxes and networking is handled through Tor, so you’re going to experience slower application launches and network connections than you might be used to.
I was surprised to find that Tor Browser (the default—and only installed—browser) wasn’t installed out of the box. Instead, there’s a launcher on the GNOME Dash that will, upon first launch, download the latest version. That’s all fine and good, but the download and install failed on me twice. Had I been working through a regular network connection, this wouldn’t have been such a headache. However, as Subgraph was working through Tor, my network connection was painfully slow, so the download, verification, and install of Tor Browser (a 26.8 MB package) took about 20 minutes. That, of course, isn’t the fault of Subgraph but of the Tor network to which I was connected. Until Tor Browser was up and running, Subgraph was quite limited in what I could actually do. Eventually, Tor Browser downloaded and all worked as expected.
Application sandboxes
Not every application has to go through the process of downloading a new version upon first launch. In fact, Tor Browser was the only application I encountered that did. When you do open up a new application, it will first start its own sandbox and then open the application in question. Once the application is up and running, you will see a drop-down in the top panel that lists each current application sandbox (Figure 3).
Figure 3: The LibreOffice application sandbox is up and running, while Tor Browser continues to download.
From each application sub-menu, you can add files to that particular sandbox or you can shutdown the sandbox. Shutting down the sandbox effectively closes the application. This is not how you should close the application itself. Instead, close the application as you normally would and then, if you’re done working with the application, you can then manually close the sandbox (through the drop-down). If you have, say, LibreOffice open and you close it by way of closing the sandbox, you run the risk of losing information.
Because each application starts up in its own sandbox, applications don’t open as quickly as they would otherwise. This is the tradeoff you make for using Subgraph and sandboxes. For those looking to get the most out of desktop security, this is a worthwhile exchange.
A very promising distribution
For anyone hoping to gain the most security they can on a desktop computer, Subgraph is one seriously promising distribution. Although it does suffer from many an alpha woe, Subgraph looks like it could make some serious waves on the desktop—especially considering how prevalent malware and ransomware has become. Even better, Subgraph could easily become a security-focused desktop distribution that anyone (regardless of competency) could make use of. Once Subgraph is out of alpha, I predict big things from this unique flavor of Linux.
Learn more about Linux through the free “Introduction to Linux” course from The Linux Foundation and edX.
The Linux Foundation is pleased to welcome LinuxBoot to our family of open source projects and to support the growth of the project community. LinuxBoot looks to improve system boot performance and reliability by replacing some firmware functionality with a Linux kernel and runtime…
LinuxBoot addresses the often slow, often error-prone, obscured code that executes these steps with a Linux kernel. The result is a system that boots in a fraction of the time of a typical system, and with greater reliability.
It’s roughly a year now that we built an intrusion detection system on AWS cloud infrastructure that provides security intelligence across some selected instances using open source technologies.
As more instances were spun, real-time security monitoring became necessary. We wanted the capability to detect when someone attempts an SQL injection, an SSH brute force, a port scan and so on. I forgot; we didn’t even want a ping request to go unnoticed if it was possible to ping any of the instances from the public and finally, centralize security logs from multiple EC2 instances which would then be visualized with Kibana.
Similar to the proliferation of mobile devices in the enterprise several years ago where organizations were feeling the pressure to have a mobile strategy but didn’t know where to start, we’re seeing the same situation with development methodologies. To accelerate development velocity, teams are feeling the pressure to “do DevOps,” and when integrating security, to “do DevSecOps.” But much like during the initial mobile wave, many companies say they’re implementing these methodologies, and might even think they are, but in reality, they’re not. Yet.
First, it’s important to remember that DevOps and DevSecOps are not job titles or roles. They are paradigm shifts in thinking and culture.
