Back to blog

When Security Met Kubernetes: My SentinelOne Journey on GKE

·5 min read
GKEKubernetesSentinelOneDevOpsCloud Security

Listen to this article· 3 min

Photo by Evgeni Tcherkasski on Unsplash

There is a moment in every developer's career when someone says:

We need to install a security agent on the Kubernetes cluster.

And you think: "Okay. How hard can it be?"

Famous last words.

I had worked with React, React Native, APIs, CI/CD and application deployments, and I was getting deeper into GCP and Kubernetes. But most of my work still started from a familiar idea:

CodeBuildDeployApplication works

Then I was asked to deploy SentinelOne on GKE. It turned out not to be an "install something" problem at all. It touched Kubernetes, Linux, containers, Helm, networking, registries, service accounts, CI/CD and production operations — a small sentence with a very large architecture diagram hiding behind it.

What Were We Actually Trying to Do?

The goal: protect the workloads running on our GKE clusters with the SentinelOne agent.

SentinelOne's Kubernetes agent runs as a DaemonSet, which means Kubernetes keeps one agent pod on each worker node:

GKE cluster — one agent per node
  • Node 1application + SentinelOne agent
  • Node 2application + SentinelOne agent
  • Node 3application + SentinelOne agent

A Deployment says "I need 3 replicas." A DaemonSet says "I need my agent wherever there is a node to protect." That's exactly what security and monitoring agents need — and it meant I was no longer thinking only about applications, but about the nodes running them.

The First Lesson: Kubernetes Has Layers

I knew the usual concepts:

  • Pod
  • Deployment
  • Service
  • Ingress
  • Namespace
  • Node

Security tooling forced me to look deeper:

  • Where does the agent actually run?
  • What does it need from the node?
  • What permissions does it require?
  • How does it get its image?
  • How does it communicate outside the cluster?
  • What happens when a node is added or removed?
  • What happens during a cluster upgrade?

An application developer can think "I deploy the container." A platform engineer has to ask:

Platform engineer
  • Where does that container run?
  • Under which identity?
  • With which permissions?
  • Through which network?
  • From which registry?
  • And what happens when infrastructure changes?

That's a much bigger question.

Helm Made It Easier... and More Interesting

SentinelOne maintains an official Helm chart, so instead of hand-maintaining a pile of manifests, the deployment could be managed as a Helm release:

From chart to agents
  1. 01Helm
  2. 02SentinelOne chart
  3. 03Kubernetes resources
  4. 04DaemonSet
  5. 05One agent per relevant node

At first a Helm chart looks like YAML with some template magic sprinkled on top. Later you realize it's a reusable deployment package — and once it's part of company infrastructure, versioning it and wiring it into the delivery process really pays off.

Then Reality Added a Proxy

In a corporate environment, it's never just helm install. Our network went through an HTTP proxy, which added a dependency:

SentinelOne agentCorporate proxyExternal service

And a new set of questions:

  • Does the pod know about the proxy?
  • Does the required traffic go through it?
  • Can DNS resolve what it needs?
  • Can the node reach the required endpoints, on the required ports?
  • Is the agent actually connected?

Kubernetes networking doesn't exist in isolation. A pod can be perfectly healthy from Kubernetes' point of view and still unable to reach an external service:

  • kubectl saysPod = Running ✅
  • Your brain saysWhy isn't the agent connected? 🤨

Both can be true.

Then Came the Registry

In an enterprise, you don't necessarily pull images straight from a public registry. Ours came through an internal artifact repository:

Where the image comes from
  1. 01Helm
  2. 02Kubernetes
  3. 03Image reference
  4. 04Internal artifact repository
  5. 05GKE node
  6. 06SentinelOne container

Is the image available? Can the node reach the registry? Are the credentials right? Is the requested version there? And most importantly: is the version you think you're deploying actually the one the cluster is running?

I learned not to trust assumptions. Check the image, the pod, the events, the logs — then check again.

