સુરક્ષા વ્યાવસાયિકો માટે કુબરનેટ્સ નેટવર્ક નીતિઓનો પરિચય

નૉૅધ. અનુવાદ: લેખના લેખક, રુવેન હેરિસન, સોફ્ટવેર ડેવલપમેન્ટમાં 20 વર્ષથી વધુનો અનુભવ ધરાવે છે, અને આજે સુરક્ષા નીતિ વ્યવસ્થાપન ઉકેલો બનાવતી કંપની તુફિનના CTO અને સહ-સ્થાપક છે. જ્યારે તે કુબરનેટ્સ નેટવર્ક નીતિઓને ક્લસ્ટરમાં નેટવર્ક વિભાજન માટે એકદમ શક્તિશાળી સાધન તરીકે જુએ છે, તે પણ માને છે કે વ્યવહારમાં તેનો અમલ કરવો એટલો સરળ નથી. આ સામગ્રી (એકદમ વિશાળ)નો હેતુ નિષ્ણાતોની આ સમસ્યા અંગેની જાગૃતિ વધારવા અને જરૂરી ગોઠવણી બનાવવામાં મદદ કરવાનો છે.

આજે, ઘણી કંપનીઓ તેમની એપ્લિકેશન ચલાવવા માટે કુબરનેટ્સને વધુને વધુ પસંદ કરી રહી છે. આ સૉફ્ટવેરમાં રસ એટલો વધારે છે કે કેટલાક કુબરનેટ્સને "ડેટા સેન્ટર માટે નવી ઑપરેટિંગ સિસ્ટમ" કહી રહ્યાં છે. ધીરે ધીરે, કુબરનેટ્સ (અથવા k8s) ને વ્યવસાયના એક મહત્વપૂર્ણ ભાગ તરીકે સમજવામાં આવે છે, જેને નેટવર્ક સુરક્ષા સહિત પરિપક્વ વ્યવસાયિક પ્રક્રિયાઓના સંગઠનની જરૂર છે.

સુરક્ષા વ્યાવસાયિકો માટે કે જેઓ કુબરનેટ્સ સાથે કામ કરીને મૂંઝવણમાં છે, વાસ્તવિક સાક્ષાત્કાર પ્લેટફોર્મની ડિફોલ્ટ નીતિ હોઈ શકે છે: દરેક વસ્તુને મંજૂરી આપો.

આ માર્ગદર્શિકા તમને નેટવર્ક નીતિઓની આંતરિક રચનાને સમજવામાં મદદ કરશે; સમજો કે તેઓ નિયમિત ફાયરવોલ માટેના નિયમોથી કેવી રીતે અલગ છે. તે કેટલીક મુશ્કેલીઓને પણ આવરી લેશે અને કુબરનેટ્સ પર એપ્લિકેશનને સુરક્ષિત કરવામાં મદદ કરવા માટે ભલામણો પ્રદાન કરશે.

Kubernetes નેટવર્ક નીતિઓ

Kubernetes નેટવર્ક પોલિસી મિકેનિઝમ તમને પ્લેટફોર્મ પર નેટવર્ક લેયર (OSI મોડલમાં ત્રીજું) પર જમાવવામાં આવેલી એપ્લિકેશનની ક્રિયાપ્રતિક્રિયાનું સંચાલન કરવાની મંજૂરી આપે છે. નેટવર્ક નીતિઓમાં આધુનિક ફાયરવોલની કેટલીક અદ્યતન સુવિધાઓનો અભાવ છે, જેમ કે OSI લેયર 7 અમલીકરણ અને ધમકી શોધ, પરંતુ તેઓ નેટવર્ક સુરક્ષાનું મૂળભૂત સ્તર પ્રદાન કરે છે જે એક સારો પ્રારંભિક બિંદુ છે.

નેટવર્ક નીતિઓ પોડ્સ વચ્ચેના સંચારને નિયંત્રિત કરે છે

કુબરનેટસમાં વર્કલોડ પોડ્સમાં વિતરિત કરવામાં આવે છે, જેમાં એક અથવા વધુ કન્ટેનર એકસાથે ગોઠવવામાં આવે છે. Kubernetes દરેક પોડને એક IP સરનામું અસાઇન કરે છે જે અન્ય પોડમાંથી સુલભ હોય છે. Kubernetes નેટવર્ક નીતિઓ પોડ્સના જૂથો માટે ઍક્સેસ અધિકારો એ જ રીતે સેટ કરે છે જે રીતે ક્લાઉડમાં સુરક્ષા જૂથોનો ઉપયોગ વર્ચ્યુઅલ મશીન ઉદાહરણોની ઍક્સેસને નિયંત્રિત કરવા માટે થાય છે.

નેટવર્ક નીતિઓ વ્યાખ્યાયિત

અન્ય Kubernetes સંસાધનોની જેમ, નેટવર્ક નીતિઓ YAML માં ઉલ્લેખિત છે. નીચેના ઉદાહરણમાં, એપ્લિકેશન balance પ્રવેશ મેળવવો postgres:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: balance
  policyTypes:
  - Ingress

(નૉૅધ. અનુવાદ: આ સ્ક્રીનશૉટ, ત્યારપછીના તમામ સમાનોની જેમ, મૂળ કુબરનેટ્સ ટૂલ્સનો ઉપયોગ કરીને નહીં, પરંતુ તુફિન ઓર્કા ટૂલનો ઉપયોગ કરીને બનાવવામાં આવ્યો હતો, જે મૂળ લેખના લેખકની કંપની દ્વારા વિકસાવવામાં આવ્યો હતો અને જેનો ઉલ્લેખ સામગ્રીના અંતે કરવામાં આવ્યો છે.)

તમારી પોતાની નેટવર્ક નીતિને વ્યાખ્યાયિત કરવા માટે, તમારે YAML ના મૂળભૂત જ્ઞાનની જરૂર પડશે. આ ભાષા ઇન્ડેન્ટેશન પર આધારિત છે (ટૅબને બદલે જગ્યાઓ દ્વારા ઉલ્લેખિત). ઇન્ડેન્ટેડ તત્વ તેની ઉપરના સૌથી નજીકના ઇન્ડેન્ટેડ તત્વનું છે. નવી સૂચિ ઘટક હાઇફનથી શરૂ થાય છે, અન્ય તમામ ઘટકોનું સ્વરૂપ હોય છે કી-મૂલ્ય.

YAML માં નીતિનું વર્ણન કર્યા પછી, ઉપયોગ કરો kubectlતેને ક્લસ્ટરમાં બનાવવા માટે:

kubectl create -f policy.yaml

નેટવર્ક નીતિ સ્પષ્ટીકરણ

કુબરનેટ્સ નેટવર્ક નીતિ સ્પષ્ટીકરણમાં ચાર ઘટકો શામેલ છે:

1. podSelector: આ નીતિ (લક્ષ્યો) દ્વારા અસરગ્રસ્ત શીંગો વ્યાખ્યાયિત કરે છે - જરૂરી;
2. policyTypes: સૂચવે છે કે આમાં કયા પ્રકારની નીતિઓ શામેલ છે: પ્રવેશ અને/અથવા બહાર નીકળો - વૈકલ્પિક, પરંતુ હું તેને તમામ કેસોમાં સ્પષ્ટપણે સ્પષ્ટ કરવાની ભલામણ કરું છું;
3. ingress: માન્ય વ્યાખ્યાયિત કરે છે ઇનકમિંગ લક્ષ્ય શીંગો પર ટ્રાફિક - વૈકલ્પિક;
4. egress: માન્ય વ્યાખ્યાયિત કરે છે આઉટગોઇંગ લક્ષ્ય શીંગોમાંથી ટ્રાફિક વૈકલ્પિક છે.

કુબરનેટીસ વેબસાઇટ પરથી લેવામાં આવેલ ઉદાહરણ (મેં બદલ્યું role પર app), બતાવે છે કે તમામ ચાર ઘટકોનો ઉપયોગ કેવી રીતે થાય છે:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:    # <<<
    matchLabels:
      app: db
  policyTypes:    # <<<
  - Ingress
  - Egress
  ingress:        # <<<
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:         # <<<
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

મહેરબાની કરીને નોંધ કરો કે તમામ ચાર ઘટકોનો સમાવેશ કરવાની જરૂર નથી. ફરજિયાત માત્ર છે podSelector, અન્ય પરિમાણો ઇચ્છિત તરીકે વાપરી શકાય છે.

જો આપણે છોડી દઈએ policyTypes, નીતિ નીચે પ્રમાણે અર્થઘટન કરવામાં આવશે:

• મૂળભૂત રીતે, એવું માનવામાં આવે છે કે તે પ્રવેશ બાજુને વ્યાખ્યાયિત કરે છે. જો નીતિ સ્પષ્ટપણે આ જણાવતી નથી, તો સિસ્ટમ માની લેશે કે તમામ ટ્રાફિક પ્રતિબંધિત છે.
• બહાર નીકળવા તરફનું વર્તન અનુરૂપ બહાર નીકળવાના પરિમાણની હાજરી અથવા ગેરહાજરી દ્વારા નક્કી કરવામાં આવશે.

ભૂલો ટાળવા માટે હું ભલામણ કરું છું હંમેશા તેને સ્પષ્ટ કરો policyTypes.

ઉપરોક્ત તર્ક મુજબ, જો પરિમાણો ingress અને / અથવા egress અવગણવામાં આવે છે, નીતિ તમામ ટ્રાફિકને નકારશે (નીચે "સ્ટ્રીપિંગ નિયમ" જુઓ).

ડિફોલ્ટ નીતિ મંજૂરી છે

જો કોઈ નીતિ નિર્ધારિત ન હોય, તો કુબરનેટ્સ તમામ ટ્રાફિકને ડિફોલ્ટ રૂપે મંજૂરી આપે છે. તમામ શીંગો મુક્તપણે પોતાની વચ્ચે માહિતીની આપ-લે કરી શકે છે. આ સુરક્ષાના પરિપ્રેક્ષ્યમાં પ્રતિસાહજિક લાગે છે, પરંતુ યાદ રાખો કે કુબરનેટીસ મૂળરૂપે વિકાસકર્તાઓ દ્વારા એપ્લિકેશન ઇન્ટરઓપરેબિલિટીને સક્ષમ કરવા માટે ડિઝાઇન કરવામાં આવી હતી. નેટવર્ક નીતિઓ પાછળથી ઉમેરવામાં આવી હતી.

નેમસ્પેસ

નેમસ્પેસ એ કુબરનેટસ સહયોગ મિકેનિઝમ છે. તેઓ એકબીજાથી તાર્કિક વાતાવરણને અલગ કરવા માટે રચાયેલ છે, જ્યારે જગ્યાઓ વચ્ચેના સંચારને મૂળભૂત રીતે મંજૂરી આપવામાં આવે છે.

મોટાભાગના કુબરનેટ્સ ઘટકોની જેમ, નેટવર્ક નીતિઓ ચોક્કસ નેમસ્પેસમાં રહે છે. બ્લોકમાં metadata તમે સ્પષ્ટ કરી શકો છો કે નીતિ કઈ જગ્યાની છે:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: my-namespace  # <<<
spec:
...

જો મેટાડેટામાં નેમસ્પેસ સ્પષ્ટ રીતે ઉલ્લેખિત ન હોય, તો સિસ્ટમ kubectl (મૂળભૂત રીતે) માં ઉલ્લેખિત નેમસ્પેસનો ઉપયોગ કરશે namespace=default):

kubectl apply -n my-namespace -f namespace.yaml

હું ભલામણ કરું છું નેમસ્પેસ સ્પષ્ટપણે સ્પષ્ટ કરો, જ્યાં સુધી તમે એક જ સમયે બહુવિધ નેમસ્પેસને લક્ષિત કરતી નીતિ લખી રહ્યાં હોવ.

મુખ્ય તત્વ podSelector પોલિસીમાં નેમસ્પેસમાંથી પોડ્સ પસંદ કરશે જેની પોલિસી છે (તેને અન્ય નેમસ્પેસમાંથી પોડ્સની ઍક્સેસ નકારી છે).

એ જ રીતે, પોડસિલેક્ટર્સ પ્રવેશ અને બહાર નીકળવાના બ્લોક્સમાં ફક્ત પોડ્સને તેમના પોતાના નામ સ્થાનમાંથી પસંદ કરી શકે છે, સિવાય કે તમે તેમની સાથે જોડો namespaceSelector (આની ચર્ચા “નેમસ્પેસ અને પોડ્સ દ્વારા ફિલ્ટર કરો” વિભાગમાં કરવામાં આવશે).

