Demo only — This is a proof-of-concept. Do not deploy to production without vetting security guardrails and understanding the unsupported JAR patch.

Summary

  • Goal: Enable AWS asset discovery from ServiceNow by running the MID Server on AWS EKS Auto Mode — without static AWS keys or self‑managed EC2 instances.
  • How: Patch mid.jar so the MID Server can use EKS Pod Identity first, with instance profiles as a fallback.
  • What you get: Pod‑scoped, auto‑rotated AWS credentials for discovery, a three‑tier IAM role model, and a CDK app that deploys everything end‑to‑end.
  • Who this is for: ServiceNow / cloud platform engineers who own both AWS and ServiceNow and need a repeatable story for AWS asset discovery.

The Problem

The ServiceNow MID Server is used for AWS asset discovery — it discovers AWS resources (EC2, ECS, etc.) by calling AWS APIs and syncs them into ServiceNow. It needs AWS credentials. The official MID Server only supports two methods: static IAM user keys and EC2 Instance Profile (IMDSv2). Neither works on EKS Auto Mode — there are no user-managed nodes for Instance Profiles, and static keys are a security anti-pattern.

EKS Pod Identity solves this by injecting temporary, pod-scoped credentials. But the MID Server’s credential resolver doesn’t know about Pod Identity. So we patch mid.jar to check Pod Identity first, with Instance Profile as fallback.

AWS Credential Models for ServiceNow Cloud Discovery

# Credential Model Runs On How It Works ServiceNow Support Trade-offs
1 AWS IAM User (Static Keys) Anywhere Create an IAM user with programmatic access. Store Access Key ID and Secret Access Key in ServiceNow. Fully supported ⚠ Security risk: Long-lived credentials. Requires manual key rotation. Keys in ServiceNow add attack surface.
2 AWS EC2 Instance Profile EC2 instance Attach an IAM role to the EC2 instance. ServiceNow uses credential-less discovery via IMDSv2. No keys stored. Fully supported ⚙ Management overhead: You own the EC2 lifecycle — OS patching, AMI hardening, capacity planning.
3 AWS IRSA EKS standard mode Associate an IAM role with a K8s ServiceAccount via OIDC. Requires IMDS hop limit set to 2 on node group. Supported (with config) ℹ Node management: EKS standard mode requires managing node groups, AMIs, OS patching, kubelet upgrades.
4 AWS EKS Pod Identity Most Secure Patch Required EKS Auto Mode Associate an IAM role with a K8s ServiceAccount via Pod Identity. EKS injects credentials into the pod. Requires patching mid.jar. Not supported ✓ Most secure: Pod-scoped, auto-rotated, no static secrets. ⚙ Requires unsupported JAR patch — re-patch on each MID Server upgrade.

Why Pod Identity on EKS Auto Mode?

  • EKS Auto Mode has no user-managed nodes, so EC2 Instance Profiles don’t apply
  • Pod Identity provides pod-scoped, temporary credentials with automatic rotation
  • No static AWS keys to store, rotate, or leak
  • The trade-off is the unsupported JAR patch — weigh this against your security and support requirements

Architecture

The three-tier IAM role architecture mirrors ServiceNow’s Model 3 (Accessor → Management → Member) discovery pattern. In production, these roles would be in separate AWS accounts. For this demo, all three live in the same account.

⚙
EKS Pod
MID Server
EKS Pod Identity
🔑
Pod Identity Role
Accessor
sts:AssumeRole
🔑
Management Role
Central Hub
sts:AssumeRole
🔑
Discovery Role
Per Account
Read-only APIs
☁
AWS Resources
EC2, ECS, etc.

Credential flow (sequence)

Accounts — demo vs prod: In the demo, Account A, B, and C are a single AWS account. In production: A = shared/tools (where EKS and the Pod Identity role live), B = management account (hub role), C = workload accounts (discovery role and the resources you scan).