The Version Matters

With security software, version management is critical. We deployed a specific, tested agent version — not "the latest." There's a big difference between "install SentinelOne" and "deploy this tested version of SentinelOne, through this approved artifact path, into this GKE environment." The second is how production engineering works. Versions need to be:

  • Known
  • Tested
  • Tracked
  • Reproducible
  • Upgradeable

"Latest" is not the same thing as "approved for production."

Dev First, Production Later

We validated everything in a development GKE environment before introducing a new security component into production:

Dev first, production later
  1. 01Development
  2. 02
    Validate deployment
    Image pullNetwork accessAgent status
  3. 03Production

It sounds basic. It isn't. The more important the infrastructure, the more boring you want its deployment to feel.

Then I Started Thinking About CI/CD

Once infrastructure lives in a GitLab repository, a question appears: why are we doing this manually? Instead of a developer running kubectl or helm against a cluster, the better long-term model is:

The better long-term model
  1. 01GitLab
  2. 02
    CI
    ValidateScanPackage
  3. 03Artifact repository
  4. 04CD
  5. 05GKE

This was the real shift: not learning to deploy an application, but learning how organizations standardize infrastructure changes. When the deployment is code, you can review it. In Git, you can version it. In CI/CD, you can automate it. And when something breaks six months later, you can actually figure out what changed.

Security Became Part of My Day-to-Day

Security used to feel like something that happened elsewhere: security teams secure, developers build, operations runs things. Cloud blurs those lines — a security agent on GKE gives the application, platform, infrastructure and security teams a reason to care about the same deployment.

Security isn't only "is the application vulnerable?" It's also:

  • Who can access it?
  • What is running on the node?
  • What image are we deploying, and where did it come from?
  • What permissions does the workload have?
  • Can the agent reach its control plane?
  • What happens when the cluster scales?

Suddenly IAM, registries, networking, Kubernetes and security are one conversation.

The Agent Wasn't the Hardest Part

Looking back, the agent itself was easy. Everything around it was the work:

Everything around the agent
  • Kubernetesa DaemonSet on GKE
  • Networkthe corporate proxy
  • Registrythe internal artifact repo
  • IAMidentities & permissions
  • CI/CDhow it gets deployed

The individual tools aren't the challenge. The challenge is making them behave like one system — which is also why platform engineering is different from "knowing Kubernetes":

The path between the boxes
  1. 01Developer
  2. 02Application
  3. 03Container
  4. 04Artifact Registry
  5. 05
    GKE
    IAMNetworkingSecurityScalingObservability

The job isn't only knowing what each box does. It's making the path between the boxes reliable. Here, the requirement came from security, the workload ran on Kubernetes, the infrastructure was GCP, the deployment used Helm, the image came through an internal repository, the network was restricted, the change had to fit CI/CD — and all of it had to coexist with production applications. That's platform engineering territory.

From React to Runtime Security

A few years ago I was thinking about components, state, props, navigation and mobile layouts. Now I'm debugging pods, nodes, DaemonSets, Helm releases, images, IAM and proxies.

Strangely, the mindset is the same: investigate, form a hypothesis, check the evidence, change one thing, test again, don't assume. The tools changed; the debugging mindset didn't. That's why moving into cloud and platform engineering never felt like starting from zero — just the same instincts applied to a much bigger system.

Final Thought

The SentinelOne deployment looked small on paper and turned out to be a crash course in cloud engineering. Modern software isn't only the code we write — it's also where that code runs, how it gets there, how it communicates, what protects it, who can access it, and what happens when the infrastructure changes underneath it.

Sometimes the fastest way to learn cloud engineering isn't another tutorial project. Sometimes someone just says:

"We need this security agent running on the cluster."

And Kubernetes answers:

"Sure. Let's talk about networking, IAM, Helm, registries, nodes, CI/CD and production." 😄

That's how you learn.

…

Up to 50 claps per reader

All posts
Share