પોલિસી નામકરણ નિયમો

નીતિ નામો સમાન નેમસ્પેસમાં અનન્ય છે. એક જ સ્પેસમાં એક જ નામની બે પોલિસી ન હોઈ શકે, પરંતુ અલગ-અલગ જગ્યાઓમાં એક જ નામની પોલિસી હોઈ શકે છે. જ્યારે તમે બહુવિધ જગ્યાઓ પર સમાન નીતિને ફરીથી લાગુ કરવા માંગતા હો ત્યારે આ ઉપયોગી છે.

મને ખાસ કરીને નામકરણની એક પદ્ધતિ ગમે છે. તેમાં નેમસ્પેસ નામને લક્ષ્ય પોડ્સ સાથે સંયોજિત કરવાનો સમાવેશ થાય છે. દાખ્લા તરીકે:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres  # <<<
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: admin
  policyTypes:
  - Ingress

લેબલ્સ

તમે કુબરનેટ્સ ઑબ્જેક્ટમાં કસ્ટમ લેબલ્સ જોડી શકો છો, જેમ કે પોડ્સ અને નેમસ્પેસ. લેબલ્સ (લેબલ્સ - ટૅગ્સ) એ ક્લાઉડમાંના ટૅગ્સની સમકક્ષ છે. Kubernetes નેટવર્ક નીતિઓ પસંદ કરવા માટે લેબલનો ઉપયોગ કરે છે શીંગોજેના પર તેઓ અરજી કરે છે:

podSelector:
  matchLabels:
    role: db

… અથવા નેમસ્પેસજેના માટે તેઓ અરજી કરે છે. આ ઉદાહરણ અનુરૂપ લેબલ્સ સાથે નેમસ્પેસમાં તમામ પોડ્સ પસંદ કરે છે:

namespaceSelector:
  matchLabels:
    project: myproject

એક સાવધાની: ઉપયોગ કરતી વખતે namespaceSelector ખાતરી કરો કે તમે પસંદ કરેલ નેમસ્પેસમાં યોગ્ય લેબલ છે. ધ્યાન રાખો કે બિલ્ટ-ઇન નેમસ્પેસ જેમ કે default и kube-system, મૂળભૂત રીતે લેબલ્સ સમાવતા નથી.

તમે આના જેવી જગ્યામાં લેબલ ઉમેરી શકો છો:

kubectl label namespace default namespace=default

તે જ સમયે, વિભાગમાં નામની જગ્યા metadata વાસ્તવિક જગ્યાના નામનો સંદર્ભ લેવો જોઈએ, લેબલનો નહીં:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default   # <<<
spec:
...

સ્ત્રોત અને ગંતવ્ય

ફાયરવોલ નીતિઓમાં સ્ત્રોતો અને ગંતવ્યોના નિયમોનો સમાવેશ થાય છે. કુબરનેટ્સ નેટવર્ક નીતિઓ લક્ષ્ય માટે વ્યાખ્યાયિત કરવામાં આવે છે - પોડ્સનો સમૂહ કે જેના પર તેઓ લાગુ થાય છે - અને પછી પ્રવેશ અને/અથવા બહાર નીકળવાના ટ્રાફિક માટે નિયમો સેટ કરે છે. અમારા ઉદાહરણમાં, પોલિસીનું લક્ષ્ય નેમસ્પેસમાંના તમામ પોડ્સ હશે default કી સાથે લેબલ સાથે app અને અર્થ db:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: db   # <<<
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

પેટાવિભાગ ingress આ નીતિમાં, આવનારા ટ્રાફિકને લક્ષ્ય પોડ્સ પર ખોલે છે. બીજા શબ્દોમાં કહીએ તો, પ્રવેશ એ સ્ત્રોત છે અને લક્ષ્ય અનુરૂપ ગંતવ્ય છે. તેવી જ રીતે, બહાર નીકળવું એ ગંતવ્ય છે અને લક્ષ્ય તેનો સ્ત્રોત છે.

આ બે ફાયરવોલ નિયમોની સમકક્ષ છે: પ્રવેશ → લક્ષ્ય; ધ્યેય → બહાર નીકળો.

બહાર નીકળવું અને DNS (મહત્વપૂર્ણ!)

આઉટગોઇંગ ટ્રાફિકને મર્યાદિત કરીને, DNS પર વિશેષ ધ્યાન આપો - Kubernetes આ સેવાનો ઉપયોગ IP સરનામાં પર સેવાઓનો નકશો બનાવવા માટે કરે છે. ઉદાહરણ તરીકે, નીચેની નીતિ કામ કરશે નહીં કારણ કે તમે એપ્લિકેશનને મંજૂરી આપી નથી balance DNS ઍક્સેસ કરો:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  policyTypes:
  - Egress

તમે DNS સેવાની ઍક્સેસ ખોલીને તેને ઠીક કરી શકો છો:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  - to:               # <<<
    ports:            # <<<
    - protocol: UDP   # <<<
      port: 53        # <<<
  policyTypes:
  - Egress

છેલ્લું તત્વ to ખાલી છે, અને તેથી તે પરોક્ષ રીતે પસંદ કરે છે તમામ નામની જગ્યાઓમાં તમામ શીંગો, પરવાનગી આપે છે balance DNS ક્વેરીઝને યોગ્ય કુબરનેટ્સ સેવા પર મોકલો (સામાન્ય રીતે જગ્યામાં ચાલતી હોય છે kube-system).

આ અભિગમ કામ કરે છે, તેમ છતાં અતિશય અનુમતિપૂર્ણ અને અસુરક્ષિત, કારણ કે તે DNS ક્વેરીઝને ક્લસ્ટરની બહાર નિર્દેશિત કરવાની મંજૂરી આપે છે.

તમે તેને ત્રણ ક્રમિક પગલાંમાં સુધારી શકો છો.

1. માત્ર DNS ક્વેરીઝને મંજૂરી આપો અંદર ઉમેરીને ક્લસ્ટર namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  - to:
    - namespaceSelector: {} # <<<
    ports:
    - protocol: UDP
      port: 53
  policyTypes:
  - Egress

