{"id":32641,"date":"2019-10-31T21:48:11","date_gmt":"2019-10-31T18:48:11","guid":{"rendered":"https:\/\/prohoster.info\/blog\/vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti\/"},"modified":"2019-10-31T21:48:11","modified_gmt":"2019-10-31T18:48:11","slug":"vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti","title":{"rendered":"Introduction to Kubernetes Network Policies for Security Professionals","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Introduction
\n
\nNote: translation.<\/b>: The author of the article, Reuven Harrison, has over 20 years of experience in software development and is currently the CTO and co-founder of Tufin, a company that creates security policy management solutions. While considering Kubernetes network policies as a powerful means for network segmentation within a cluster, he believes they are not as straightforward to implement in practice. This rather extensive material aims to enhance professionals' awareness of this issue and assist them in creating the necessary configurations.<\/i><\/a><\/noindex><\/p>\n

Today, many companies are increasingly choosing Kubernetes to run their applications. The interest in this software is so high that some even call Kubernetes 'the new operating system for data centers.' Gradually, Kubernetes (or k8s) is beginning to be seen as a critical part of the business that demands the organization of mature business processes, including network security.<\/p>\n

For security professionals grappling with working with Kubernetes, a real revelation may be the platform's default policy: allow everything.<\/p>\n

This guide will help to understand the internal workings of network policies, and how they differ from rules for traditional firewalls. It will also discuss some pitfalls and provide recommendations that will help secure applications in Kubernetes.<\/p>\n

Kubernetes Network Policies<\/h2>\n

\nThe Kubernetes network policy mechanism allows the management of interactions between applications deployed on the platform at the network level (the third layer in the OSI model). Network policies lack some advanced features of modern firewalls, such as Layer 7 OSI control and threat detection; however, they provide a basic level of network security which serves as a decent starting point.<\/p>\n

Network policies control communications between pods.<\/h2>\n

\nWorkloads in Kubernetes are distributed across pods, which consist of one or more containers deployed together. Kubernetes assigns an IP address to each pod that is accessible from other pods. Kubernetes network policies set access rights for groups of pods in the same way that security groups in the cloud are used to manage access to virtual machine instances.<\/p>\n

Defining Network Policies<\/h2>\n

\nLike other Kubernetes resources, network policies are defined in YAML. In the example below, the application balance<\/code> is granted access to postgres<\/code>:<\/p>\n

apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.postgres\n  namespace: default\nspec:\n  podSelector:\n    matchLabels:\n      app: postgres\n  ingress:\n  - from:\n    - podSelector:\n        matchLabels:\n          app: balance\n  policyTypes:\n  - Ingress<\/code><\/pre>\n
\n\"Introduction
\n
\n(Note: translation.<\/b>: this screenshot, like all subsequent similar ones, was created not using native Kubernetes tools but with the Tufin Orca tool, developed by the company of the original article's author and mentioned at the end of the material.)<\/i><\/p>\n
To define your own network policy, basic knowledge of YAML is required. This language is based on indentation (using spaces, not tabs). An indented element belongs to the nearest indented element above it. A new list element begins with a dash, while all other elements appear as key-value<\/i>.<\/p>\n
After describing the policy in YAML, use kubectl<\/a><\/noindex>, to create it in the cluster:<\/p>\n
kubectl create -f policy.yaml<\/code><\/pre>\n
<\/p>\n
Network Policy Specification<\/h2>\n
\nThe Kubernetes network policy specification includes four elements:<\/p>\n
    \n
  1.  podSelector<\/code>specifies the pods affected by this policy (targets) \u2014 mandatory;<\/li>\n
  2.  policyTypes<\/code>: specifies which types of policies are included: ingress and\/or egress - optional, but I recommend explicitly stating it in all cases;<\/li>\n
  3.  ingress<\/code>: defines the allowed incoming<\/b> traffic to target pods \u2014 optional;<\/li>\n
  4.  egress<\/code>: defines the allowed outgoing<\/b> traffic from target pods \u2014 optional.<\/li>\n<\/ol>\n
    \nAn example borrowed from the Kubernetes website (I replaced role<\/code> to app<\/code>), shows how all four elements are used:<\/p>\n
    apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: test-network-policy\n  namespace: default\nspec:\n  podSelector:    # <<<\n    matchLabels:\n      app: db\n  policyTypes:    # <<<\n  - Ingress\n  - Egress\n  ingress:        # <<<\n  - from:\n    - ipBlock:\n        cidr: 172.17.0.0\/16\n        except:\n        - 172.17.1.0\/24\n    - namespaceSelector:\n        matchLabels:\n          project: myproject\n    - podSelector:\n        matchLabels:\n          role: frontend\n    ports:\n    - protocol: TCP\n      port: 6379\n  egress:         # <<<\n  - to:\n    - ipBlock:\n        cidr: 10.0.0.0\/24\n    ports:\n    - protocol: TCP\n      port: 5978<\/code><\/pre>\n
    \n\"Introduction
    \n\"Introduction
    \n
    \nPlease note that not all four elements are required to be included. Only podSelector<\/code>the other parameters can be optional.<\/p>\n
    If omitted policyTypes<\/code>, the policy will be interpreted as follows:<\/p>\n