sequenceDiagram participant Pod as MID pod Account A EKS participant PodId as Pod Identity role Account A participant Mgmt as Management role Account B participant Disc as Discovery role Account C participant AWS as AWS APIs Account C Note over Pod,AWS: Demo A B C same account Prod A tools B mgmt C workloads Note over Pod,PodId: Step 1 Pod Identity Pod->>PodId: ServiceAccount to IAM role Account A PodId-->>Pod: Short-lived credentials Note over Pod,Mgmt: Step 2 Assume B Pod->>Mgmt: sts:AssumeRole TagSession Mgmt-->>Pod: Session as B Note over Pod,Disc: Step 3 Assume C Pod->>Disc: sts:AssumeRole TagSession Disc-->>Pod: Session as C Note over Pod,AWS: Step 4 Discover Pod->>AWS: ec2 ecs Describe List AWS-->>Pod: Inventory Note over Pod: Step 5 CMDB Pod->>Pod: To ServiceNow

Detailed architecture

The next figure is the same story as above, drawn as CDK-shaped boxes. Names and IAM live in the CDK source if you change anything.

Accounts — demo vs prod: Same as the sequence diagram — demo uses one account for A, B, and C. In production: A = shared/tools, B = management, C = workload accounts (discovery roles and resources).

About the MID password in this demo
CDK drops it into a Kubernetes Secret from deploy context so the stack comes up fast. For real use, put the password where you already keep secrets—Secrets Manager (often with External Secrets), or your CI/CD vault—and don’t commit it.

graph TB subgraph SN["ServiceNow"] SNOW["ServiceNow HTTPS to MID"] end subgraph ACCA["Account A"] subgraph EKSMID["EKS MID Server"] subgraph NS["Namespace servicenow"] POD["StatefulSet mid-server"] SA["ServiceAccount servicenow-mid-server"] CM["ConfigMap mid-server-config"] end PODA["Pod Identity association"] end PODID["servicenow-pod-identity-role
Trust pods.eks.amazonaws.com
Assume Account B TagSession self"] end subgraph IAM_M["Account B"] MGMT["servicenow-management-role
Trust Account A Orgs read only
Assume Account C TagSession"] end subgraph IAM_D["Account C"] DISC["servicenow-discovery-role
Trust Account B ec2 ecs read"] end subgraph WL["Account C workload resources"] EC2["EC2"] ECS["ECS"] end SNOW <-->|HTTPS| POD POD --> SA POD --> CM SA --> PODA PODA --> PODID PODID -->|sts:AssumeRole| MGMT MGMT -->|sts:AssumeRole| DISC DISC -->|Describe/List| EC2 DISC -->|Describe/List| ECS style POD fill:#e1f5ff style PODID fill:#fff4e1 style MGMT fill:#ffe1e1 style DISC fill:#e1ffe1

What Gets Deployed

The CDK app deploys five stacks:

Stack Resources
EksMidServerEcrStack Private ECR repository with image scanning and lifecycle rules
EksMidServerVpcStack VPC with 2 AZs, private subnets, NAT gateway
EksMidServerClusterStack EKS Auto Mode cluster with control plane logging
EksMidServerRolesStack Three-tier IAM roles: Pod Identity → Management → Discovery
EksMidServerAppStack Namespace, ServiceAccount, Pod Identity association, ConfigMap, Secret, StatefulSet

Guide

The full step-by-step guide is split into two parts:

  1. MID Server JAR Patching — Decompile mid.jar, add Pod Identity support, recompile, build Docker image, push to ECR
  2. Deployment and Discovery Guide — Deploy CDK stacks, verify the MID Server, configure credential-less cloud discovery in ServiceNow

Source Code

The complete CDK app, example Dockerfiles, and documentation are available in the GitHub repository.

This is a demo/POC implementation. The mid.jar patching described here is unsupported by ServiceNow. See the repository README for full disclaimers.

Updated: