Cloud Governance For The DevOps Pro

Michael Levan - Feb 28 '22 - - Dev Community

Whether you work in a bank, a startup, or any other type of organization, the cloud at this point is most likely part of your organization. You could be using Azure or AWS, or maybe you’re on-prem but you use Office 365 or Gmail. In any case, protecting your data is crucial.

In this blog post, you’ll learn what cloud governance means for DevOps engineers and how you can get started implementing it today.

Defining Policies

The “DevOps Engineer” role is turning into a bit of a unicorn. It reminds a lot of engineers of a Systems Administrator. As a Sysadmin, you pretty much have to do everything. Security, infrastructure, storage, networking, user management, and a bunch of other areas.

With DevOps, you have to do software, app support, deployments, security, cloud management, and several other roles. The duties aren’t the same as a Sysadmin, but the idea of wearing many hats is. One of those hats is security.

If an application has a security bug in it and you deployed it, chances are you might hear about that even if you didn’t write the code. To ensure that what you’re deploying is up to a certain standard, you need to have those standards in place. For example, maybe every deployment that you do requires some type of security test with a tool like SonarQube. If that test doesn’t exist, the code doesn’t get deployed. Although it can slow down productivity, a security leak will slow down productivity even more.

Defining policies and standards around what’s deployed in the organization that you work at is crucial for security success.

Test Close To Your Development Cycle

The whole “Shift Left” approach has become amazingly buzzword-ish, but there is good meaning behind it from an engineering perspective.

In most scenarios, especially in the development/DevOps space, security is an afterthought. It’s all about getting a feature out so a customer wants to buy more of the software vs what’s important. Sure, a new feature is important, but what’s even more important is ensuring that the software works properly. In today’s world, a lot of folks, including organization leaders, get caught up in the new and shiny to impress the board.

Well, that’s nothing like getting hacked to really impress the board!

The Shift Left movement is the idea of implementing security practices from the beginning. For example, let’s say you write a new application functionality. After you wrote it, did you implement security tests with something like SonarQube or Veracode? When you built the code automatically with CICD, did you put your security tests in the CI process?

If not, that means you’re not shifting left.

The best ways to get started are:

  • Ensure that after every piece of code that you build, it should have a security test, just like it has a unit test.
  • Ensure that secrets (API keys, passwords, etc.) aren’t saved in source control like GitHub
  • Use something like SonarQube and if possible, a security linter (like gosec for Go) to ensure that you’re following standards and best practices
  • Implement a Policy-as-Code tool

Make Security A Priority, But Not A Guarantee

We’re all used to features, bug fixes, and cleaner code being a priority, but what about security? In the previous section, you learned of a few reasons why it’s important to make security a priority, but one thing that you have to understand is that it’s never going to be a guarantee. Security is an interesting animal. You can implement all of the best practices, but it may not be 100%.

It sort of reminds me of weatherman. To predict the weather is an interesting thing. With the use of satellites, radar, and surface maps, a weatherman can see what weather types are coming and what to prepare people for. Here’s the reality though - weather changes. Winds change course, are faster, and ultimately unpredictable. Security is the same way.

You can implement tons of great practices, tools, software, and standards, but you can’t ever say that your organization is 100% secure. Even big organizations go through cyber security attacks, so you can’t assume that everyone is always secure. The best thing that you can do is implement all of the best standards/practices and ensure you keep up to date on them.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .