Skip to content

AWS Security Configuration Guide

logo

Overview

This guide provides comprehensive security configuration requirements and best practices for deploying Orion on AWS infrastructure in compliance with AWS Foundational Technical Review (FTR) standards. These configurations ensure enterprise-grade security while maintaining operational excellence.

Administrative Privileges

Principle of Least Privilege

Orion deployments follow strict least privilege principles, ensuring no component requires unnecessary administrative access:

Orion Platform Privileges

  • No Root Access: Orion containers run as non-privileged users
  • Service Account Limitations: Kubernetes service accounts have minimal required permissions
  • API Access: Limited to specific resource types and namespaces
  • Network Access: Restricted to essential ports and protocols

EKSCTL Deployment Privileges

During initial deployment, EKSCTL requires:

  • EKS Cluster Management: Creating and managing EKS clusters

  • EC2 Instance Management: Managing worker nodes and security groups

  • VPC Management: Creating subnets, route tables, and NAT gateways

  • IAM Role Management: Creating service-specific roles with limited scope

Post-Deployment: Administrative privileges can be reduced to operational maintenance level.

Operational Privileges

For day-to-day operations:

  • Platform Updates: Limited to Orion namespace and resources

  • Monitoring: Read-only access to system metrics and logs

  • Troubleshooting: Specific diagnostic permissions without system-wide access

Administrative Access Controls

# Example Orion service account with minimal privileges
apiVersion: v1
kind: ServiceAccount
metadata:
  name: orion-platform
  namespace: orion-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: orion-platform-role
  namespace: orion-system
rules:
- apiGroups: [""]
  resources: ["pods", "services", "endpoints"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]
- apiGroups: ["apps"]
  resources: ["deployments", "replicasets"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]

IAM Roles and Policies

EKSCTL ships with its own system for creating and managing IAM roles and policies. We highly recommend following their recommendations from AWS directly:

Required IAM Roles

Orion deployment creates specific IAM roles with clearly defined boundaries:

EKS Cluster Service Role

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "eks.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Attached Policies: - AmazonEKSClusterPolicy

Purpose: Allows EKS service to manage cluster resources on your behalf

EKS Node Group Role

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Attached Policies:

  • AmazonEKSWorkerNodePolicy

  • AmazonEKS_CNI_Policy

  • AmazonEC2ContainerRegistryReadOnly

Purpose: Allows worker nodes to join cluster and access ECR

AWS Load Balancer Controller Role

Uses OIDC provider for secure service account mapping:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::ACCOUNT-ID:oidc-provider/oidc.eks.REGION.amazonaws.com/id/EXAMPLE"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "oidc.eks.REGION.amazonaws.com/id/EXAMPLE:sub": "system:serviceaccount:kube-system:aws-load-balancer-controller",
          "oidc.eks.REGION.amazonaws.com/id/EXAMPLE:aud": "sts.amazonaws.com"
        }
      }
    }
  ]
}

Policy Boundaries and Resource Tagging

All resources created by Orion deployment include consistent tagging:

tags:
  Environment: "production"
  Application: "orion-platform"
  ManagedBy: "juno-innovations"
  CostCenter: "it-infrastructure"
  DataClassification: "internal"

Encryption Configuration

Encryption at Rest

EKS Cluster Encryption

# EKSCTL configuration for cluster encryption
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: orion-cluster
  region: us-east-1
encryptionConfig:
  provider:
    keyArn: arn:aws:kms:us-east-1:ACCOUNT:key/KEY-ID
  resources:
    - secrets

EBS Volume Encryption

# Encrypted storage class
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: orion-encrypted-gp3
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  encrypted: "true"
  kmsKeyId: arn:aws:kms:us-east-1:ACCOUNT:key/KEY-ID
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

Encryption in Transit

TLS Configuration

  • All external communications use TLS 1.2 or higher
  • Internal service mesh communications encrypted (optional but recommended)
  • Database connections encrypted using SSL/TLS
