Cloudockit Compliance Feature & AWS, Azure, GCP Built-in Policies and Security features

In this article, we will compare the tools to monitor & control your cloud environment in the three major Cloud Providers (Azure, AWS & GCP) and also see how Cloudockit can help you to ensure your environments in the cloud are conform to what you planed.

First, let’s have a look at what is built-in in Azure, AWS & GCP:

Tool to …AzureAWSGCP
Understand your security and data attack surface

Security Center



Image result for guardduty

Cloud Security Command Center

Image result for Cloud Security Command Center

Enforce rules that you chooseAzure PolicyService Control PoliciesOrganization Policy Service

Here are more details about each of this feature:

  • AWS
    • AWS provides a feature call GuardDuty that is similar to Azure Security Center. GuardDuty objective is to allow threat detection and monitor for unauthorized behavior. It works by analyzing your CloudTrail Events, VPC flow logs, DNS Logs… and then interpret that to find if something is wrong. You can find more resources about GuardDuty here :
    • AWS has the ‘Service Control Policies’ that will allow you to control what users can do. As for Azure Policies, it stands on top of permission. So even if you have the permissions to do something, if there is a Service Control Policy that explicitly deny you from doing something, then you will be refused. As an example, you can create a policy that will prevent users from disabling AWS CloudTrail. You can see more at
  • GCP
    • GCP Organization Policy services is similar to Azure Policies and AWS Service Control Policies as it will allow you to control compliance across your entire resource hierarchy. Within a policy, you will be able to define a constraint that will be enforced. For example, you can create a policy with a constraint ‘Disable VM Nested Virtualization’ to ensure that none of the Virtual Machine in your GCP environment has Virtual Machines running inside. You can see more about GCP Organization Policy here:
    • Cloud Security Command Center (Cloud SCC) – Still in alpha at the time of the article (30/08/2018) – is a tool that provide you multiple information that is comparable to Azure Security Center and AWS Guard Duty. It does Anomaly Detection by detection potential account hijacking and it also gives you the ability to display a list of all the assets you have in your GCP project with a number of warning foreach of these assets.

So, as you can see, AWS, Azure & GCP offer very good tools (with a lot of similitude) so you may wonder what Cloudockit can bring into the table in addition to built-in Cloud providers feature.

To understand why we have developed the Compliance Rules management in Cloudockit, here is a short story that we have seen with many of our customers …

  • The customer: “As a well-organized enterprise, we need to implement proper standards and we need to make sure that those standards are enforced.”
  • The Cloud expert: “That’s a really wise decision. We are going to first define the most important policies that we want to respect and then we will implement them using Azure Policies, AWS Service Control Policies and GCP Organization Policy (Ok, in real life, not so many cloud providers for one customer but 2 is very common…)”
  • The customer: “Here you are:
    • I want to deploy only in North Europe and East US Data-Center
    • The following 3 tags are mandatory: Cost-Center, Chargeback-Code, Application
    • I never want any Public IP deployed in my Azure subscription
    • All disks in all Cloud Provider should be encrypted”
  • The Cloud expert: “That’s done, I have implemented all the policies to enforce that”

… now …. 2 days later …

  • The customer: “the CEO has decided that we need to focus on a new major project for Germany and we need to use Germany for this one, we were blocked by the location policy, please remove it”
  • The Cloud expert: “OK”

… 3 days later

  • The customer: “One of our guys is trying to create a resource in the Azure Portal and has no time to script it and he cannot enter the tags in the portal. He is blocked by the Tag Policy”
  • The Cloud expert: “Ok, I will remove it”

And so, one and so force. While these can seem to be extreme cases, you will see that there are a lot of exception in real life and that’s what you often want to do is to Control but stay Agile instead of Blocking and Preventing from doing stuff.

That’s one of the reasons why we have created the Compliance Rule mechanism: allow you to track what is happening without blocking it.

Another reason is that all build-in constraints in Azure, AWS and GCP are pretty much limited: in Cloudockit, you will have the ability to create really advanced rules yourself.

In addition to that, not everyone is familiar with JSON to define rules so in Cloudockit you just do everything using the GUI.

Another reason is that we want to be a true Multi-Cloud Management tool so we think that defining rules should not have to be done individually in each cloud provider.

Let’s have a look at the different options that we offer with the compliance rules in Cloudockit.

First, you access that by using the Compliance Tab

Cloudockit compliance rules, using the compliance tab

As you can see, there are some built-in rules. Let’s click on one of them to see how it is structured:

Cloudockit buit-in rules preview

A Compliance Rule is mainly compound of two parts:

  • Information about the rule classification (Name, Description, Link, Type…)
  • Trigger about when the Compliance Rule is true

In the previous, screenshot, the rule CDK-AppService-RemoteDebuggingEnabled objective is to ensure that App Services have not Remote Debugging Activated as this is not recommended.

The trigger is as follow:

Trigger rules

What we mean with that is: If in the collection of App Services, there is an element (an App Service) that match the Condition “Remote Debugging Enabled” equals true, then give a warning. The warning will be automatically associated to the corresponding App Service.

As you can see, we can really build new rules and these can be complex rules like:

Building complexe rules with Cloudockit

With that rule, we say that we want to ensure that no Virtual Machine should contains a NIC that has an NSG that contains a rule whose address prefix is * as this is too much open. Notice that you can build even more complex rules by using Group and AND/OR Conditions.

These rules are available to AWS, GCP and Azure so you don’t need to learn multiple syntaxes.

On top of that, not only will Cloudockit gives you the warnings that you want but it will also automatically generate your Azure, AWS and Google Cloud Documentation & Diagrams which is really useful to ensure that your environment is compliant. Indeed, compliance is not only a matter of ensuring that some technical best practices are met but this is also ensuring that what has been architected is what is really deployed: that’s where automatic document & diagrams generation comes into play.