Security Basics

Security in Kubernetes is not a single feature.

It is a layered design that spans infrastructure, networking, access control, and workload configuration.

This guide explains the fundamental security concepts you must understand when running Kubernetes in KubeRaya, and how CloudRaya’s managed platform helps enforce secure defaults.

Shared Responsibility Model

Security in KubeRaya follows a shared responsibility model.

CloudRaya Is Responsible For

• Kubernetes control plane security
• API server availability and integrity
• Core Kubernetes components
• VPC-level isolation
• Infrastructure reliability

You Are Responsible For

• Cluster access control
• Application security
• Pod and container configuration
• Network exposure decisions
• Secrets and credentials usage

CloudRaya secures the platform.

You secure the workloads.

Security Layer Overview

Kubernetes security works across multiple layers:

Infrastructure (CloudRaya)
  ↓
VPC & Networking
  ↓
Kubernetes Control Plane
  ↓
Cluster Access (RBAC)
  ↓
Workloads (Pods & Containers)

Each layer must be configured correctly to achieve a secure system.

Network Security Fundamentals

Default Behavior

• Clusters run inside a private VPC
• Nodes use private IP addresses
• No service is public unless explicitly exposed

This provides a strong security baseline.

Best Practices

• Use ClusterIP for internal services
• Expose services only when required
• Prefer Ingress + LoadBalancer for public access
• Avoid NodePort for production workloads

📄 See:

• Expose Services in Kubernetes
• Networking in Kubernetes

Access Control with RBAC

Role-Based Access Control (RBAC) defines who can do what inside the cluster.

What RBAC Controls

• Access to Kubernetes API
• Permissions to create, update, or delete resources
• Scope of access (namespace or cluster-wide)

Best Practices

• Grant minimum required permissions
• Avoid using cluster-admin for daily operations
• Separate roles for:
  • Admins
  • Developers
  • CI/CD systems

RBAC is the first line of defense against accidental or malicious changes.

Namespace Isolation

Namespaces provide logical isolation inside a cluster.

Common Uses

• Separate environments (dev / staging / prod)
• Isolate teams or applications
• Apply scoped RBAC and quotas

Best Practices

• Do not deploy everything into default
• Use namespaces consistently
• Apply access controls per namespace

Namespaces help reduce blast radius during incidents.

Pod & Container Security

Containers should be treated as untrusted by default.

Recommended Practices

• Use minimal base images
• Avoid running containers as root
• Define resource limits (CPU / memory)
• Scan container images for vulnerabilities
• Avoid embedding secrets in images

Security issues often originate inside containers, not the cluster itself.

Secrets Management

Kubernetes provides Secrets to store sensitive data.

Use Secrets For

• Database credentials
• API keys
• Tokens and certificates

Avoid

• Hardcoding secrets in YAML files
• Committing secrets to Git
• Storing secrets in container images

Secrets should be referenced, not exposed.

API Server & Cluster Access

Secure Access Principles

• Access the cluster only from trusted environments
• Protect kubeconfig files
• Rotate credentials when necessary
• Revoke access immediately when users leave

Kubernetes API access equals full control over the cluster.

Public Exposure Risks

Every public endpoint increases risk.

Common Mistakes

• Exposing internal services publicly
• Using NodePort without restrictions
• Leaving services open without authentication
• Forgetting to enable TLS

Public access should always be intentional, documented, and reviewed.

Monitoring & Auditing

Security is not only prevention, it is also visibility.

Recommended Actions

• Monitor cluster resource usage
• Track changes to critical resources
• Review access logs
• Audit RBAC permissions regularly

Early detection reduces impact.

Secure-by-Design with CloudRaya

CloudRaya helps enforce secure Kubernetes usage by:

• Running clusters inside isolated VPCs
• Managing control plane security
• Requiring explicit service exposure
• Integrating with CloudRaya networking primitives

Security is built into the platform, not bolted on later.

When to Revisit Security Configuration

Review your security posture when:

• Adding new services
• Exposing applications publicly
• Onboarding new team members
• Scaling workloads
• Experiencing incidents

Security is an ongoing process, not a one-time setup.

Related Guides

📄 Kubernetes Overview

📄 Expose Services in Kubernetes

📄 Networking in Kubernetes

📄 Cluster Architecture & Concepts

📄 Kubernetes Best Practices