Using open source code makes it easier to build applications, but the freely available nature of open source code introduces the risk of pulling potential security vulnerabilities into your environment. Knowing whether or not customers are actually accessing the vulnerable parts of your application is key to triaging security threats without spending hours fixing an issue that doesn’t affect end users.
A SSH session can be interactive or non-interactive. The session starts when a computer or human connects to a node using SSH. SSH sessions can be established using public/private key cryptography or can use short lived SSH Certificates, similar to how Teleport works. Organizations often want to know who is accessing the systems and provide a greater level of control over who and when people are accessing them, which is where Teleport 4.4 comes into play.
Teleport 4.4 is here! The major innovation we’re introducing in this version is much improved control over interactive sessions for SSH and Kubernetes protocols. We’ll do a deeper dive into session control later, but for those who aren’t familiar with it, Teleport is an open source project. It provides access to SSH servers and Kubernetes clusters on any infrastructure, on any cloud, or any IoT device, anywhere, even behind NAT.
The first time I created a cloud compute instance, then still called a “Cloud VM”, was an almost transcendent moment. It was like magic. I was at my first organization which had adopted the cloud, in my first DevOps position, and I immediately knew that the world had changed.
Before we dive into the gap in cloud network security, let’s take a step back. If you’ve been in Operations for a while, you might remember how it used to be. “Network” was a team. When you needed to open a port on the network, you had to provide an exhaustive definition of the change, explaining what port you needed, what external addresses should be able to reach it, and where it should be routed to internally.
As the number of known vulnerabilities continues to grow every year, software development and application security teams are increasingly relying on vulnerability detection tools throughout development. The result: teams are often overwhelmed with a steady stream of security alerts that must be addressed, and it’s becoming clear that it’s impossible to attempt to fix everything.
Kubernetes has some impressive baked-in role based access controls (RBAC). These controls allow administrators to define nuanced permissions when querying Kubernetes resources, like Pods, Deployments, ReplicaSets, etc. For those familiar with Kubernetes, the value of RBAC is immediately recognizable. A single Kubernetes cluster can contain your organization’s entire CI/CD pipeline, highly available SaaS products, or infrastructure that is in the process of being moved to the cloud.
In a prior blog post, we explained how to install or update Artifactory through the Azure Marketplace in the amount of time it takes for your coffee order to arrive on the counter. Now you can add to your self-managed (BYOL) Artifactory deployment Xray, the cream of software component analysis (SCA) tools, through the Azure Marketplace as well.
As Kubernetes is eating the world, discover an alternative certified Kubernetes offering called K3s, made by the wizards at Rancher. K3s is gaining a lot of interest in the community for its easy deployment, low footprint binary, and its ability to be used for specific use cases that the full Kubernetes may be too advanced for. K3s is a fully CNCF (Cloud Native Computing Foundation) certified Kubernetes offering.
