This newsletter is traditionally published by the Field CTO team here at HashiCorp. It focuses on looking over the previous week's news and giving general comments about what we’ve observed and how this relates to parts of the industry that concern our work with HashiCorp. Sometimes we riff on whatever tickles our fancy.
Welcome back! My name is Michael Wood, another member of the Field CTO team here at HashiCorp. I approach these newsletters with an eye toward the elements that may impact today’s thinking. I’m hoping to capture the thread that runs through these events and how we might better position ourselves for long-term success.
In this episode, I find I’m captivated by the rapid transformation of the networking landscape. While we have not landed on laser sharks yet, we do have laser balloons!
Space, Lazers, and Other Cool Stuff
When I was in middle school and into high school, I dreamed of the day when we would have flying cars. I naively thought it was easier to deliver something aerodynamic for personal travel than to put all of the world’s knowledge on a phone/computer/TV/calculator thing in my pocket. After all, we’d been predicting a world of flying cars before the 1950s. Given the focus on delivery of all this personal and digital service, we simply shoot past simple things like a flying car to Star Trek kinds of things.
For instance, networking seems intent on accelerating past towers into space and laser! Or maybe space lasers! Or sharks with lasers on their heads! Er … something like that. I may have lost reality there for a sec, given I might get to take a space flight before personal flight finds a safe landing for the general public. If you’re interested in booking your trip to space, start here with a quick application!
Back to satellites and data delivery. Satellite launches continue to accelerate. Starlink is blanketing the planet with satellites to provide network access everywhere. Apple now releases phones with the ability to flip over to satellite network communication. Could this be an answer to the rumored Tesla phone? Sounds good to me!
Maybe I’m slow to the party here, but when I read about Google Loon (a wild idea of floating network devices on a grid of balloons), I thought I was reading more of my childhood science fiction. Well, Loon has moved out of Google’s protective care and is now looking to shoot “frickin lasers” to transmit data over long distances through the air at speeds “100-1000x faster than anything else available today.” While moving away from the balloons concept, they still need to deal with signal reliability (as objects can pass through the beam and disrupt transmission). So, project “Spacetime” connects to different endpoints as needed to keep clean, fast signal transmission. And might I say, these names give me hope that my kind of wild creative can find meaningful work. Innovation continues to run at breakneck speed. We haven’t finished getting the satellites up, DARPA is optimizing patterns of usage for space networking, and already we are on to laser cannon communication. Whew! Maybe with all this space stuff, we can get a better picture of this giant exoplanet!
So, Now Everything is on the Network?
Well, I suppose so. One of the required elements to driving automation to the ends of the earth, as expressed in services like self-driving vehicles, is connectivity at all times, in all weather, and everywhere. In the early days, there were thoughts on achieving this; fiber in the pavement, for example. Forbes offered a handful of ideas in 2018, which include machine readable signs, all infrastructure being fiber connected, etc. To automate things, each individual “thing” must connect, consume power, and move data. In such a world, everything and everyone reports telemetry and boasts some level of trust 24X7.
Now with laser sharks (thanks, Dr. Evil, for the quote) potentially firing network wherever we need it to go at all times, supported by a sky full of communication satellites, we are racing to that reality. Everything down to the pavement will be connected and moving data. Where does your network begin and end? The cloud vendors are looking to provide private 5g networks as cloud-native services. These should allow for “network slicing” such that enterprises will rope off sections of 5g as private.
As per Ericsson, “The network slice is a logically separated, self-contained, independent and secured part of the network, targeting different services with different requirements on speed, latency, and reliability.”
So, here we have our new sub-netting! Our 5g slices of the network should allow us to play around with discrete policy and management for subdivisions of the cloud real estate under management. However, as these slicing services mature, we are likely to consider still treating the network as low-trust. If everything is on the network, then defense against unauthorized network transgression continues to be a daunting process.
To The Breach with Style!
So, what stands out to me is how correct the move to identity continues to be. Shortly after 5g IP range negotiations shake out, we’ll instrument all the things, then everything will be on the network. Consequently, we must use name and ID to establish trust. As ID gets more robust, the need for manual passwords declines. The iPhone now boasts passwordless unlocking of your phone. On the systems side, Okta and Ping have focused on strongly attested identity apart from passwords for a bit now.
In addition, Microsoft’s efforts on Azure to eliminate user passwords indicate the public cloud’s move to generally simplify access (authN/authZ) for users to cloud resources. However, attack patterns progressively come through social engineering (phishing) or systems (like Windows 11 vulnerabilities). Here I thought we were doing everything right on the human side, and still, we are open to attack!
Given that systems can create an identity and trusted resources on the network (like the Tesla breach a few years back or vulnerabilities in our OS, as mentioned above), we should consider removing the ability to create trusted resources directly. Instead, declare intent to be vetted and consumed via automation.
I’m likely beginning to sound like a broken record, but I can’t help but notice that after the SolarWinds’ supply chain-style attack on systems too numerous to count, we continue to repeat the vulnerabilities that make such attacks incredibly potent. A vulnerable OS with a trusted IP on too broad a set of assets can be a threat. But what if?
What if we force users to declare the change they wish to see, vet that request, and only then consider implementing the change in our environment? What if, in addition, we declared the networking rules only to allow access to these systems from systems of automation - reducing the networking routes by (potentially) orders of magnitude? What if the identity of the machines were centrally managed and assigned with the least-privilege constraints managed and re-attested often? The point remains. The issues we face in an ever-changing and expanding interconnected world are not technological - they center on workflow. How do we introduce change to our environments? How many ways can change enter our network segment? Can any laptop, if compromised, create trusted workloads on the network? As the acceleration of devices on the network skyrockets, so does the need for an industrialized approach to introducing change and assigning ID.
I Can’t Think of Another Thing
To close, I thought I’d make one more push at mitigating “cognitive load.” I love the term. It implies weight, which, of course, it is. I was reading how AWS services received 54 updates in the last ten days, which is an incredible pace of play. When you have money and bodies to throw at these innovations, you can drive pretty solid speed, but I’m sure it is more than that. Azure had 12 updates in 12 days, which is symmetrical and even. It feels like Microsoft (and yes, I know that was just a coincidence). What struck me here is the amount of change we are progressively on the hook for. As every device, street corner, and pair of socks joins the network, we are building experiences to interact with it all, and all the while, the cloud services we rely on are in a constant state of flux.
Additionally, new services are born every day. As we consider the adoption of systems, we need to do so with an eye for the progressive complexity of our adoption. Each service the cloud provides is something else to understand (from usage, complexity, security, audit, compliance, cost, risk, and failure conditions). For better or worse, we will need simplification through some form of platform team that automates the delivery of the “right” services for the “right” outcome. The days are numbered where a team can exercise all things, all the time, with perfect knowledge. Even the celebrities who have gotten away with it have done just that—gotten away with it. Eventually, complexity and access catch up to you.
I hope you enjoyed the newsletter! See you in the field!