2. માત્ર નેમસ્પેસમાં જ DNS ક્વેરીઝને મંજૂરી આપો kube-system.

આ કરવા માટે તમારે નેમસ્પેસમાં લેબલ ઉમેરવાની જરૂર છે kube-system: kubectl label namespace kube-system namespace=kube-system - અને તેનો ઉપયોગ કરીને પોલિસીમાં લખો namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  - to:
    - namespaceSelector:         # <<<
        matchLabels:             # <<<
          namespace: kube-system # <<<
    ports:
    - protocol: UDP
      port: 53
  policyTypes:
  - Egress

3. પેરાનોઇડ લોકો હજી પણ આગળ જઈ શકે છે અને DNS ક્વેરીઝને ચોક્કસ DNS સેવા સુધી મર્યાદિત કરી શકે છે kube-system. "નેમસ્પેસ અને પોડ્સ દ્વારા ફિલ્ટર કરો" વિભાગ તમને આ કેવી રીતે પ્રાપ્ત કરવું તે જણાવશે.

બીજો વિકલ્પ નેમસ્પેસ સ્તરે DNS ઉકેલવાનો છે. આ કિસ્સામાં, તેને દરેક સેવા માટે ખોલવાની જરૂર રહેશે નહીં:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.dns
  namespace: default
spec:
  podSelector: {} # <<<
  egress:
  - to:
    - namespaceSelector: {}
    ports:
    - protocol: UDP
      port: 53
  policyTypes:
  - Egress

ખાલી podSelector નેમસ્પેસમાં તમામ પોડ્સ પસંદ કરે છે.

પ્રથમ મેચ અને નિયમનો ક્રમ

પરંપરાગત ફાયરવોલમાં, પેકેટ પરની ક્રિયા (મંજૂરી આપો અથવા નામંજૂર કરો) તે પ્રથમ નિયમ દ્વારા નક્કી કરવામાં આવે છે જેને તે સંતોષે છે. કુબરનેટ્સમાં, નીતિઓના ક્રમમાં કોઈ ફરક પડતો નથી.

મૂળભૂત રીતે, જ્યારે કોઈ નીતિઓ સેટ કરવામાં આવતી નથી, ત્યારે પોડ્સ વચ્ચેના સંચારને મંજૂરી આપવામાં આવે છે અને તેઓ મુક્તપણે માહિતીની આપલે કરી શકે છે. એકવાર તમે નીતિઓ ઘડવાનું શરૂ કરો, તેમાંથી ઓછામાં ઓછા એકથી પ્રભાવિત દરેક પોડ તેને પસંદ કરેલી તમામ નીતિઓના વિસંવાદ (તાર્કિક અથવા) અનુસાર અલગ થઈ જાય છે. કોઈપણ પોલિસીથી પ્રભાવિત ન થતા શીંગો ખુલ્લા રહે છે.

તમે સ્ટ્રિપિંગ નિયમનો ઉપયોગ કરીને આ વર્તન બદલી શકો છો.

સ્ટ્રીપિંગ નિયમ ("નકારો")

ફાયરવોલ નીતિઓ સામાન્ય રીતે કોઈપણ ટ્રાફિકને નકારે છે જેને સ્પષ્ટપણે મંજૂરી આપવામાં આવતી નથી.

કુબરનેટ્સમાં કોઈ નામંજૂર ક્રિયા નથીજો કે, સ્ત્રોત પોડ્સના ખાલી જૂથ (પ્રવેશ)ને પસંદ કરીને નિયમિત (પરમિશન આપતી) નીતિ સાથે સમાન અસર પ્રાપ્ત કરી શકાય છે:

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

આ નીતિ નેમસ્પેસમાંના તમામ પોડ્સને પસંદ કરે છે અને આવનારા તમામ ટ્રાફિકને નકારીને, અવ્યાખ્યાયિત પ્રવેશને છોડી દે છે.

તેવી જ રીતે, તમે નેમસ્પેસમાંથી તમામ આઉટગોઇંગ ટ્રાફિકને પ્રતિબંધિત કરી શકો છો:

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

મહેરબાની કરીને નોંધ કરો નેમસ્પેસમાં પોડ્સ પર ટ્રાફિકને મંજૂરી આપતી કોઈપણ વધારાની નીતિઓ આ નિયમ પર અગ્રતા લેશે (ફાયરવોલ રૂપરેખાંકનમાં નામંજૂર નિયમ પહેલાં પરવાનગીનો નિયમ ઉમેરવા જેવું).

દરેક વસ્તુને મંજૂરી આપો (કોઈપણ-કોઈપણ-મંજૂરી આપો)

બધાને મંજૂરી આપો નીતિ બનાવવા માટે, તમારે ઉપરની નકારો નીતિને ખાલી ઘટક સાથે પૂરક બનાવવાની જરૂર છે ingress:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all
  namespace: default
spec:
  podSelector: {}
  ingress: # <<<
  - {}     # <<<
  policyTypes:
  - Ingress

તેમાંથી ઍક્સેસની મંજૂરી આપે છે નેમસ્પેસમાંના કોઈપણ પોડ માટે તમામ નેમસ્પેસ (અને તમામ આઈપી) માં તમામ પોડ્સ default. આ વર્તણૂક મૂળભૂત રીતે સક્ષમ છે, તેથી તેને સામાન્ય રીતે વધુ વ્યાખ્યાયિત કરવાની જરૂર નથી. જો કે, કેટલીકવાર તમારે સમસ્યાનું નિદાન કરવા માટે અમુક ચોક્કસ પરવાનગીઓને અસ્થાયી રૂપે અક્ષમ કરવાની જરૂર પડી શકે છે.

ફક્ત ઍક્સેસની મંજૂરી આપવા માટે નિયમને સંકુચિત કરી શકાય છે શીંગોનો ચોક્કસ સમૂહ (app:balance) નેમસ્પેસમાં default:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-to-balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  ingress: 
  - {}
  policyTypes:
  - Ingress

નીચેની નીતિ ક્લસ્ટરની બહાર કોઈપણ આઈપીની ઍક્સેસ સહિત તમામ પ્રવેશ અને બહાર નીકળવાના ટ્રાફિકને મંજૂરી આપે છે:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all
spec:
  podSelector: {}
  ingress:
  - {}
  egress:
  - {}
  policyTypes:
  - Ingress
  - Egress

