Announcement

Use Steampipe to scan Kubernetes configurations, manifest files, and helm charts

Query all aspects of your Kubernetes environment to answer ad-hoc questions or scan for security best practices.

Steampipe Team
5 min. read - Oct 04, 2023
Query all aspects of your Kubernetes environment to answer ad-hoc questions or scan for security best practices.

Kubernetes environments are complex. It's a challenge to keep track of clusters, jobs, namespaces, deployments, nodes, pods, and roles, to ensure everything is configured securely, and to visualize how the parts fit together. The Kubernetes plugin made it possible to write SQL queries to answer questions about your K8s environment. Building on that foundation, the Kubernetes Compliance mod added benchmarks and controls for CIS, NSA, and CISA best practices. Then the Kubernetes Insights mod delivered a wealth of instant answers to common questions, along with powerful relationship graphs to help you visualize the environment.

At first all K8s queries — your own custom ones, and those that power benchmarks and dashboards — fetched data from live clusters. Now we've enhanced the plugin with the ability to query manifests and helm charts too. Let's look at some queries and controls that use the new capability with a simple helm chart example.

Query helm charts and Kubernetes deployments

This query returns two rows from the kubernetes_deployment table.

select
source_type,
name,
creation_timestamp
from
kubernetes_deployment
where
name = 'cherry-chart'
order by
creation_timestamp desc
+----------------------+--------------+---------------------------+
| source_type | name | creation_timestamp |
+----------------------+--------------+---------------------------+
| helm_rendered:charts | cherry-chart | <null> |
| deployed | cherry-chart | 2023-10-03T10:32:09-07:00 |
+----------------------+--------------+---------------------------+

Why two rows? We've configured the plugin's source_types argument as ["deployed", "helm"]. So we're querying both the rendered helm chart — which doesn't know the creation_timestamp — and the deployment which does.

Scan helm charts and Kubernetes deployments

The Kubernetes Compliance mod builds on this foundation. For example, it's a best practice not to use the default namespace for a ServiceAccount. There's a control to check for that, based on this query.

select
coalesce(uid, concat(path, ':', start_line)) as resource,
case
when namespace = 'default' then 'alarm'
else 'ok'
end as status,
case
when namespace = 'default' then name || ' uses default namespace.'
else name || ' not using the default namespace.'
end as reason,
name as service_account_name,
coalesce(context_name, '') as context_name,
namespace,
source_type,
coalesce(path || ':' || start_line || '-' || end_line, '') as path
from
kubernetes_service_account;

Running the control shows that the helm chart and deployment are both green: no default namespace.

helm green deploy green

Now somebody improperly sets the namespace to default in serviceaccount.yaml.

{{- if .Values.serviceAccount.create -}}
apiVersion: v1
kind: ServiceAccount
metadata:
namespace: default
name: {{ include "buildachart.serviceAccountName" . }}
labels:
{{ include "buildachart.labels" . | nindent 4 }}
{{- end -}}

Now the control shows a mismatch between the chart and the deployment.

helm red deploy green

But we're going to deploy anyway.

helm upgrade my-cherry-chart buildachart/

Now the chart and the deployment are both in the alarm state.

helm red deploy red

Let's properly set a namespace in the helm chart.

{{- if .Values.serviceAccount.create -}}
apiVersion: v1
kind: ServiceAccount
metadata:
namespace: cherry # must not be default!
name: {{ include "buildachart.serviceAccountName" . }}
labels:
{{ include "buildachart.labels" . | nindent 4 }}
{{- end -}}

Now we're back to a mixed result: the chart is green, but the deployment is still red.

helm green deploy green

After redeploying, we're back to green all around.

helm green deploy green

See it in action

A wealth of queries and controls

We've looked at just one of the 790 controls provided by the Kubernetes Compliance mod. Collectively they support best practices defined by CIS Kubernetes v1.20, CIS v1.7.0, and NSA and CISA Kubernetes Hardening Guidance v1.0. Those controls build on 781 queries. Use them out of the box, or reuse and remix to suit your needs. And please do let us know how it goes!