OpsCanary
kubernetessecurityPractitioner

Building a Secure Internal Developer Platform with Kubernetes and GitOps

5 min read CNCF BlogMay 29, 2026Reviewed for accuracy
Share
PractitionerHands-on experience recommended

In today's fast-paced development environment, building a cloud-native internal developer platform is essential for teams looking to enhance productivity and security. This approach allows you to manage your infrastructure and applications seamlessly while ensuring that security is integrated into every step of the process. By using Kubernetes, GitOps, and supply chain security principles, you can create a robust platform that supports rapid development cycles without sacrificing safety.

The platform operates on a multi-stage delivery workflow that emphasizes a strict separation between application builds, security validation, and infrastructure provisioning. It starts with foundational components necessary for automation and pipelines. Each time a commit is made to application repositories, the pipeline triggers, producing a secure and validated container image. Security validation is a prerequisite for any deployment or infrastructure change. Once validation is successful, the infrastructure provisioning pipeline kicks in to establish your Kubernetes environment. Following this, a GitOps model is employed, where Argo CD continuously reconciles the platform and application components by monitoring Kubernetes manifests and Helm charts.

In production, you need to ensure that you have a container image registry for storing versioned and signed artifacts, a Terraform remote backend for state management, and a secure cloud provider service connection for executing pipelines. Pay close attention to the configuration of your Kubernetes cluster, such as enabling auto-scaling and configuring network policies. Remember, while this setup is powerful, it requires careful management and monitoring to avoid pitfalls. The version information is also crucial; keep track of updates and changes to ensure compatibility and security.

Key takeaways

  • Implement Infrastructure as Code (IaC) to manage your infrastructure efficiently.
  • Use GitOps as the single source of truth for cluster management.
  • Enforce security validation before any deployment or infrastructure change.
  • Leverage Argo CD for continuous reconciliation of Kubernetes components.
  • Ensure you have a container image registry for versioned and signed artifacts.

Why it matters

This approach significantly reduces the risk of security vulnerabilities in your deployment process while enhancing the speed of application delivery. By integrating security into the development lifecycle, you can protect your applications from threats and ensure compliance.

Code examples

YAML
1# Stage 1: Build the container image
2- task: Docker@2
3  displayName: 'Build Container Image'
4  inputs:
5    command: build
6    repository: $(ACR_NAME).azurecr.io/$(IMAGE_NAME)
7    tags: $(Build.BuildId)
HCL
1resource "azurerm_kubernetes_cluster" "main" {
2  name                = var.cluster_name
3  resource_group_name = var.resource_group_name
4
5  default_node_pool {
6    name                 = "system"
7    auto_scaling_enabled = true
8    min_count            = 2
9    max_count            = 10
10  }
11
12  identity { 
13    type = "SystemAssigned"
14  }
15
16  network_profile {
17    network_plugin = "azure"
18    network_policy = "calico"
19  }
20
21  key_vault_secrets_provider {
22    secret_rotation_enabled = true
23  }
24}
YAML
1apiVersion: argoproj.io/v1alpha1
2kind: Application
3metadata:
4  name: microservice-api
5  namespace: argocd
6  labels:
7    app.kubernetes.io/part-of: internal-developer-platform
8spec:
9  project: default
10  source:
11    repoURL: https://github.com/your-org/gitops-repo
12    targetRevision: main
13    path: apps/microservice-api/overlays/production
14  destination:
15    server: https://kubernetes.default.svc
16    namespace: production
17  syncPolicy:
18    automated:
19      prune: true        # Remove resources deleted from Git
20      selfHeal: true     # Revert manual changes to cluster
21    syncOptions:
22      - CreateNamespace=true
23      - PrunePropagationPolicy=foreground
24    retry:
25      limit: 5
26      backoff:
27        duration: 5s
28        factor: 2
29        maxDuration: 3m

When NOT to use this

The official docs don't call out specific anti-patterns here. Use your judgment based on your scale and requirements.

Want the complete reference?

Read official docs

Test what you just learned

Quiz questions written from this article

Take the quiz →
Better StackSponsor

Unified observability — logs, uptime monitoring, and on-call in one place. Used by 50,000+ engineering teams to ship faster and sleep better.

Try Better Stack free →

Get the daily digest

One email. 5 articles. Every morning.

No spam. Unsubscribe anytime.