બહુવિધ નીતિઓનું સંયોજન

ત્રણ સ્તરો પર લોજિકલ OR નો ઉપયોગ કરીને નીતિઓને જોડવામાં આવે છે; દરેક પોડની પરવાનગીઓ તેને અસર કરતી તમામ નીતિઓના વિચ્છેદન અનુસાર સેટ કરવામાં આવે છે:

1. ક્ષેત્રોમાં from и to ત્રણ પ્રકારના તત્વોને વ્યાખ્યાયિત કરી શકાય છે (તે બધા OR નો ઉપયોગ કરીને જોડાયેલા છે):

• namespaceSelector — સમગ્ર નેમસ્પેસ પસંદ કરે છે;
• podSelector - શીંગો પસંદ કરે છે;
• ipBlock - સબનેટ પસંદ કરે છે.

તદુપરાંત, પેટા વિભાગોમાં તત્વોની સંખ્યા (સમાન સમાન પણ) from/to મર્યાદિત નથી. તે બધાને તાર્કિક OR દ્વારા જોડવામાં આવશે.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
    - podSelector:
        matchLabels:
          app: admin
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

2. પોલિસી વિભાગની અંદર ingress ઘણા તત્વો હોઈ શકે છે from (લોજિકલ OR દ્વારા સંયુક્ત). એ જ રીતે, વિભાગ egress ઘણા ઘટકો શામેલ હોઈ શકે છે to (વિભાજન દ્વારા પણ સંયુક્ત):

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
  - from:
    - podSelector:
        matchLabels:
          app: admin
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

3. વિવિધ નીતિઓ પણ તાર્કિક OR સાથે જોડાયેલી છે

પરંતુ જ્યારે તેમને સંયોજિત કરવામાં આવે છે, ત્યારે ત્યાં એક મર્યાદા છે જેના પર નિર્દેશ ક્રિસ કુની: Kubernetes માત્ર વિવિધ સાથે પોલિસીને જોડી શકે છે policyTypes (Ingress અથવા Egress). પ્રવેશ (અથવા બહાર નીકળવું) ને વ્યાખ્યાયિત કરતી નીતિઓ એકબીજા પર ફરીથી લખશે.

નેમસ્પેસ વચ્ચેનો સંબંધ

મૂળભૂત રીતે, નેમસ્પેસ વચ્ચે માહિતી શેર કરવાની મંજૂરી છે. આને નકારવાની નીતિનો ઉપયોગ કરીને બદલી શકાય છે જે ટ્રાફિક આઉટગોઇંગ અને/અથવા નેમસ્પેસમાં ઇનકમિંગને પ્રતિબંધિત કરશે (ઉપર "સ્ટ્રિપિંગ નિયમ" જુઓ).

એકવાર તમે નેમસ્પેસની ઍક્સેસને અવરોધિત કરી લો (ઉપરનો "સ્ટ્રિપિંગ નિયમ" જુઓ), તમે ચોક્કસ નેમસ્પેસમાંથી જોડાણોને મંજૂરી આપીને નામંજૂર નીતિમાં અપવાદો બનાવી શકો છો. namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database.postgres
  namespace: database
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - namespaceSelector: # <<<
        matchLabels:
          namespace: default
  policyTypes:
  - Ingress

પરિણામે, નામની જગ્યામાં તમામ શીંગો default શીંગોની ઍક્સેસ હશે postgres નેમસ્પેસમાં database. પરંતુ જો તમે ઍક્સેસ ખોલવા માંગતા હોવ તો શું postgres નેમસ્પેસમાં માત્ર ચોક્કસ શીંગો default?

નેમસ્પેસ અને પોડ્સ દ્વારા ફિલ્ટર કરો

Kubernetes સંસ્કરણ 1.11 અને ઉચ્ચતમ તમને ઓપરેટરોને જોડવાની મંજૂરી આપે છે namespaceSelector и podSelector લોજિકલ AND નો ઉપયોગ કરીને. તે આના જેવું દેખાય છે:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database.postgres
  namespace: database
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          namespace: default
      podSelector: # <<<
        matchLabels:
          app: admin
  policyTypes:
  - Ingress

શા માટે આને સામાન્ય OR ને બદલે AND તરીકે અર્થઘટન કરવામાં આવે છે?

તે નોંધ લો podSelector હાઇફનથી શરૂ થતું નથી. YAML માં આનો અર્થ એ થાય છે podSelector અને તેની સામે ઉભો છે namespaceSelector સમાન સૂચિ તત્વનો સંદર્ભ લો. તેથી, તેઓ તાર્કિક AND સાથે જોડાયેલા છે.

પહેલાં હાઇફન ઉમેરવું podSelector નવી સૂચિ ઘટકના ઉદભવમાં પરિણમશે, જે પાછલા એક સાથે જોડવામાં આવશે namespaceSelector લોજિકલ OR નો ઉપયોગ કરીને.

ચોક્કસ લેબલ સાથે શીંગો પસંદ કરવા માટે તમામ નેમસ્પેસમાં, ખાલી દાખલ કરો namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database.postgres
  namespace: database
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          app: admin
  policyTypes:
  - Ingress

બહુવિધ લેબલ્સ I સાથે ટીમ બનાવે છે

બહુવિધ ઑબ્જેક્ટ્સ (યજમાનો, નેટવર્ક્સ, જૂથો) સાથેના ફાયરવોલ માટેના નિયમો લોજિકલ OR નો ઉપયોગ કરીને જોડવામાં આવે છે. જો પેકેટ સ્ત્રોત મેળ ખાતો હોય તો નીચેનો નિયમ કામ કરશે Host_1 અથવા Host_2:

| Source | Destination | Service | Action |
| ----------------------------------------|
| Host_1 | Subnet_A    | HTTPS   | Allow  |
| Host_2 |             |         |        |
| ----------------------------------------|

તેનાથી વિપરિત, કુબરનેટ્સમાં વિવિધ લેબલ્સ છે podSelector અથવા namespaceSelector લોજિકલ AND સાથે જોડવામાં આવે છે. ઉદાહરણ તરીકે, નીચેનો નિયમ પોડ્સ પસંદ કરશે જેમાં બંને લેબલ હોય, role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

