Table of Contents | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Overview
Data Theorem provides several integrations that collect information about your GKE deployments to help you manage your Kubernetes security posture. Additionally, like the data collected from all Data Theorem integrations, we send your GKE information to our analyzer to build a deep, full-stack understanding of your applications and resources they rely on.
...
GCP Account Integration
GCP Load Balancer Log Analysis Integration
Kubernetes In-Cluster Helm Chart Integration
Kubernetes Control-Plane Integration
We recommend enabling the GCP Account Integration and the GCP Load Balancer Log Analysis Integration, and optionally, one of the Kubernetes integrations.
KSPM Integrations
GCP Account Integration
The close integration of GKE and Google Cloud means that just by onboarding your GCP account we good visibility into your GKE clusters and the GCP resources they use.
How to enable this integration: https://datatheorem.atlassian.net/wiki/x/AoBQAg
GCP Load Balancer Log Analysis Integration
The Data Theorem GCP Load Balancer integration forwarding HTTP request logs from your GCP load balancers to a log sink that publishes HTTP request metadata to a Data Theorem Pub/Sub queue.
...
Data Theorem strongly recommends creating the sink at the organization level to maximize discovery, and to then use the sink’s log filter to limit which logs are sent to Data Theorem.
Information Collected
This integration collects non-sensitive runtime information about requests made to your load balancers. No request or response bodies or sensitive headers are collected.
Here is an example:
Pre-requisites
Make sure that
Logging
is enabled on the Load Balancer Backend Service ConfigurationCheck this link for more information on how to enable Logging on the Load Balancer Backend Service
Create
...
a Pub/Sub
...
Topic For The Logs Routing Sink
Info |
---|
If creating a logs routing sink at the organization or folder level, this should be your Data Theorem integration project |
...
, otherwise it can be in the same project as where you plan to create the sink |
In the GCP console, switch to the project where you will create the Pub/Sub topic
Using the left-hand side menu, select Pub/Sub (in the Analytics section), and then select Topics
...
, Click on Create Topic
In Create Topic Flow
Use
datatheorem-logs-processing
as the topic ID
...
Uncheck "Add a default subscription"
...
No other options are needed
...
Click Create to create the topic
...
an confirm not other boxes are checked
Click Create
...
Create The Cloud Logging Sink
Info |
---|
If creating the sink at the organization (or folder) level, switch from the project to your organization (or folder) |
Using the left-hand side menu, select Logging (in the Observability section), then within the Configure subsection, select Log router
Click
...
Create Sink
In the Sink details section, input
datatheorem-logs-processing
as the sink name, and click NextYou will have to fill in the full ID of the sink destination. For a Pub/Sub topic, it must be formatted as (but replace the
[PROJECT_ID]
and[TOPIC_ID]
with the topic's information):pubsub.googleapis.com/projects/[PROJECT_ID]/topics/[TOPIC_ID]
Click Next
...
Choose Logs to Include in Sink
Info |
---|
You can click on Preview logs to see which logs will be included |
...
Complete the sink creation by clicking on Create sink
Create a Service Account
...
In the Choose logs to include section, add the following inclusion filter:
resource.type="http_load_balancer"
You can click on Preview logs to see which logs will be included
Click Create sink
...
Create a
...
Service Account
...
To Authenticate Log Forwarding
In the GCP on console, switch back to the GCP project where the Pub/Sub topic was created
Then using the left-hand side menu, select IAM & Admin section, and then select Service Accounts
Click on Create Service Account at the top
In the Service account details section, input
datatheorem-logs-processing
as the name
...
Click CREATE AND CONTINUE
Allow Service Account to Assume Role To Authenticate Log Forwarding
In the Grant this service account access to project section
...
Select a role
Filter for “token creator” in the role filter
Select
Service Account OpenID Connect Identity Token Creator
...
role to allow Pub/Sub to generate OIDC tokens that will be used to authenticate requests
Complete the service account creation by clicking on Done
...
Collect Service Account’s OAuth2 ClientId
On the service account listing, above the table, input
datatheorem-logs-processing
to retrieve the newly created service accountCopy the value from the OAuth 2 Client ID column and register it below
...
Create a Pub/Sub
...
Subscription In The Same GCP project As The Pub/Sub
...
Topic
Using the left-hand side menu, select Pub/Sub (in the Analytics section), then within the PUB/SUB subsection, select Subscriptions
Click on CREATE SUBSCRIPTION at the top
Input
datatheorem-logs-processing
as the subscription IDClick on Select a Cloud Pub/Sub topic and input
datatheorem
to filter the previously created Pub/Sub topicIn the Delivery type section, select Push
In the Endpoint URL text box, input
https://api-protect-api.securetheorem.com/logs/v1/ingest/gcp_load_balancers
...
Check on the Enable Authentication checkbox below the Endpoint URL, and select the previously created service account
In the Retry policy section at the bottom, change the retry policy in the subscription to exponential backoff instead of immediate retry
...
Click CREATE
Kubernetes In-Cluster Helm Chart Integration
Overview
This integration uses a Helm chart to creates create a discovery
deployment in the datatheorem
namespace in your Kubernetes cluster. The deployment is not “in-line” for any of your cluster’s services. The application is stateless and designed to consume almost no resources, and it should not require any autoscaling.
It uses a the datatheorem-service-account
bound to the datatheorem-cluster-role
with the following permissions for read-only access on a limited set of cluster resources:
Code Block | ||
---|---|---|
| ||
rules: - apiGroups: - "*" resources: - deployments - pods/log - pods - services - endpoints - persistentvolumeclaims - ingresses - gateways verbs: - list - get - watch |
and a cluster role binding the datatheorem-cluster-role
to the datatheorem-service-account
.
Installation
Step 1 : Extract all the items which you should receive during the onboarding process.
Code Block |
---|
unzip DataTheorem-APIProtect-K8S_PROTECT.zip |
Step 2 : Verify you are configured for the correct kubernetes cluster
Code Block |
---|
kubectl config current-context |
Step 3 : Install API Protect
Add mirroring to the chosen endpoint. This step must be repeated for each endpoint.
Code Block |
---|
helm install k8s-protect \ ./k8s-protect \ --create-namespace \ --namespace datatheorem \ --wait |
Step 5 : Verify the deployment
It should look something like this
...
Code Block |
---|
helm test -n datatheorem k8s-protect |
Finished.
Un-Installation should it be required
Code Block |
---|
helm uninstall -n datatheorem k8s-protect |
Kubernetes Control-Plane Integration
...