Designing software is tough. Whether you’re a designer, a product manager, or an engineer, we all play a major role in what the end user gets their hands on. Perhaps one of the most critical pieces on the journey to making great software is the relationship between designers and developers. When software is done right, it’s easy, intuitive, and a joy to use. This is no accident - it’s very intentional and it often takes countless iterations to get products to look and feel great.

The modern human likely has profiles on dozens of applications. Whether it’s social media applications, music/video streaming, or workspace resources, each of us must manage accounts that contain personal information. Over time, these siloed applications have become increasingly connected. Twitter allows news sites to directly tweet, Discord searches Facebook for suggested friends, and Jira creates user accounts using Github profiles.

We’re excited to announce the release of Teleport 4.3 - new UI, API driven, expanded audit capabilities, and still open source. This version is so significant, we nearly called it 5.0! In this post, we’ll cover the major new features and you’ll see why we called it ‘Teleport’.

This is a major Teleport release with a focus on new features, functionality, and bug fixes. It’s a substantial release and users can review 4.3 closed issues on Github for details of all items. We would love your feedback - please pick a time slot for a remote UX feedback session if you’re interested. Teleport 4.3 includes a completely redesigned Web UI.

SCP? It’s that handy file-transfer feature of SSH, right? Well, not quite. It’s more of a hack. Or an undocumented, unstandardized mashup of two protocols. Let’s look at the exciting (and scary) details. Secure Copy Protocol (SCP) allows us to move files (and directories) between two computers. Using it is straightforward: This will copy local_file.txt to another computer (usually a server) with domain name remote_host into the /home directory.

Organizations of all sizes are currently under siege by adversaries with unlimited time and enough technical skill to exploit the cracks in our information systems and networks. All organizations have something to protect, whether large or small, and they are always looking for new technology to help against these adversaries. Zero Trust has become the latest framework to solve all of our security woes.

In under five years time, Kubernetes has become the default method for deploying and managing cloud applications, a remarkably fast adoption rate for any enterprise technology. Amongst other things, Kubernetes’s power lies in its ability to map compute resources to the needs of services in the current infrastructure paradigm. But how does this tool work when faced with the new infrastructure layer that is blockchain? Can the two technologies be used in conjunction?

As one of the engineers on the Gravity team here at Gravitational, I was tasked with adding SELinux support to Gravity 7.0, released back in March. The result of this work is a base Kubernetes cluster policy that confines the services (both Gravity-specific and Kubernetes) and user workloads. In this post, I will explain how I built it, which issues I ran into, and some useful tips I’d like to share. Specifically, we will look at the use of attributes for the common aspects of the policy.

In this post, I want to share my observations of how SaaS companies approach the trade-off between having solid cloud infrastructure security and pissing off their own engineers by overdoing it. Security is annoying. Life could be much easier if security did not get in the way of getting things done.