# Ingress TLS configuration
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: orion-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
  tls:
  - hosts:
    - orion.yourdomain.com
    secretName: orion-tls-secret
  rules:
  - host: orion.yourdomain.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: orion-frontend
            port:
              number: 80

Network Security

VPC Configuration

Network Isolation

# EKSCTL VPC configuration
vpc:
  cidr: "10.0.0.0/16"
  subnets:
    public:
      public-subnet-1:
        cidr: "10.0.1.0/24"
        availabilityZone: "us-east-1a"
      public-subnet-2:
        cidr: "10.0.2.0/24"
        availabilityZone: "us-east-1b"
    private:
      private-subnet-1:
        cidr: "10.0.11.0/24"
        availabilityZone: "us-east-1a"
      private-subnet-2:
        cidr: "10.0.12.0/24"
        availabilityZone: "us-east-1b"

Security Groups

{
  "GroupName": "orion-worker-nodes-sg",
  "Description": "Security group for Orion EKS worker nodes",
  "SecurityGroupRules": [
    {
      "IpProtocol": "tcp",
      "FromPort": 443,
      "ToPort": 443,
      "CidrIpv4": "0.0.0.0/0",
      "Description": "HTTPS inbound"
    },
    {
      "IpProtocol": "tcp",
      "FromPort": 10250,
      "ToPort": 10250,
      "SourceSecurityGroupId": "sg-cluster-control-plane",
      "Description": "Kubelet API"
    }
  ]
}

Network ACLs

Additional network-level protection:

  • Default deny all inbound traffic

  • Explicit allow rules for required services

  • Separate ACLs for public and private subnets

Kubernetes Network Policies

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: orion-network-policy
  namespace: orion-system
spec:
  podSelector:
    matchLabels:
      app: orion-platform
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: ingress-nginx
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - namespaceSelector: {}
    ports:
    - protocol: TCP
      port: 443

Key Management

AWS KMS Integration

Customer-Managed Keys

# KMS key for Orion resources
ApiVersion: kms.aws.com/v1
Kind: Key
Metadata:
  Name: orion-platform-key
Spec:
  Description: "Encryption key for Orion platform resources"
  KeyUsage: ENCRYPT_DECRYPT
  KeySpec: SYMMETRIC_DEFAULT
  Policy:
    Version: "2012-10-17"
    Statement:
      - Sid: Enable IAM User Permissions
        Effect: Allow
        Principal:
          AWS: "arn:aws:iam::ACCOUNT:root"
        Action: "kms:*"
        Resource: "*"
      - Sid: Allow EKS Service
        Effect: Allow
        Principal:
          Service: eks.amazonaws.com
        Action:
          - kms:Decrypt
          - kms:DescribeKey
        Resource: "*"

Key Rotation

We highly recommend enabling automatic key rotation for all customer-managed keys. You can use the secrets-store-csi-driver from the Kubernetes SIGs to manage secrets and keys within your cluster. Please follow the official documentation for installation and follow the core concepts. Once installed, configure the AWS provider as per the AWS provider documentation. You can then follow the usage documentation to setup the rotation of your keys.

  • Automatic key rotation enabled for customer-managed keys

  • Annual rotation policy with audit trail

  • Immediate rotation capability for security incidents

Certificate Management

AWS Certificate Manager Integration

# Certificate for Orion ingress
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: orion-tls-cert
  namespace: orion-system
spec:
  secretName: orion-tls-secret
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
  - orion.yourdomain.com
  - api.orion.yourdomain.com

Internal Service Certificates

  • Mutual TLS for internal service communication

  • Certificate lifecycle management

  • Automatic renewal and distribution

IMDSv1 Disable Support

EC2 Metadata Service Configuration

IMDSv2 Enforcement

All EKS worker nodes configured to require IMDSv2:

# EKSCTL node group configuration
nodeGroups:
  - name: orion-nodes
    instanceType: t3.medium
    desiredCapacity: 3
    ssh:
      publicKeyName: eks-nodes
    iam:
      withAddonPolicies:
        imageBuilder: true
    metadata:
      httpEndpoint: enabled
      httpTokens: required  # Enforces IMDSv2
      httpPutResponseHopLimit: 2

