How to Configure AWS SageMaker TeamCity for Secure, Repeatable Access

CI jobs fail for all sorts of silly reasons, but the worst is when permissions collapse mid-deploy and you’re staring at an AccessDenied message you didn’t earn. If you’re training models in AWS SageMaker and relying on TeamCity for orchestration, getting identity and access right can feel like wrestling two polite but distant coworkers into a handshake. Let’s fix that.

AWS SageMaker is where your ML lives. It spins up scalable compute for training, inference, and pipelines. TeamCity is your build brain, running versioned workflows that package and deploy code automatically. Bring them together, and you get a feedback loop: new code trains new models, which flow straight into test environments without manual glue code or coffee-fueled copy-paste moments.

The logic is straightforward. TeamCity executes jobs using service accounts bound to AWS IAM roles. Those roles should have scoped policies granting SageMaker access to relevant artifacts in S3, plus permission to start and monitor training jobs. The trick is making it reproducible and secure. Store credentials in TeamCity’s AWS Connections plugin using temporary tokens or OpenID Connect (OIDC) federation with AWS IAM. That way, no long-term keys leak into build logs—a small miracle in modern DevOps hygiene.

If you hit auth errors, check three places first. One, that the TeamCity build agent’s OIDC identity maps correctly to the intended IAM role. Two, that you delegated SageMaker policies at the role level, not the resource level. And three, that the SageMaker execution role allows “passrole” from that identity. Those checks solve 90% of CI pipeline permission mysteries.

Useful outcomes follow fast:

• Continuous model builds tied to Git commits
• Centralized role management through AWS IAM and OIDC
• Eliminated secrets from build configs
• Auditable, ephemeral access for compliance teams
• Faster rollback and retrain loops when experiments fail

For developers, this means no hard-coded keys, shorter build queues, and fewer interrupted runs. Onboarding a new engineer becomes a single identity grant instead of a half-day key rotation ritual. Velocity goes up, and cognitive friction goes down.

Platforms like hoop.dev turn those access rules into guardrails that enforce policy automatically. Instead of manually wiring IAM and OIDC mappings, you define who can trigger what, and hoop.dev ensures every workflow respects that identity contract. It’s how real teams keep IAM sane while scaling automation.

Quick answer: To connect AWS SageMaker and TeamCity securely, use OIDC integration between TeamCity and AWS IAM. Configure roles for SageMaker access, store no static keys, and limit policies to specific job scopes for reproducible, compliant automation.

As AI assistants creep into the CI/CD landscape, that foundation matters even more. Automated bots pushing code or triggering retrains still need proper role boundaries. Federated identity keeps the robots in line, with traceable actions and revocable trust.

Set it up once, and you stop worrying about whose token did what. You start focusing on better models, cleaner pipelines, and fewer late-night deploy regrets.

See an Environment Agnostic Identity-Aware Proxy in action with hoop.dev. Deploy it, connect your identity provider, and watch it protect your endpoints everywhere—live in minutes.