સમાન તર્ક તમામ પ્રકારના ઓપરેટરોને લાગુ પડે છે: નીતિ લક્ષ્ય પસંદગીકારો, પોડ પસંદગીકારો અને નેમસ્પેસ પસંદગીકારો.

સબનેટ અને IP સરનામાં (IPBlocks)

ફાયરવોલ નેટવર્કને વિભાજિત કરવા માટે VLAN, IP સરનામાં અને સબનેટનો ઉપયોગ કરે છે.

Kubernetes માં, IP સરનામાં પોડ્સને આપમેળે સોંપવામાં આવે છે અને તે વારંવાર બદલાઈ શકે છે, તેથી નેટવર્ક નીતિઓમાં પોડ્સ અને નેમસ્પેસ પસંદ કરવા માટે લેબલનો ઉપયોગ કરવામાં આવે છે.

સબનેટ (ipBlocksઇનકમિંગ (ઇન્ગ્રેસ) અથવા આઉટગોઇંગ (એગ્રેસ) બાહ્ય (ઉત્તર-દક્ષિણ) જોડાણોનું સંચાલન કરતી વખતે ) નો ઉપયોગ થાય છે. ઉદાહરણ તરીકે, આ નીતિ નેમસ્પેસમાંથી તમામ પોડ્સ માટે ખુલે છે default Google DNS સેવાની ઍક્સેસ:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-dns
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 8.8.8.8/32
    ports:
    - protocol: UDP
      port: 53

આ ઉદાહરણમાં ખાલી પોડ સિલેક્ટરનો અર્થ છે "નેમસ્પેસમાં તમામ પોડ્સ પસંદ કરો."

આ નીતિ ફક્ત 8.8.8.8 સુધી પહોંચવાની મંજૂરી આપે છે; અન્ય કોઈપણ આઈપીની ઍક્સેસ પ્રતિબંધિત છે. તેથી, સારમાં, તમે આંતરિક કુબરનેટ્સ DNS સેવાની ઍક્સેસને અવરોધિત કરી છે. જો તમે હજી પણ તેને ખોલવા માંગતા હો, તો આ સ્પષ્ટપણે સૂચવો.

સામાન્ય રીતે ipBlocks и podSelectors પરસ્પર વિશિષ્ટ છે, કારણ કે પોડ્સના આંતરિક IP સરનામાઓનો ઉપયોગ કરવામાં આવતો નથી ipBlocks. સૂચવીને આંતરિક IP પોડ્સ, તમે વાસ્તવમાં આ સરનામાંઓ સાથે પોડ્સ સાથે/થી કનેક્શન્સને મંજૂરી આપશો. વ્યવહારમાં, તમે જાણતા નથી કે કયા IP સરનામાંનો ઉપયોગ કરવો, તેથી જ તેનો ઉપયોગ પોડ પસંદ કરવા માટે ન કરવો જોઈએ.

પ્રતિ-ઉદાહરણ તરીકે, નીચેની નીતિમાં તમામ IP નો સમાવેશ થાય છે અને તેથી તે અન્ય તમામ પોડ્સને ઍક્સેસ કરવાની મંજૂરી આપે છે:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-any
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0

તમે પોડ્સના આંતરિક IP સરનામાઓને બાદ કરતાં માત્ર બાહ્ય IP માટે જ ઍક્સેસ ખોલી શકો છો. ઉદાહરણ તરીકે, જો તમારા પોડનું સબનેટ 10.16.0.0/14 છે:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-any
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 10.16.0.0/14

બંદરો અને પ્રોટોકોલ

સામાન્ય રીતે શીંગો એક પોર્ટ સાંભળે છે. આનો અર્થ એ છે કે તમે ફક્ત નીતિઓમાં પોર્ટ નંબરનો ઉલ્લેખ કરી શકતા નથી અને બધું જ ડિફોલ્ટ તરીકે છોડી શકો છો. જો કે, નીતિઓને શક્ય તેટલી પ્રતિબંધિત બનાવવાની ભલામણ કરવામાં આવે છે, તેથી કેટલાક કિસ્સાઓમાં તમે હજી પણ પોર્ટનો ઉલ્લેખ કરી શકો છો:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
    - podSelector:
        matchLabels:
          app: admin
    ports:             # <<<
      - port: 443      # <<<
        protocol: TCP  # <<<
      - port: 80       # <<<
        protocol: TCP  # <<<
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

નોંધ કરો કે પસંદગીકાર ports બ્લોકમાંના તમામ ઘટકોને લાગુ પડે છે to અથવા from, જેમાં સમાવે છે. તત્વોના જુદા જુદા સેટ માટે વિવિધ પોર્ટનો ઉલ્લેખ કરવા માટે, વિભાજિત કરો ingress અથવા egress સાથે કેટલાક પેટાવિભાગોમાં to અથવા from અને દરેકમાં તમારા પોર્ટ રજીસ્ટર કરો:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
    ports:             # <<<
     - port: 443       # <<<
       protocol: TCP   # <<<
  - from:
    - podSelector:
        matchLabels:
          app: admin
    ports:             # <<<
     - port: 80        # <<<
       protocol: TCP   # <<<
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

ડિફૉલ્ટ પોર્ટ ઑપરેશન:

• જો તમે પોર્ટ વ્યાખ્યાને સંપૂર્ણપણે છોડી દો (ports), આનો અર્થ બધા પ્રોટોકોલ અને તમામ પોર્ટ છે;
• જો તમે પ્રોટોકોલ વ્યાખ્યાને છોડી દો તો (protocol), આનો અર્થ TCP;
• જો તમે પોર્ટ વ્યાખ્યા છોડી દો તો (port), આનો અર્થ બધા બંદરો છે.

શ્રેષ્ઠ પ્રેક્ટિસ: ડિફૉલ્ટ મૂલ્યો પર આધાર રાખશો નહીં, તમને જે જોઈએ છે તે સ્પષ્ટપણે સ્પષ્ટ કરો.

મહેરબાની કરીને નોંધ કરો કે તમારે પોડ પોર્ટનો ઉપયોગ કરવો આવશ્યક છે, સર્વિસ પોર્ટનો નહીં (આના પર વધુ આગળના ફકરામાં).

શું પોડ્સ અથવા સેવાઓ માટે નીતિઓ નિર્ધારિત છે?