Pod-Level IMDS Restrictions

# Security context preventing IMDS access
apiVersion: v1
kind: Pod
metadata:
  name: orion-workload
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 2000
  containers:
  - name: orion-app
    image: juno/orion:latest
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
        - ALL

Security Monitoring and Compliance

CloudTrail Configuration

API Logging

{
  "TrailName": "orion-security-audit",
  "S3BucketName": "orion-cloudtrail-logs",
  "IncludeGlobalServiceEvents": true,
  "IsMultiRegionTrail": true,
  "EnableLogFileValidation": true,
  "EventSelectors": [
    {
      "ReadWriteType": "All",
      "IncludeManagementEvents": true,
      "DataResources": [
        {
          "Type": "AWS::S3::Object",
          "Values": ["arn:aws:s3:::orion-*/*"]
        }
      ]
    }
  ]
}

AWS Config Rules

Compliance Monitoring

  • EKS cluster endpoint access configuration
  • Security group compliance rules
  • Encryption at rest validation
  • IMDSv2 enforcement monitoring
{
  "ConfigRuleName": "eks-cluster-endpoint-no-public-access",
  "Source": {
    "Owner": "AWS",
    "SourceIdentifier": "EKS_ENDPOINT_NO_PUBLIC_ACCESS"
  },
  "Scope": {
    "ComplianceResourceTypes": [
      "AWS::EKS::Cluster"
    ]
  }
}

Security Best Practices Checklist

Pre-Deployment Security

  • Customer-managed KMS keys created and configured
  • IAM roles follow principle of least privilege
  • VPC designed with proper network segmentation
  • Security groups configured with minimal required access
  • IMDSv2 enforced on all EC2 instances

Post-Deployment Security

  • All communications encrypted in transit
  • Storage encrypted at rest with customer-managed keys
  • Network policies implemented for pod-to-pod communication
  • CloudTrail logging enabled and monitored
  • AWS Config rules deployed for compliance monitoring

Ongoing Security Maintenance

  • Regular security group audit and cleanup
  • Certificate renewal monitoring and automation
  • Key rotation compliance verification
  • Security patch management for worker nodes
  • Compliance reporting and audit preparation

Security Incident Response

Detection and Alerting

  • CloudWatch alarms for security-relevant events
  • AWS Security Hub integration for centralized findings
  • VPC Flow Logs analysis for network anomalies

Response Procedures

  1. Incident Classification: Severity assessment using established criteria
  2. Containment: Isolate affected resources and limit blast radius
  3. Investigation: Forensic analysis using CloudTrail and VPC Flow Logs
  4. Recovery: Restore services from known-good configurations
  5. Lessons Learned: Post-incident review and security improvements

Compliance Documentation

Audit Requirements

  • Access Logs: Complete audit trail of all administrative actions
  • Configuration Changes: Version-controlled infrastructure as code
  • Security Controls: Evidence of implemented security measures
  • Compliance Reports: Regular assessment against security frameworks

Documentation Maintenance

  • Security configuration baselines
  • Incident response playbooks
  • Compliance evidence collection
  • Regular security assessment reports

Backup and Recovery

Please refer to the official EKS documentation on how to provide safety and recovery for your cluster in this guide.

System Updates and Patch Management

We highly recommend using AWS Managed EKS AMI's for your worker nodes. These AMI's are regularly updated and patched by AWS to ensure you have the latest security updates and patches. You can find more information on how to use these AMI's in the official documentation here. The full documentation for how to build and manually update your system is very well documented here. We recommend using the integrated ami's from AWS to ensure you have the latest security patches and updates. If you need additional libraries, you can build on top of their work to add additional functionality (updated drivers, bleeding edge libraries, etc).

Disclaimer: All cost estimates and deployment times are based on current AWS pricing and may vary by region and usage patterns. Contact our sales team for precise pricing and customized cost analysis based on your specific requirements.