Proxmox Security

Here’s a detailed guide with examples and best practices to conduct local security audits focusing on Proxmox access control, Kubernetes RBAC, and networking rules.

  1. Proxmox Access Control

Objective: Ensure that only authorized users can access Proxmox, with role-based permissions to limit actions based on user roles.

•   Audit Access Logs:
•   Regularly check Proxmox logs for unauthorized access attempts. Logs can be found in /var/log/syslog and /var/log/daemon.log.
•   Example: Use grep to search for login attempts.

grep ‘auth’ /var/log/syslog

•   Look for suspicious IPs, unusual login attempts, or brute-force patterns.

•   Implement Role-Based Access Control (RBAC):
•   Proxmox offers built-in roles (e.g., PVEAdmin, PVEDatastoreAdmin, PVEUser). Assign roles based on the principle of least privilege.
•   Example: Assign PVEUser to a general user to give read-only access to VMs without making changes.

Login to Proxmox web UI -> Datacenter -> Permissions -> Users

Assign user roles with least privileges

•   Enable Two-Factor Authentication (2FA):
•   Enable 2FA to add an extra layer of security. This can be configured in the Proxmox Web GUI under Datacenter > Permissions > Realms.
•   Use TOTP (Time-based One-Time Password) authentication with a mobile authenticator app.
•   Example:

Go to Proxmox web interface, select Authentication realm, enable TOTP

•   Secure Proxmox API Access:
•   Restrict API access to specific users and IPs if API access is necessary.
•   Example: Edit /etc/pve/privileges.cfg to specify custom permissions for API users.

Define user permissions in privileges.cfg

user@pve:1,2,3 # Role: PVEDatastoreAdmin

  1. Kubernetes Role-Based Access Control (RBAC)

Objective: Control who can access and modify resources within Kubernetes clusters. Misconfigured RBAC can allow unauthorized users to access sensitive resources.

•   Audit Existing Roles and RoleBindings:
•   Review all roles to ensure they align with security policies. For example, avoid giving cluster-admin permissions to general users.
•   Example: List all roles and role bindings to assess current permissions.

kubectl get roles –all-namespaces
kubectl get rolebindings –all-namespaces
kubectl get clusterroles
kubectl get clusterrolebindings

•   Look for unnecessary or overly permissive roles, such as those containing * in verbs or resources fields.

•   Create Minimalistic Role Definitions:
•   Limit roles to only necessary permissions. For example, restrict access to specific namespaces or resources.
•   Example: Define a read-only role for a specific namespace.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: dev
name: readonly
rules:

  • apiGroups: [“”]
    resources: [“pods”, “services”]
    verbs: [“get”, “list”] • Bind this role to a user or group using RoleBinding.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-only-binding
namespace: dev
subjects:

  • kind: User
    name: “jane.doe” # Username
    apiGroup: rbac.authorization.k8s.io
    roleRef:
    kind: Role
    name: readonly
    apiGroup: rbac.authorization.k8s.io • Disable kubectl Exec Access:
    • Disallow access to kubectl exec for non-admin users, as this command can provide shell access to running containers.
    • Example: Create a role that excludes exec privileges.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: restricted-access
namespace: production
rules:

  • apiGroups: [“”]
    resources: [“pods”]
    verbs: [“get”, “list”, “watch”] • Implement Network Policies for Namespace Isolation:
    • Use Network Policies in Kubernetes to limit inter-namespace communication.
    • Example: Create a network policy that only allows communication between pods in the same namespace.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-same-namespace
namespace: dev
spec:
podSelector: {}
ingress:

  • from:
    • podSelector: {}
  1. Networking Rules

Objective: Secure network access within and outside the Kubernetes cluster to ensure that only required traffic is permitted.

•   Limit Proxmox Network Access:
•   Use firewall rules to restrict access to Proxmox’s management interface, limiting it to specific IP ranges (e.g., your internal network or VPN).
•   Example: Add firewall rules to allow access only from specific IPs.

UFW example

sudo ufw allow from 192.168.1.0/24 to any port 8006 proto tcp
sudo ufw allow from to any port 8006 proto tcp

•   Enable Proxmox Firewall for VM Isolation:
•   Enable Proxmox’s built-in firewall to isolate VMs and limit their network access. Configure rules based on VM roles.
•   Example: Isolate a sensitive VM by allowing access only from the management network.

Go to VM > Firewall > Add Rule in the Proxmox UI to configure

•   Use Kubernetes Network Policies for Microsegmentation:
•   Control traffic between pods using Kubernetes Network Policies, implementing a “deny by default” model.
•   Example: Block all incoming traffic to a namespace except from specific sources.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all
namespace: secure-app
spec:
podSelector: {}
policyTypes:

  • Ingress
  • Egress • Monitor Traffic and Configure Alerts:
    • Use Prometheus and Grafana to track network traffic metrics and detect unusual patterns.
    • Set up alerts on failed connection attempts, traffic spikes, or unusual access attempts to critical services.

Summary Checklist

1.  Proxmox: Implement RBAC, 2FA, restrict API access, monitor access logs, and isolate VMs with firewalls.
2.  Kubernetes: Create least-privilege roles, limit kubectl exec for sensitive workloads, implement network policies for isolation.
3.  Networking: Use firewall rules to restrict access to Proxmox, enforce network policies for microsegmentation in Kubernetes, and set up monitoring for traffic anomalies.

These practices establish a secure foundation for Proxmox and Kubernetes in your NFT production environment.