[WIP]Queries for gke cisv1.3.0

[saisirishreddy]

Checklist

• Issue(s) linked

[rajlearner17]

@saisirishreddy, thanks for helping; I would like to get some clarification for this PR; what is the purpose of these new queries? Are you planning to send PR for the new benchmark, i.e. GKE-CISv1.3.0. I don't see any existing query update except below control

control "gke_restrict_pod_traffic" {
  title = "Check that GKE clusters have a Network Policy installed"
  query = query.kubernetes_cluster_network_policy_installed

  tags = merge(local.policy_bundle_kubernetes_common_tags, {
    cft_scorecard_v1 = "true"
    severity         = "high"
  })
}

CC @bigdatasourav

[saisirishreddy]

@rajlearner17 , This PR is just to populate the queries for GKE-CISv1.3.0.
I have some work in progress on my fork, the idea is to have GKE-CISv1.3.0 compliance checks, similar to cis_v200.
Would you propose any approach, let me know if there are other dependencies..
CIS Google Kubernetes Engine (GKE) Benchmark v1.3.0 PDF.pdf

[rajlearner17]

@saisirishreddy Thanks for attempting to bring CIS GKE 1.30

Any specific reason why you selected CIS GKE 1.3.0 over CIS GKE 1.4.0?

While we initially were still deciding whether to bring such provider-specific Kubernetes compliance separately or bring in general CIS of Kubernetes, which can address all cloud providers. However, I understand that. Short-falls few provider-specific checks.

While you are proceeding with this, I would like to contact others to provide feedback so we are better covered with the right approach. The reason is once we do this for GCP, we may have an interest in Amazon (EKS) (1.3.0), Azure (AKS) (1.3.0), OCI (OKE) (1.3.0) etc. Better we get aligned with the expectation on this. You will hear from us on this thread.

CC @cbruno10 @johnsmyth

Cheers!

[saisirishreddy]

CIS GKE 1.4.0 would work too and can be used as latest reference. I already have my local queries with reference to CIS GKE 1.4.0.

• Also I am only focusing on the cloud provider specific checks that can be performed without accessing the cluster itself like kubelet config.

• Any check that can be performed from Google API's can be included.

• Should that be made available to all users ..? I believe some users can get benefited, I also understand that users might expect the same parity for other Clouds (AWS, Azure etc) that Steampipe community supports.

• While that is being discussed, would leaving the queries in the policy bundle without being referenced pose any problem..?

Whatever the approach, happy to contribute. thanks

[cbruno10]

Hey @saisirishreddy , thanks again for raising this PR!

Looking at GKE CIS v1.3.0 and v1.4.0, along with Azure AKS CIS v1.3.0 and AWS EKS CIS v1.3.0, it seems like all 3 CIS reports have a mix of controls that are checked/remediated either using kubectl, e.g., 4.2.1 Minimize the admission of privileged containers (Automated) or the GCP/Azure/AWS console/CLI tools, e.g., 5.6.6 Consider firewalling GKE worker nodes (Manual).

Some of the kubectl controls in GKE CIS v1.4.0 are also present in Kubernetes CIS v1.7.0, e.g., 4.6.2 Ensure that the seccomp profile is set to docker/default in your pod definitions (Manual) in GKE CIS v1.4.0 is in Kubernetes CIS v1.7.0 Benchmark: 5.7.2 Ensure that the seccomp profile is set to docker/default in your Pod definitions .

So one approach we could take is:

• Create a separate mod for AKS, GKE, and EKS CIS reports
• Each new CIS version will be a separate benchmark, e.g., GKE v1.3.0 and v1.4.0 will each have their own benchmark in the GKE CIS mod
• These new mods can use the Kubernetes Compliance mods, along with AWS/Azure/GCP Compliance mods, as mod dependencies so they can reference existing controls or queries in those mods
• For any queries or controls not in the mod dependencies, if they are generally good checks to include in those mods, we should add new queries and queries into the Kubernetes/AWS/Azure/GCP Compliance mods and reference them as mentioned above, instead of adding them into the AKS/EKS/GKE Compliance mods directly

@saisirishreddy @rajlearner17 Thoughts on the proposal above?

[rajlearner17]

@cbruno10 Using mod dependencies is a great idea and a benefit of the Steampipe feature. However, I not have much idea as of now about the level of interdependence, such as

• Cloud provider-specific CIS e.g. GKE CIS 1.x.x vs Steampipe provided hybrid Kubernetes, here I see a few commonalities mentioned by @cbruno10

• Cloud provider-specific CIS e.g. GKE CIS 1.x.x vs other Cloud provider CIS such as AWS EKS/Azure AKS, the standard common controls must be analyzed

Maybe we have to plan how to make a start, whether by analyzing all together and documenting the required changes first
or
starting with GKE, then checking what mod dependency factors are with Kubernetes compliance (available in Steampipe), and starting building from there for other providers.

Here is the reference to Mod Dependencies

[cbruno10]

@rajlearner17 I think for whatever CIS report we start with, we could go control by control and as we're adding each one, see if it's an existing control/query in the Kubernetes or cloud Compliance mod. We may end up with most controls being referenced or very few, but even if there are just a few I think it's beneficial to use mod dependencies where we can.

[cbruno10]

@saisirishreddy I've created #123 to continue the discussion since this PR was closed due to merging of the release/v0.20 branch and unfortunately can't be re-opened

[saisirishreddy]

Sure thank you, I agree that referencing to the Kubernetes mod where applicable helps along with the Corresponding Cloud queries. However I think handling the config files might be challenging as the access requirements are not the same.