સામાન્ય રીતે, કુબરનેટ્સમાં પોડ્સ સેવા દ્વારા એકબીજાને ઍક્સેસ કરે છે - એક વર્ચ્યુઅલ લોડ બેલેન્સર જે સેવાને અમલમાં મૂકતા પોડ્સ પર ટ્રાફિકને રીડાયરેક્ટ કરે છે. તમે વિચારી શકો છો કે નેટવર્ક નીતિઓ સેવાઓની ઍક્સેસને નિયંત્રિત કરે છે, પરંતુ આ કેસ નથી. કુબરનેટ્સ નેટવર્ક પોલિસી પોડ પોર્ટ પર કામ કરે છે, સર્વિસ પોર્ટ પર નહીં.

ઉદાહરણ તરીકે, જો કોઈ સેવા પોર્ટ 80 સાંભળે છે, પરંતુ ટ્રાફિકને તેના પોડ્સના પોર્ટ 8080 પર રીડાયરેક્ટ કરે છે, તો તમારે નેટવર્ક નીતિમાં બરાબર 8080 નો ઉલ્લેખ કરવો આવશ્યક છે.

આવી મિકેનિઝમને સબઓપ્ટિમલ ગણવી જોઈએ: જો સેવાની આંતરિક રચના (જેના પોડ્સ સાંભળે છે) બદલાય છે, તો નેટવર્ક નીતિઓને અપડેટ કરવી પડશે.

સર્વિસ મેશનો ઉપયોગ કરીને નવો આર્કિટેક્ચરલ અભિગમ (ઉદાહરણ તરીકે, નીચે Istio વિશે જુઓ - આશરે. અનુવાદ.) તમને આ સમસ્યાનો સામનો કરવા દે છે.

શું પ્રવેશ અને બહાર નીકળવા બંનેની નોંધણી કરવી જરૂરી છે?

ટૂંકો જવાબ હા છે, પોડ A ને પોડ B સાથે વાતચીત કરવા માટે, તેને આઉટગોઇંગ કનેક્શન બનાવવાની મંજૂરી હોવી આવશ્યક છે (આ માટે તમારે બહાર નીકળવાની નીતિ ગોઠવવાની જરૂર છે), અને પોડ B ઇનકમિંગ કનેક્શન સ્વીકારવા માટે સક્ષમ હોવું આવશ્યક છે ( આ માટે, તે મુજબ, તમારે પ્રવેશ નીતિની જરૂર છે. નીતિ).

જો કે, વ્યવહારમાં, તમે એક અથવા બંને દિશામાં જોડાણોને મંજૂરી આપવા માટે ડિફોલ્ટ નીતિ પર આધાર રાખી શકો છો.

જો અમુક પોડ-સ્રોત એક અથવા વધુ દ્વારા પસંદ કરવામાં આવશે દા.ત.-રાજકારણીઓ, તેના પર લાદવામાં આવેલા નિયંત્રણો તેમના વિસંવાદ દ્વારા નક્કી કરવામાં આવશે. આ કિસ્સામાં, તમારે સ્પષ્ટપણે પોડ સાથે જોડાણની મંજૂરી આપવાની જરૂર પડશે -સરનામું. જો કોઈ પોલિસી દ્વારા પોડ પસંદ કરવામાં આવ્યો નથી, તો તેના આઉટગોઇંગ (એગ્રેસ) ટ્રાફિકને ડિફોલ્ટ રૂપે મંજૂરી આપવામાં આવે છે.

તેવી જ રીતે, ફળીનું ભાગ્ય છેસરનામું, એક અથવા વધુ દ્વારા પસંદ કરેલ પ્રવેશ-રાજકારણીઓ, તેમના વિસંવાદ દ્વારા નક્કી કરવામાં આવશે. આ કિસ્સામાં, તમારે તેને સ્રોત પોડમાંથી ટ્રાફિક પ્રાપ્ત કરવાની સ્પષ્ટ મંજૂરી આપવી જોઈએ. જો કોઈ પોલિસી દ્વારા પોડ પસંદ કરવામાં આવ્યો નથી, તો તેના માટેના તમામ પ્રવેશ ટ્રાફિકને ડિફોલ્ટ રૂપે મંજૂરી આપવામાં આવે છે.

નીચે સ્ટેટફુલ અથવા સ્ટેટલેસ જુઓ.

લોગ્સ

Kubernetes નેટવર્ક નીતિઓ ટ્રાફિકને લૉગ કરી શકતી નથી. આનાથી તે નક્કી કરવું મુશ્કેલ બને છે કે શું નીતિ હેતુ મુજબ કામ કરી રહી છે અને સુરક્ષા વિશ્લેષણને ખૂબ જટિલ બનાવે છે.

બાહ્ય સેવાઓ માટે ટ્રાફિકનું નિયંત્રણ

Kubernetes નેટવર્ક નીતિઓ તમને બહાર નીકળવાના વિભાગોમાં સંપૂર્ણ લાયકાત ધરાવતા ડોમેન નામ (DNS) નો ઉલ્લેખ કરવાની મંજૂરી આપતી નથી. નિશ્ચિત IP સરનામું (જેમ કે aws.com) ન હોય તેવા બાહ્ય સ્થળો પર ટ્રાફિકને પ્રતિબંધિત કરવાનો પ્રયાસ કરતી વખતે આ હકીકત નોંધપાત્ર અસુવિધા તરફ દોરી જાય છે.

પોલિસી ચેક

ફાયરવોલ્સ તમને ચેતવણી આપશે અથવા તો ખોટી નીતિ સ્વીકારવાનો ઇનકાર કરશે. કુબરનેટ્સ પણ કેટલીક ચકાસણી કરે છે. kubectl દ્વારા નેટવર્ક નીતિ સેટ કરતી વખતે, Kubernetes જાહેર કરી શકે છે કે તે ખોટું છે અને તેને સ્વીકારવાનો ઇનકાર કરી શકે છે. અન્ય કિસ્સાઓમાં, કુબરનેટ્સ પોલિસી લેશે અને તેને ખૂટતી વિગતો સાથે ભરશે. તેઓ આદેશનો ઉપયોગ કરીને જોઈ શકાય છે:

kubernetes get networkpolicy <policy-name> -o yaml

