Security¶
With kubernetes deployed internally, companies have control over their physical environment, network, operating system patches, access to authentication and authorization internal registry. They control data access, access to administration console for the platform and the workload deployed.
As part of security is the Identity and Access Management to control access to resource and connection protocol like OpenID. A team is a logical grouping of resources, users, and user groups. Teams can be restricted to all resources within a namespace. Access control gateway enforces role-based access control (RBAC) for all registered services.
Network segmentation to provide isolation, using DMZ VLAN for specific workload, so deploying cluster in DMZ. And use VLAN to segment the physical network, subnets, clusters and namespaces to add more segmentation.
Segmentation will depend of the application requirements.
For securing kubernetes network control, you will have Edge nodes that are worker nodes with only ingress workloads and network policies. Traffic reaches application through private network. Backend services may not be accessible from public network. K8s network policy specifies how pods can communicate with each other, and Calico, the IP based networking, implements the policies (rule per IP addresses). Rules are ORe'ed, if any ingress / egress rule matches connection is allowed. Their are scoped at namespace level.
We can isolate application using labels. The srv1 backend can be accessed only from the frontend
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: backend-allow
spec:
podSelector:
matchLabels:
app: Srv1
Tier: backend
ingress:
- from:
- podSelector:
matchLabels:
app: Srv1
Tier: frontend
and the db backend can only be accessed from the srv1 backend.
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: db-allow
spec:
podSelector:
matchLabels:
app: Srv1
Tier: db
ingress:
- from:
- podSelector:
matchLabels:
app: Srv1
Tier: backend
Role Based Access Control¶
Add a user to a role:
oc adm policy add-cluster-role-to-user strimzi-cluster-operator-namespaced IAM#emailasuserid@something.com
Security Context Constraints¶
- Security Context Constraints (SCCs) to control permissions a pod can perform and what resources it can access
- Access to existing SCC:
kubectl get scc - Get security policies for a scc:
oc describe scc privileged - You can specify SCCs as resources that are handled by RBAC. This allows you to scope access to your SCCs to a certain project or to the entire cluster. Assigning users, groups, or service accounts directly to an SCC retains cluster-wide scope See explanations here