Security Considerations - antimetal/system-agent GitHub Wiki

Security Considerations

⚠️ Work in Progress: This documentation is currently being developed and may be incomplete or subject to change.

Overview

The Antimetal System Agent is designed with security as a primary concern. This page outlines the security architecture, best practices, and considerations for deploying and operating the agent in production environments.

Security Architecture

1. Minimal Privileges

The System Agent operates with the minimum required privileges:

  • Read-only access to system metrics (/proc, /sys)
  • No write permissions to system configuration
  • No shell execution capabilities
  • No network services exposed (client-only)

2. Container Security

When deployed as a container:

securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
  capabilities:
    drop:
    - ALL

3. Network Security

  • Outbound only: Agent only makes outbound gRPC connections
  • TLS encryption: All communications use TLS 1.2+
  • Certificate validation: Strict certificate checking
  • No listening ports: Agent doesn't expose any network services

Kubernetes RBAC

The agent requires minimal Kubernetes permissions:

rules:
- apiGroups: [""]
  resources: ["nodes", "pods", "services", "endpoints", "namespaces"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["deployments", "daemonsets", "statefulsets", "replicasets"]
  verbs: ["get", "list", "watch"]

RBAC Best Practices

  1. Use dedicated service account: Never use default service account
  2. Scope to namespace: Limit permissions when possible
  3. Regular audits: Review RBAC permissions periodically
  4. Principle of least privilege: Only grant required permissions

Data Security

1. Data Collection

  • No sensitive data: Agent doesn't collect passwords, keys, or secrets
  • Metadata only: Focuses on performance metrics and resource metadata
  • Configurable exclusions: Can exclude specific resources from collection

2. Data Transmission

  • End-to-end encryption: TLS for all data in transit
  • Authentication: mTLS or API key authentication
  • Data integrity: Message signing and verification
  • No data persistence: Agent doesn't store data locally

3. Data Privacy

  • No PII collection: No personal identifiable information
  • Configurable redaction: Can redact sensitive labels/annotations
  • Compliance ready: Supports GDPR, HIPAA compliance requirements

Deployment Security

1. Image Security

  • Official images only: Use images from official registry
  • Image scanning: All images scanned for vulnerabilities
  • Minimal base image: Distroless or Alpine base
  • Regular updates: Frequent security patches

2. Configuration Security

# Secure configuration example
apiVersion: v1
kind: ConfigMap
metadata:
  name: antimetal-agent-config
data:
  config.yaml: |
    # No sensitive data in ConfigMaps
    cluster_name: production
    collection_interval: 30s
---
apiVersion: v1
kind: Secret
metadata:
  name: antimetal-agent-secret
type: Opaque
data:
  # Sensitive data in Secrets only
  api_key: <base64-encoded-key>

3. Secret Management

  • Kubernetes Secrets: For API keys and certificates
  • External secret managers: Support for Vault, AWS Secrets Manager
  • Rotation support: Automatic secret rotation capabilities
  • No hardcoded secrets: Never embed secrets in images or configs

Monitoring and Auditing

1. Security Monitoring

  • Audit logs: All API access logged
  • Anomaly detection: Unusual access patterns flagged
  • Failed authentication: Track and alert on failures
  • Resource access: Monitor what resources are accessed

2. Compliance

  • Audit trails: Complete audit trail of all operations
  • Access logs: Who accessed what and when
  • Change tracking: Configuration change history
  • Compliance reports: Generate compliance documentation

Common Security Concerns

Q: What data does the agent collect?

The agent collects:

  • System performance metrics (CPU, memory, disk, network)
  • Kubernetes resource metadata (names, labels, annotations)
  • Container resource usage
  • Hardware configuration information

The agent does NOT collect:

  • Application data or logs
  • Environment variables (may contain secrets)
  • File contents
  • Network traffic content
  • User data or PII

Q: How is data transmitted securely?

  • All data transmitted over TLS 1.2+
  • Certificate pinning available
  • Mutual TLS (mTLS) authentication supported
  • API key authentication as alternative
  • No unencrypted transmission options

Q: What about multi-tenancy?

  • Namespace isolation: Can be scoped to specific namespaces
  • Resource filtering: Include/exclude specific resources
  • Data segregation: Tenant data kept separate
  • Access control: Per-tenant access controls

Security Checklist

Before deploying to production:

  • Review and apply minimal RBAC permissions
  • Enable pod security policies/standards
  • Configure network policies
  • Use dedicated service account
  • Store secrets in Kubernetes Secrets or external manager
  • Enable audit logging
  • Configure TLS with valid certificates
  • Review container security context
  • Scan images for vulnerabilities
  • Document security configuration

Vulnerability Reporting

If you discover a security vulnerability:

  1. Do not create a public GitHub issue
  2. Email [email protected] with details
  3. Include steps to reproduce if possible
  4. Allow 90 days for patching before disclosure

Additional Resources