ધ્યાનમાં રાખો કે કુબરનેટ્સ માન્યતા પ્રણાલી અચૂક નથી અને કેટલીક પ્રકારની ભૂલો ચૂકી શકે છે.

એક્ઝેક્યુશન

કુબરનેટ્સ પોતે નેટવર્ક નીતિઓ અમલમાં મૂકતું નથી, પરંતુ તે માત્ર એક API ગેટવે છે જે કન્ટેનર નેટવર્કિંગ ઈન્ટરફેસ (CNI) નામની અંતર્ગત સિસ્ટમને નિયંત્રણનો બોજ સોંપે છે. યોગ્ય CNI સોંપ્યા વિના કુબરનેટ્સ ક્લસ્ટર પર નીતિઓ સેટ કરવી એ ફાયરવોલ મેનેજમેન્ટ સર્વર પર ફાયરવોલ પર ઇન્સ્ટોલ કર્યા વિના પોલિસી બનાવવા સમાન છે. તમારી પાસે યોગ્ય CNI છે તેની ખાતરી કરવી તમારા પર નિર્ભર છે અથવા, Kubernetes પ્લેટફોર્મના કિસ્સામાં, ક્લાઉડમાં હોસ્ટ કરવામાં આવે છે (તમે પ્રદાતાઓની સૂચિ જોઈ શકો છો અહીં - આશરે ટ્રાન્સ.), નેટવર્ક નીતિઓને સક્ષમ કરો જે તમારા માટે CNI સેટ કરશે.

નોંધ કરો કે જો તમે યોગ્ય સહાયક CNI વિના નેટવર્ક નીતિ સેટ કરશો તો કુબરનેટ્સ તમને ચેતવણી આપશે નહીં.

સ્ટેટફુલ કે સ્ટેટલેસ?

બધા કુબરનેટ્સ CNIs મને મળ્યા છે તે સ્ટેટફુલ છે (ઉદાહરણ તરીકે, કેલિકો Linux કોન્ટ્રાકનો ઉપયોગ કરે છે). આ પોડને તેને પુનઃસ્થાપિત કર્યા વિના શરૂ કરેલ TCP કનેક્શન પર પ્રતિસાદ પ્રાપ્ત કરવાની મંજૂરી આપે છે. જો કે, હું કુબરનેટ્સ સ્ટાન્ડર્ડ વિશે જાણતો નથી જે સ્ટેટફુલનેસની ખાતરી આપે.

અદ્યતન સુરક્ષા નીતિ વ્યવસ્થાપન

કુબરનેટ્સમાં સુરક્ષા નીતિના અમલીકરણને સુધારવાની કેટલીક રીતો અહીં છે:

1. સર્વિસ મેશ આર્કિટેક્ચરલ પેટર્ન સેવા સ્તર પર વિગતવાર ટેલિમેટ્રી અને ટ્રાફિક નિયંત્રણ પ્રદાન કરવા માટે સાઇડકાર કન્ટેનરનો ઉપયોગ કરે છે. ઉદાહરણ તરીકે આપણે લઈ શકીએ ઇસ્ટિઓ.
2. કેટલાક CNI વિક્રેતાઓએ કુબરનેટ્સ નેટવર્ક નીતિઓથી આગળ વધવા માટે તેમના ટૂલ્સનો વિસ્તાર કર્યો છે.
3. તુફિન ઓર્કા Kubernetes નેટવર્ક નીતિઓની દૃશ્યતા અને ઓટોમેશન પ્રદાન કરે છે.

Tufin Orca પેકેજ કુબરનેટ્સ નેટવર્ક નીતિઓનું સંચાલન કરે છે (અને તે ઉપરના સ્ક્રીનશોટનો સ્ત્રોત છે).

વધારાની માહિતી

• GKE માંથી Ahmet Alp Balkan દ્વારા તૈયાર કરાયેલ નેટવર્ક નીતિઓના ઉદાહરણો;
• અધિકૃત Kubernetes વેબસાઇટ પરથી દસ્તાવેજીકરણ;
• કુબરનેટ્સ નેટવર્કિંગ મોડલ માટે માર્ગદર્શિકા;
• નેટવર્ક નીતિઓ તપાસવા માટેની સ્ક્રિપ્ટ.

નિષ્કર્ષ

Kubernetes નેટવર્ક નીતિઓ ક્લસ્ટરોને વિભાજિત કરવા માટે સાધનોનો સારો સમૂહ પ્રદાન કરે છે, પરંતુ તે સાહજિક નથી અને તેમાં ઘણી સૂક્ષ્મતા છે. આ જટિલતાને કારણે, હું માનું છું કે ઘણી વર્તમાન ક્લસ્ટર નીતિઓ બગડેલ છે. આ સમસ્યાના સંભવિત ઉકેલોમાં સ્વચાલિત નીતિ વ્યાખ્યાઓ અથવા અન્ય વિભાજન સાધનોનો ઉપયોગ શામેલ છે.

હું આશા રાખું છું કે આ માર્ગદર્શિકા કેટલાક પ્રશ્નોને દૂર કરવામાં અને તમને આવી શકે તેવી સમસ્યાઓ ઉકેલવામાં મદદ કરશે.

અનુવાદક તરફથી પીએસ

અમારા બ્લોગ પર પણ વાંચો:

• "ઇસ્ટિઓ સાથે માઇક્રોસર્વિસિસ પર પાછા": ભાગ 1 (મુખ્ય લક્ષણોનો પરિચય), ભાગ 2 (રાઉટીંગ, ટ્રાફિક કંટ્રોલ), ભાગ 3 (સુરક્ષા);
• "કુબરનેટ્સમાં નેટવર્કીંગ માટે એક સચિત્ર માર્ગદર્શિકા": ભાગો 1 અને 2 (નેટવર્ક મોડેલ, ઓવરલે નેટવર્ક્સ), ભાગ 3 (સેવાઓ અને ટ્રાફિક પ્રક્રિયા);
• «ડોકર અને કુબરનેટ્સ સુરક્ષાની માંગ કરતા વાતાવરણમાં»;
• «કુબરનેટ્સ સુરક્ષા માટે 9 શ્રેષ્ઠ પ્રયાસો»;
• «કુબરનેટ્સ હેકનો શિકાર બનવાની (નહીં) 11 રીતો».

સોર્સ: www.habr.com