I'm taking sailing lessons with my 12 year old son and he's as excited about it as I am. We have been out twice on a 37 foot sailboat with an incredibly patient instructor who calmly allows us to raise and then sheet in sails, teaches us to tack and jibe, and helps us learn every step of the process. My son gets seasick, and the instructor is even patient with that.
The first day we set out, the seas were incredibly rough. I'm actually pretty thankful for this as I was worried that if I only ever saw calm water, I'd fall in love with the sport but not understand the reality of what it’s like when it gets intense. As we pulled out of the harbor, I found myself holding on to the helm for dear life and learning to stand at weird angles as the boat heeled (leaned) strongly to one side and then started plowing over wave after wave. A few hours into the chaos, it started to feel a bit normal (and my son’s eyes were no longer wide open and freaked out), but it was intimidating as can be to start. Intimidating in a way that made me super thankful for the life vest the instructor required us to wear.
Through several days of instruction, we became more and more comfortable walking around the boat to get to hard to reach places, learning what to hold on to, what to watch out for, where it gets slippery, and so much more. But we also learned about the parts of the boat where you can strap yourself into a harness to ensure you don't get knocked off the boat in rough seas. As a person new to sailing, I don't want to go overboard. Heck, I'm sure long-time sailors don't either. But I was happy to be taught what I needed to know to ensure my safety and security.
I could pivot here and make a million helm, spinnaker, and halyard jokes, but instead I'm going to say, your developers, new or old at your company, don't want to make the kinds of mistakes that send them overboard. They want to be provided with a live vest and a harness with straps to keep them safe. It's your job at your company to push the guardrails for security into their hands.
If a developer thinks they're writing code and deploying to production in a safe way, but then later finds out their code has known vulnerabilities or includes horribly obvious over-permissioning, it's like a sailor finding out they're opening a valve in the bottom of the boat when they thought they were just draining the sink. Instead of a now-drained sink, they end up with a sinking ship. No sailor wants that. No developer wants to cause a security incident.
You have two choices in this situation: you can either educate the h*ck out of your developers or you can build the boat in such a way that it’s really hard to sink. This is where policy, best practices, and tooling for enforcement are a life vest. It may be heavier than just a t-shirt, but you're more than happy to wear one when you know what's at stake.
There is more than one way to ride on a boat. One is to show up, never hope to learn anything about it, enjoy your port wine and medronho below deck and look at the water when it's sunny. You enjoy the ride, but never care what this rope over here does, or wonder what's in that cargo bin and why it says "DANGER, SELF-INFLATING." You sit back, enjoy the ride, and let the captain handle all the problems — telling you when to go below, when to buckle up, and when to hold on.
But hopefully, when you're hiring developers, you're hiring people who are there to help you move the boat along. It's an antipattern for your DevOps or security team to have to be responsible for every single security problem. That'd be like having an army of bouncers standing around the edge of the boat because your guests don't know how to hold on to the railing when they walk above deck. It's expensive, it doesn't scale, and no one who wants to learn how to helm the boat is going to have patience for it.
As organizations increasingly adopt a service ownership model, the responsibility for platform teams to empower their developers to avoid security concerns also increases. You want alerts in place that keep your developers from deploying something with a known CVE or another security issue. You want to block deployments that allow people to run a container as root.
Waiting until things are live in production and yelling at your developer, "WHY ISN’T THAT FILESYSTEM SET TO READ ONLY!?" is like waiting till the wind and rain have picked up and yelling at the rookie helming the ship, "WHY ARE YOU POINTED DIRECTLY INTO THE WIND?!"
It's too late.
The education needs to have already happened or the boat needs an autopilot that makes avoiding the mistakes easy. You might recover, but everything is going to be more painful than it needed to be. Give your developers what they want — guardrails to keep them in the boat, a sense of security so they don’t have to panic about setting it on fire, and the tools for them to succeed. You all want to leverage the fair winds to get you moving in the same direction, after all.
Empower your developers with best practices and great tooling. Most of them are not Kubernetes experts and they’re new to helming the boat, but you can still make them successful sailors, er… developers.
Fairwinds Insights gives you security best practices out of the box. It's like getting sailors showing up on your boat already wearing life vests, the harnesses are ready (so you don’t need to handle a man-overboard situation), and they know that nothing they do is going to set the boat on fire. Turn it on, enable guardrails for your developers, and watch the ship sail smoother with empowered devs.
