Trend Micro Cloud One workload security India: a Bengaluru fintech’s Friday after the amber
06.42 AM. The Slack ping was not in caps this time. A senior cloud engineer at our 180-person Bengaluru fintech had paged me to ask if a sustained CPU spike on one EKS worker was expected. It was not. By 09.14 IST, Trend Micro Cloud One Workload Security threw an amber. Process behaviour anomaly. Outbound connection to a stratum pool we did not recognise. That is when the trend micro cloud one workload security india story stopped being a 2026 roadmap slide and became a working Friday. The 11-domain DPDP audit prep playbook told me which controls were on the auditor’s re-test list. Workload posture and runtime were two of them.
The first hour after the amber
I did not start with the alert. I started with the architecture. Six months ago this fintech ran on-prem in a Whitefield colocation. The CTO had finally said yes to a hybrid shift. Lending on AWS EKS. Wallet on Azure AKS. KYC pinned to India regions with a documented residency posture. Forty-seven EKS nodes live, seven AKS pools, six container registries.
Arre, the posture work had not kept up. Cloud One was bought during the move. The Workload Security agent was on every node. Conformity was ingesting AWS and Azure findings. Container Security was watching ECR. But four weeks ago, to clear a wallet release, a senior engineer had disabled the pipeline gate that fails a build on Container Security findings. That is a Friday-before-quarter-end story. It is not a Trend Micro story.
What the trend micro cloud one workload security india console actually told me
The runtime event in Trend Micro Cloud One Workload Security read in plain text. Container ID. Image digest. Process tree. Parent was a node init script. Child was a sidecar from a public ECR image we had pinned for a logging shim. Grandchild was an outbound TCP session to a stratum mining pool over port 3333. The behaviour engine matched cryptominer indicators from the Smart Protection Network. Confidence high. Action default was log-and-alert because the policy was set to monitor. Production should have been block. That was the second thing I had got wrong.
Bas, the fix at the EKS layer was four steps. Kill the node. Drain the group. Tighten Karpenter. Audit the service-account IAM role. The role had Action: ec2:* on the whole region. A DevOps engineer had set it during a March debugging session and never tightened it.
The vendor call that earned its place
I called the Trend Micro Cloud One India SE at 11.40 IST. She did not start with a script. She asked which workloads were in scope, which policy mode each node group was in, and then walked me through a setting I should have known about. Application Control on Workload Security can lock down a node to a known-good binary set. For our production EKS, it should have been on. Conformity already had a rule that flagged Workload Security in monitor mode on production tags. That rule had fired for three weeks. Nobody had assigned it. That was the third thing I had got wrong.
I had assumed our Check Point Quantum perimeter plus Vision One on the M365 estate plus endpoint EDR added up to runtime workload coverage. It did not. Vision One talks to the M365 tenant, endpoints, and a thin slice of identity. Cloud One talks to the cloud workloads. Same vendor on the bill. Different product on the screen.
The 60-second comparison table that decided the rest of the day
I drew this at 13.20 IST. The CTO asked the question every CTO asks at this point. Are we paying for what we are not using. Yes. And we are not using what we are paying for.
| Module | Watches | Before | After |
|---|---|---|---|
| Workload Security | EKS/AKS node runtime | Monitor mode | Block. App Control on. |
| Container Security | ECR/ACR scan plus runtime | Gate disabled | Re-enabled, admission block |
| File Storage Security | S3/Blob upload scan | KYC bucket only | 3 more buckets |
| Cloud Risk Management | Posture AWS+Azure | No owner | Owner, Slack, top 12 closed |
The CTO looked at row two and said the words every Indian fintech CFO has heard once before. Achha, who disabled that gate, and who signed the JIRA for re-enabling it. By 14.45 IST the platform lead had pulled it from Git history. The senior engineer had done it under a fast-track release approval. The release approval had checked the build green, not the gate. Process bug, not product bug.
The afternoon, in three small fixes
First, we rotated every AWS access key issued in the last 90 days that touched the EKS service account or the Karpenter controller. Nineteen keys. Three belonged to ex-employees who had left in April. Their off-boarding had revoked human access but not the long-lived programmatic keys. Jhamela. We added a Cloud Risk Management rule that flags any access key over 30 days old on a tagged production account, wired to the on-call Slack.
Second, we tightened the EKS service-account role from Action: ec2:* to a scoped list of seven actions against the production VPC and AMI family. That alone removed the path the spot instance had used. We tested it twice against the Karpenter scale-up. It held.
Third, we re-enabled the pipeline gate that fails a build on critical Container Security findings, and we added an admission controller in the EKS clusters that blocks pulls from any registry that is not our private ECR or one of three whitelisted public mirrors. That admission controller is the simple change I will explain to the auditor first. It removes the entire class of public-registry-sidecar risk in one configuration line.
The amber alert is the gift the on-call wanted at 4.30 last Friday
The senior engineer who had disabled the gate walked over at 16.10 IST. He was not defensive. He was the one who had paged me at 06.42 because the CPU spike did not look right. That is the team you want. He asked the right question. Yaar, would Workload Security have caught this if the image had been clean and runtime stayed benign for a week. Application Control and the runtime behaviour engine would have, on the first outbound stratum connection. The image scan would not have caught a behaviourally clean image.
This is the part the auditor wants in writing. Not the heroics. The boring policy that says runtime block on production node groups, Application Control on, public registry pulls blocked at admission. We will pin it to the SecOps wall. The Mumbai NBFC amber alert postmortem ended with a similar poster. I also called our Hyderabad SaaS friend who had the OAuth-token SharePoint recovery a fortnight ago. His was an identity-side gap. Mine was workload-side. Same lesson. The control had been bought. The configuration had drifted. The owner had not been assigned.
What we will tell the next auditor
The auditor will ask one question first. How is workload runtime risk monitored across your AWS and Azure footprints, who owns the policy, and how do you know the policy is live. Our answer is the screenshot, the JIRA workflow, the Slack channel, and the wall poster. He will also ask the DPDP-specific question. For personal data flowing through these workloads, what is your detection-to-response window and your evidence trail. The MeitY DPDP guidance is clear on this. The INR 250 crore penalty cap is not the only thing to fear. The board-pack finding is what fintech CISOs lose sleep over. Our Cloud One event log paired with Cloud Risk Management posture history gives the trail end to end. The Azure security fundamentals reference is also worth keeping handy for the AKS portion.
Sirius Star has stood up Trend Micro Cloud One for 30 plus Indian BFSI and fintech estates. The product gets bought during a cloud-shift. The configuration drifts. The auditor finds the gap. We close it. The Pune NBFC Okta rollout is the identity-side version of the same lesson.
Key takeaways
- Workload runtime and image scan are different controls. A clean image with bad runtime will defeat scan-only stacks.
- Monitor mode on a production node group is a board-pack finding. Move to block. Document the JIRA.
- Cloud Risk Management findings without an owner are not findings. Assign. Wire to Slack. Close the top twelve weekly.
- The pipeline gate is the simplest line of defence. Re-enable it. Block public registry pulls at admission.
FAQ
Does Vision One cover cloud workloads?
No. Vision One is the XDR layer for endpoints, email, identity and a thin cloud-app slice. Cloud One Workload Security is the agent and policy engine for VMs and Kubernetes nodes. Both are Trend Micro. Separate consoles, separate SKUs.
Does Workload Security run on AKS as well as EKS?
Yes. The agent runs on the node OS for both. Container Security adds image scan for ECR and ACR plus runtime container behaviour. Most Indian fintech estates buy the two layers together.
Where does Cloud One sit on DPDP evidence?
Workload Security event logs plus Cloud Risk Management posture history give a detection-to-response evidence trail across AWS and Azure. Paired with a SIEM, that trail is what Indian auditors ask for under the DPDP control around personal data processing systems.
What does an India fintech Cloud One rollout cost?
Pricing is per workload per month for Workload Security, per repository per month for Container Security, per AWS account or Azure subscription for Cloud Risk Management. For a 50-node EKS+AKS estate with 8 registries and 3 cloud accounts, all-in is typically INR 18 to 28 lakh per year before SE and rollout services.
P.S. Priya here. We shipped this exact playbook for a Mumbai NBFC two weeks ago. The auditor walked out with a clean workload finding on Day 9. If your cloud-shift is six months in and the Conformity findings are piling up unassigned, that is the moment to make the call. The amber alert is the gift the on-call wanted at 4.30 last Friday.
