🥇ආරක්ෂක වෘත්තිකයන් සඳහා Kubernetes ජාල ප්‍රතිපත්ති හඳුන්වාදීම

සටහන. පරිවර්තනය.: ලිපියේ කතුවරයා වන Reuven Harrison, මෘදුකාංග සංවර්ධනය පිළිබඳ වසර 20 කට වැඩි පළපුරුද්දක් ඇති අතර, අද ආරක්ෂක ප්‍රතිපත්ති කළමනාකරණ විසඳුම් නිර්මාණය කරන සමාගමක් වන Tufin හි CTO සහ සම-නිර්මාතෘ වේ. ඔහු Kubernetes ජාල ප්‍රතිපත්ති පොකුරක් තුළ ජාල ඛණ්ඩනය සඳහා තරමක් ප්‍රබල මෙවලමක් ලෙස සලකන අතර, ඒවා ප්‍රායෝගිකව ක්‍රියාත්මක කිරීම එතරම් පහසු නොවන බව ද ඔහු විශ්වාස කරයි. මෙම ද්රව්යය (තරමක් විශාල) මෙම ගැටළුව පිළිබඳ විශේෂඥයින්ගේ දැනුවත්භාවය වැඩිදියුණු කිරීමට සහ අවශ්ය වින්යාසයන් නිර්මාණය කිරීමට ඔවුන්ට උපකාර කිරීමට අදහස් කෙරේ.

අද, බොහෝ සමාගම් ඔවුන්ගේ යෙදුම් ධාවනය කිරීමට වැඩි වැඩියෙන් Kubernetes තෝරා ගනී. මෙම මෘදුකාංගය කෙරෙහි ඇති උනන්දුව කොතරම්ද යත් සමහරු Kubernetes හඳුන්වන්නේ "දත්ත මධ්‍යස්ථානය සඳහා වන නව මෙහෙයුම් පද්ධතිය" ලෙසයි. ක්‍රමයෙන්, Kubernetes (හෝ k8s) ව්‍යාපාරයේ තීරණාත්මක කොටසක් ලෙස වටහා ගැනීමට පටන් ගෙන ඇති අතර, ජාල ආරක්ෂාව ඇතුළු පරිණත ව්‍යාපාරික ක්‍රියාවලීන් සංවිධානය කිරීම අවශ්‍ය වේ.

Kubernetes සමඟ වැඩ කිරීමෙන් ප්‍රහේලිකාවක් ඇති ආරක්ෂක වෘත්තිකයන් සඳහා, සැබෑ හෙළිදරව්ව වේදිකාවේ පෙරනිමි ප්‍රතිපත්තිය විය හැකිය: සියල්ලට ඉඩ දෙන්න.

ජාල ප්‍රතිපත්තිවල අභ්‍යන්තර ව්‍යුහය තේරුම් ගැනීමට මෙම මාර්ගෝපදේශය ඔබට උපකාර කරනු ඇත; ඒවා සාමාන්‍ය ෆයර්වෝල් සඳහා වන නීතිවලට වඩා වෙනස් වන ආකාරය තේරුම් ගන්න. එය සමහර අන්තරායන් ආවරණය කරන අතර Kubernetes හි යෙදුම් සුරක්ෂිත කිරීමට උදවු කිරීමට නිර්දේශ ලබා දෙනු ඇත.

Kubernetes ජාල ප්රතිපත්ති

Kubernetes ජාල ප්‍රතිපත්ති යාන්ත්‍රණය ඔබට ජාල ස්ථරයේ වේදිකාවේ යොදවා ඇති යෙදුම්වල අන්තර්ක්‍රියා කළමනාකරණය කිරීමට ඉඩ සලසයි (OSI ආකෘතියේ තුන්වන). OSI Layer 7 බලාත්මක කිරීම සහ තර්ජන හඳුනාගැනීම වැනි නවීන ෆයර්වෝලවල සමහර උසස් විශේෂාංග ජාල ප්‍රතිපත්තිවල නොමැත, නමුත් ඒවා හොඳ ආරම්භක ලක්ෂ්‍යයක් වන මූලික මට්ටමේ ජාල ආරක්ෂාවක් සපයයි.

ජාල ප්‍රතිපත්ති කරල් අතර සන්නිවේදනය පාලනය කරයි

Kubernetes හි වැඩ බර කරල් හරහා බෙදා හරිනු ලැබේ, ඒවා එකට යොදවා ඇති බහාලුම් එකක් හෝ වැඩි ගණනකින් සමන්විත වේ. 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

ජාල ප්‍රතිපත්ති පිරිවිතර

Kubernetes ජාල ප්‍රතිපත්ති පිරිවිතරයට අංග හතරක් ඇතුළත් වේ:

podSelector: මෙම ප්‍රතිපත්තිය මගින් බලපෑමට ලක් වූ කරල් නිර්වචනය කරයි (ඉලක්ක) - අවශ්‍ය;
policyTypes: මෙයට ඇතුළත් කර ඇති ප්‍රතිපත්ති වර්ග මොනවාද යන්න දක්වයි: ඇතුල්වීම සහ/හෝ පිටවීම - විකල්ප, නමුත් මම එය සෑම අවස්ථාවකදීම පැහැදිලිව සඳහන් කිරීමට නිර්දේශ කරමි;
ingress: අවසරය නිර්වචනය කරයි එන ඉලක්ක කරල් වෙත ගමනාගමනය - විකල්ප;
egress: අවසරය නිර්වචනය කරයි පිටතට යන ඉලක්ක කරල් වලින් ගමනාගමනය විකල්ප වේ.

Kubernetes වෙබ් අඩවියෙන් ලබාගත් උදාහරණය (මම ප්‍රතිස්ථාපනය කළා 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 ඉවත් කර ඇත, ප්‍රතිපත්තිය සියලු ගමනාගමනය ප්‍රතික්ෂේප කරයි (පහත "ඉවත් කිරීමේ රීතිය" බලන්න).

පෙරනිමි ප්‍රතිපත්තිය Allow වේ

ප්‍රතිපත්ති නිර්වචනය කර නොමැති නම්, Kubernetes පෙරනිමියෙන් සියලුම ගමනාගමනයට ඉඩ දෙයි. සියලුම කරල් වලට නිදහසේ තොරතුරු හුවමාරු කර ගත හැකිය. ආරක්ෂක දෘෂ්ටිකෝණයකින් මෙය ප්‍රතිවිරෝධී බවක් පෙනෙන්නට ඇත, නමුත් Kubernetes මුලින් නිර්මාණය කර ඇත්තේ යෙදුම් අන්තර් ක්‍රියාකාරීත්වය සක්‍රීය කිරීම සඳහා සංවර්ධකයින් විසින් බව මතක තබා ගන්න. ජාල ප්‍රතිපත්ති පසුව එකතු කරන ලදී.

නාම අවකාශයන්

නාම අවකාශයන් යනු Kubernetes සහයෝගීතා යාන්ත්‍රණයයි. ඒවා නිර්මාණය කර ඇත්තේ තාර්කික පරිසරයන් එකිනෙකින් හුදකලා කිරීමට වන අතර, අවකාශයන් අතර සන්නිවේදනය පෙරනිමියෙන් ඉඩ දෙනු ලැබේ.

බොහෝ Kubernetes සංරචක මෙන්, ජාල ප්‍රතිපත්ති නිශ්චිත නාම අවකාශයක ජීවත් වේ. බ්ලොක් එකේ 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 ප්‍රතිපත්තිය තුළ ප්‍රතිපත්තිය අයත් වන නාම අවකාශයෙන් පොඩ් තෝරා ගනු ඇත (එය වෙනත් නාම අවකාශයකින් පොඩ් වෙත ප්‍රවේශය ප්‍රතික්ෂේප කර ඇත).

ඒ හා සමානව, podSelectors ඇතුල්වීම සහ පිටවීම අවහිර කිරීම් වලදී ඔබ ඒවා සමඟ ඒකාබද්ධ කරන්නේ නම් මිස, ඔවුන්ගේම නාම අවකාශයෙන් පමණක් කරල් තෝරාගත හැක 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

ලේබල්

ඔබට Pods සහ namespaces වැනි Kubernetes වස්තූන් වෙත අභිරුචි ලේබල ඇමිණිය හැක. ලේබල් (ලේබල් - ටැග්) යනු වලාකුළෙහි ඇති ටැග් වලට සමාන වේ. 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:
...

මූලාශ්රය සහ ගමනාන්තය

ෆයර්වෝල් ප්‍රතිපත්ති මූලාශ්‍ර සහ ගමනාන්ත සහිත නීති වලින් සමන්විත වේ. Kubernetes ජාල ප්‍රතිපත්ති නිර්වචනය කරනු ලබන්නේ ඉලක්කයක් සඳහාය - ඒවා අදාළ වන කරල් කට්ටලයක් - ඉන්පසු ඇතුල්වීම සහ/හෝ පිටවීම ගමනාගමනය සඳහා නීති සකසයි. අපගේ උදාහරණයේ දී, ප්‍රතිපත්තියේ ඉලක්කය නාම අවකාශයේ ඇති සියලුම කරල් වේ 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 මෙම ප්‍රතිපත්තිය තුළ, ඉලක්ක කරල් වෙත පැමිණෙන ගමනාගමනය විවෘත කරයි. වෙනත් වචන වලින් කිවහොත්, ඇතුල්වීම මූලාශ්‍රය වන අතර ඉලක්කය අනුරූප ගමනාන්තය වේ. එලෙසම, පිටවීම ගමනාන්තය වන අතර ඉලක්කය එහි මූලාශ්‍රය වේ.

මෙය ෆයර්වෝල් නීති දෙකකට සමාන වේ: Ingress → Target; ඉලක්කය → පිටවීම.

පිටවීම සහ DNS (වැදගත්!)

පිටතට යන ගමනාගමනය සීමා කිරීමෙන්, DNS වෙත විශේෂ අවධානයක් යොමු කරන්න - IP ලිපින වෙත සේවාවන් සිතියම්ගත කිරීමට Kubernetes මෙම සේවාව භාවිතා කරයි. උදාහරණයක් ලෙස, ඔබ යෙදුමට අවසර දී නොමැති නිසා පහත ප්‍රතිපත්තිය ක්‍රියා නොකරනු ඇත 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 විමසුම් සුදුසු Kubernetes සේවාව වෙත යවන්න (සාමාන්‍යයෙන් අවකාශයේ ධාවනය වේ 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 නාම අවකාශයේ සියලුම පොඩ් තෝරා ගනී.

පළමු තරගය සහ රීති අනුපිළිවෙල

සාම්ප්‍රදායික ෆයර්වෝල් වලදී, පැකට්ටුවක ක්‍රියාව (අවසර හෝ ප්‍රතික්ෂේප කිරීම) තීරණය වන්නේ එය තෘප්තිමත් වන පළමු රීතිය මගිනි. Kubernetes හි, ප්‍රතිපත්තිවල අනුපිළිවෙල වැදගත් නොවේ.

පෙරනිමියෙන්, ප්‍රතිපත්ති කිසිවක් සකසා නොමැති විට, කරල් අතර සන්නිවේදනයට අවසර දී ඇති අතර ඒවාට නිදහසේ තොරතුරු හුවමාරු කර ගත හැක. ඔබ ප්‍රතිපත්ති සැකසීමට පටන් ගත් පසු, අවම වශයෙන් එක් අයෙකුගෙන් බලපෑමට ලක් වූ සෑම පොඩ් එකක්ම එය තෝරාගත් සියලුම ප්‍රතිපත්තිවල විසංයෝජනය (තාර්කික OR) අනුව හුදකලා වේ. කිසිදු ප්‍රතිපත්තියකින් බලපෑමට ලක් නොවන කරල් විවෘතව පවතී.

ඉවත් කිරීමේ රීතියක් භාවිතයෙන් ඔබට මෙම හැසිරීම වෙනස් කළ හැකිය.

ඉවත් කිරීමේ රීතිය ("ප්‍රතික්ෂේප කරන්න")

ෆයර්වෝල් ප්‍රතිපත්ති සාමාන්‍යයෙන් පැහැදිලිව ඉඩ නොදෙන ඕනෑම ගමනාගමනයක් ප්‍රතික්ෂේප කරයි.

Kubernetes හි ප්‍රතික්ෂේප ක්‍රියාවක් නොමැත, කෙසේ වෙතත්, හිස් ප්‍රභව කරල් සමූහයක් (ඇතුළත් වීම) තේරීමෙන් සාමාන්‍ය (අවසර) ප්‍රතිපත්තියක් සමඟ සමාන බලපෑමක් ලබා ගත හැක:

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

වෙතින් ප්රවේශ වීමට ඉඩ සලසයි සියලුම නාම අවකාශයන්හි ඇති සියලුම පොඩ් (සහ සියලුම IP) නාම අවකාශයේ ඕනෑම පොඩ් එකකට 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

පහත ප්‍රතිපත්තිය පොකුරෙන් පිටත ඕනෑම IP වෙත ප්‍රවේශය ඇතුළුව සියලුම ඇතුල්වීම් සහ පිටවීමේ ගමනාගමනයට ඉඩ දෙයි:

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

බහුවිධ ප්‍රතිපත්ති ඒකාබද්ධ කිරීම

ප්‍රතිපත්ති තාර්කික හෝ මට්ටම් තුනකින් ඒකාබද්ධ කෙරේ; සෑම පොඩ් එකකම අවසර එයට බලපාන සියලුම ප්‍රතිපත්තිවල විසංයෝජනයට අනුකූලව සකසා ඇත:

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 hyphen එකකින් ආරම්භ නොවේ. 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 |             |         |        |
| ----------------------------------------|

ඊට පටහැනිව, Kubernetes හි විවිධ ලේබල් ඇත 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 වෙත පමණක් ප්‍රවේශ වීමට ඉඩ දෙයි; වෙනත් IP වෙත ප්‍රවේශ වීම තහනම්ය. එබැවින්, සාරය වශයෙන්, ඔබ අභ්යන්තර Kubernetes 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), මෙයින් අදහස් කරන්නේ සියලුම වරායන් ය.

හොඳම භාවිතය: පෙරනිමි අගයන් මත රඳා නොසිටින්න, ඔබට අවශ්‍ය දේ පැහැදිලිව සඳහන් කරන්න.

ඔබ සේවා වරායන් නොව පොඩ් පෝට් භාවිතා කළ යුතු බව කරුණාවෙන් සලකන්න (ඊළඟ ඡේදයේ මේ ගැන වැඩි විස්තර).

කරල් හෝ සේවා සඳහා ප්‍රතිපත්ති නිර්වචනය කර තිබේද?

සාමාන්‍යයෙන්, Kubernetes හි කරල් එකිනෙක වෙත ප්‍රවේශ වන්නේ සේවාවක් හරහාය - සේවාව ක්‍රියාත්මක කරන කරල් වෙත ගමනාගමනය හරවා යවන අතථ්‍ය පැටවුම් සමතුලිතයකි. ජාල ප්‍රතිපත්ති මගින් සේවා වෙත ප්‍රවේශය පාලනය කරන බව ඔබ සිතනු ඇත, නමුත් මෙය එසේ නොවේ. Kubernetes ජාල ප්‍රතිපත්ති ක්‍රියා කරන්නේ සේවා වරායන් මත නොව පොඩ් පෝට් මත ය.

උදාහරණයක් ලෙස, සේවාවක් වරාය 80 ට සවන් දෙන්නේ නම්, නමුත් එහි පොඩ් වල 8080 වරාය වෙත ගමනාගමනය හරවා යවන්නේ නම්, ඔබ ජාල ප්‍රතිපත්තියේ හරියටම 8080 සඳහන් කළ යුතුය.

එවැනි යාන්ත්‍රණයක් උප ප්‍රශස්ත ලෙස සැලකිය යුතුය: සේවාවේ අභ්‍යන්තර ව්‍යුහය (පොඩ්ස් සවන් දෙන වරායන්) වෙනස් වුවහොත්, ජාල ප්‍රතිපත්ති යාවත්කාලීන කිරීමට සිදුවේ.

Service Mesh භාවිතයෙන් නව වාස්තුවිද්‍යාත්මක ප්‍රවේශය (උදාහරණයක් ලෙස, පහත ඉස්තියෝ ගැන බලන්න - දළ වශයෙන් පරිවර්තනය.) මෙම ගැටලුව සමඟ සාර්ථකව කටයුතු කිරීමට ඔබට ඉඩ සලසයි.

ඇතුල්වීම සහ පිටවීම යන දෙකම ලියාපදිංචි කිරීම අවශ්‍යද?

කෙටි පිළිතුර ඔව්, Pod A හට Pod B සමඟ සන්නිවේදනය කිරීම සඳහා, එය පිටතට යන සම්බන්ධතාවයක් නිර්මාණය කිරීමට ඉඩ දිය යුතුය (මේ සඳහා ඔබ පිටවීමේ ප්‍රතිපත්තියක් වින්‍යාසගත කළ යුතුය), සහ Pod B හට පැමිණෙන සම්බන්ධතාවයක් පිළිගැනීමට හැකි විය යුතුය ( මේ සඳහා, ඒ අනුව, ඔබට ඇතුල්වීමේ ප්‍රතිපත්තියක් අවශ්‍ය වේ).

කෙසේ වෙතත්, ප්‍රායෝගිකව, ඔබට එක් දිශාවකට හෝ දෙපැත්තකට සම්බන්ධතා ඉඩ දීමට පෙරනිමි ප්‍රතිපත්තිය මත විශ්වාසය තැබිය හැක.

පොඩ් ටිකක් නම් -ප්රභවය එකක් හෝ කිහිපයක් විසින් තෝරා ගනු ලැබේ පිටවීම-දේශපාලකයින්, එයට පනවා ඇති සීමාවන් ඔවුන්ගේ විසංයෝජනය අනුව තීරණය වේ. මෙම අවස්ථාවෙහිදී, ඔබ පොඩ් වෙත සම්බන්ධ වීමට පැහැදිලිවම ඉඩ දීමට අවශ්‍ය වනු ඇත -ලිපිනයට. කිසියම් ප්‍රතිපත්තියක් මගින් පොඩ් එකක් තෝරා නොගන්නේ නම්, එහි පිටතට යන (පිටවීම) ගමනාගමනය පෙරනිමියෙන් ඉඩ දෙනු ලැබේ.

ඒ හා සමානව, පෝඩ්ගේ ඉරණම වේලිපිනය, එකක් හෝ කිහිපයක් විසින් තෝරා ගන්නා ලදී ඇතුල්වීම-දේශපාලකයින්, ඔවුන්ගේ විසංයෝජනය අනුව තීරණය වේ. මෙම අවස්ථාවේදී, ඔබ එයට මූලාශ්‍ර පොඩ් එකෙන් ගමනාගමනය ලබා ගැනීමට පැහැදිලිවම ඉඩ දිය යුතුය. කිසියම් ප්‍රතිපත්තියක් මගින් පොඩ් එකක් තෝරා නොගන්නේ නම්, ඒ සඳහා සියලුම ඇතුල්වීමේ ගමනාගමනය පෙරනිමියෙන් අවසර දෙනු ලැබේ.

පහතින් Stateful හෝ Stateless බලන්න.

සටහන්

Kubernetes ජාල ප්‍රතිපත්තිවලට ගමනාගමනය ලොග් කළ නොහැක. මෙය ප්‍රතිපත්තියක් අපේක්ෂිත පරිදි ක්‍රියා කරන්නේද යන්න තීරණය කිරීම දුෂ්කර කරන අතර ආරක්ෂක විශ්ලේෂණය බෙහෙවින් සංකීර්ණ කරයි.

බාහිර සේවාවන් වෙත ගමනාගමනය පාලනය කිරීම

Kubernetes ජාල ප්‍රතිපත්ති මඟින් පිටවීමේ කොටස්වල සම්පූර්ණ සුදුසුකම් ලත් ඩොමේන් නාමයක් (DNS) සඳහන් කිරීමට ඔබට ඉඩ නොදේ. ස්ථාවර IP ලිපිනයක් (aws.com වැනි) නොමැති බාහිර ගමනාන්ත වෙත ගමනාගමනය සීමා කිරීමට උත්සාහ කිරීමේදී මෙම කරුණ සැලකිය යුතු අපහසුතාවයක් ඇති කරයි.

ප්‍රතිපත්ති පරීක්ෂාව

ෆයර්වෝල් ඔබට අනතුරු අඟවනු ඇත, නැතහොත් වැරදි ප්‍රතිපත්තිය පිළිගැනීම ප්‍රතික්ෂේප කරයි. Kubernetes ද යම් සත්‍යාපනයක් කරයි. kubectl හරහා ජාල ප්‍රතිපත්තියක් සැකසීමේදී, Kubernetes එය වැරදි බව ප්‍රකාශ කළ හැකි අතර එය පිළිගැනීම ප්‍රතික්ෂේප කරයි. වෙනත් අවස්ථාවල දී, Kubernetes ප්‍රතිපත්තිය ගෙන එය නැතිවූ විස්තර සමඟ පුරවනු ඇත. විධානය භාවිතයෙන් ඒවා දැකිය හැකිය:

kubernetes get networkpolicy <policy-name> -o yaml

Kubernetes වලංගු කිරීමේ පද්ධතිය නොවරදින එකක් නොවන අතර සමහර ආකාරයේ දෝෂ මඟ හැරිය හැකි බව මතක තබා ගන්න.

ක්රියාත්මක කිරීම

Kubernetes ජාල ප්‍රතිපත්ති ක්‍රියාත්මක නොකරන නමුත්, බහාලුම් ජාලකරණ අතුරුමුහුණත (CNI) නම් යටින් පවතින පද්ධතියකට පාලන බර පවරන API ද්වාරයක් පමණි. සුදුසු CNI පැවරීමකින් තොරව Kubernetes පොකුරක් මත ප්‍රතිපත්ති සැකසීම ෆයර්වෝල් මත ස්ථාපනය නොකර ෆයර්වෝල් කළමනාකරණ සේවාදායකයක් මත ප්‍රතිපත්ති සෑදීමට සමාන වේ. ඔබට හොඳ CNI එකක් ඇති බව සහතික කිරීම හෝ, Kubernetes වේදිකා සම්බන්ධයෙන්, වලාකුළෙහි සත්කාරකත්වය ලබා දීම ඔබ සතුය. (ඔබට සපයන්නන්ගේ ලැයිස්තුව බලන්න පුළුවන් මෙහි - ආසන්න වශයෙන්. පරිවර්තනය.), ඔබ වෙනුවෙන් CNI සකසන ජාල ප්‍රතිපත්ති සබල කරන්න.

ඔබ සුදුසු සහායක CNI නොමැතිව ජාල ප්‍රතිපත්තියක් සකසා ඇත්නම් Kubernetes ඔබට අනතුරු අඟවන්නේ නැති බව සලකන්න.

රාජ්ය හෝ රාජ්ය නැති?

මා මුහුණ දුන් සියලුම Kubernetes CNI ප්‍රකාශිත ඒවා වේ (උදාහරණයක් ලෙස, Calico Linux conntrack භාවිතා කරයි). මෙය නැවත ස්ථාපිත කිරීමකින් තොරව එය ආරම්භ කරන ලද TCP සම්බන්ධතාවයේ ප්‍රතිචාර ලබා ගැනීමට පොඩ් හට ඉඩ සලසයි. කෙසේ වෙතත්, රාජ්‍යත්වය සහතික කරන Kubernetes ප්‍රමිතියක් ගැන මම නොදනිමි.

උසස් ආරක්ෂක ප්‍රතිපත්ති කළමනාකරණය

Kubernetes හි ආරක්ෂක ප්‍රතිපත්ති බලාත්මක කිරීම වැඩිදියුණු කිරීමට ක්‍රම කිහිපයක් මෙන්න:

Service Mesh වාස්තුවිද්‍යාත්මක රටාව සේවා මට්ටමින් සවිස්තරාත්මක දුරමිතික සහ රථවාහන පාලනය සැපයීම සඳහා පැති කාර් බහාලුම් භාවිතා කරයි. උදාහරණයක් ලෙස අපට ගත හැකිය ඉස්ටියෝ.
සමහර CNI වෙළෙන්දන් Kubernetes ජාල ප්‍රතිපත්තිවලින් ඔබ්බට යාමට ඔවුන්ගේ මෙවලම් දිගු කර ඇත.
Tufin Orca Kubernetes ජාල ප්‍රතිපත්තිවල දෘශ්‍යතාව සහ ස්වයංක්‍රීයකරණය සපයයි.

Tufin Orca පැකේජය Kubernetes ජාල ප්‍රතිපත්ති කළමනාකරණය කරයි (සහ ඉහත තිරපිටපත් වල මූලාශ්‍රය වේ).

අමතර තොරතුරු

නිගමනය

Kubernetes ජාල ප්‍රතිපත්ති පොකුරු කොටස් කිරීම සඳහා හොඳ මෙවලම් කට්ටලයක් ලබා දෙයි, නමුත් ඒවා අවබෝධාත්මක නොවන අතර බොහෝ සියුම්කම් ඇත. මෙම සංකීර්ණත්වය නිසා, පවතින බොහෝ පොකුරු ප්‍රතිපත්ති දෝෂ සහිත බව මම විශ්වාස කරමි. මෙම ගැටලුව සඳහා විය හැකි විසඳුම් අතර ප්‍රතිපත්ති නිර්වචන ස්වයංක්‍රීය කිරීම හෝ වෙනත් කොටස් කිරීමේ මෙවලම් භාවිතා කිරීම ඇතුළත් වේ.

මෙම මාර්ගෝපදේශය සමහර ප්‍රශ්න නිරවුල් කිරීමට සහ ඔබට මුහුණ දීමට සිදු විය හැකි ගැටළු විසඳීමට උපකාරී වනු ඇතැයි මම බලාපොරොත්තු වෙමි.

පරිවර්තකගෙන් PS

අපගේ බ්ලොග් අඩවියේ ද කියවන්න:

"ඉස්ටියෝ සමඟ ක්ෂුද්‍ර සේවා වෙත ආපසු": 1 කොටස (ප්‍රධාන අංගයන් හැඳින්වීම), 2 කොටස (මාර්ගගත කිරීම, රථවාහන පාලනය), 3 කොටස (ආරක්ෂාව);
"Kubernetes හි ජාලකරණය සඳහා නිදර්ශන මාර්ගෝපදේශයක්": කොටස් 1 සහ 2 (ජාල ආකෘතිය, ආවරණ ජාල), 3 කොටස (සේවා සහ රථවාහන සැකසීම);
«ආරක්‍ෂාව ඉල්ලන පරිසරයක ඩොකර් සහ කුබර්නෙට්ස්»;
«9 Kubernetes ආරක්ෂක හොඳම භාවිතයන්»;
«Kubernetes Hack එකක ගොදුරක් වීමට (නොවන) මාර්ග 11".

මූලාශ්රය: www.habr.com

ආරක්ෂක වෘත්තිකයන් සඳහා Kubernetes ජාල ප්‍රතිපත්ති පිළිබඳ හැඳින්වීමක්

Kubernetes ජාල ප්රතිපත්ති

ජාල ප්‍රතිපත්ති කරල් අතර සන්නිවේදනය පාලනය කරයි

ජාල ප්‍රතිපත්ති නිර්වචනය කිරීම

ජාල ප්‍රතිපත්ති පිරිවිතර

පෙරනිමි ප්‍රතිපත්තිය Allow වේ

නාම අවකාශයන්

ප්‍රතිපත්ති නම් කිරීමේ රීති

ලේබල්

මූලාශ්රය සහ ගමනාන්තය

පිටවීම සහ DNS (වැදගත්!)

පළමු තරගය සහ රීති අනුපිළිවෙල

ඉවත් කිරීමේ රීතිය ("ප්‍රතික්ෂේප කරන්න")

සියල්ලට ඉඩ දෙන්න (ඕනෑම-ඕනෑම-ඕනෑම-අවසර)

බහුවිධ ප්‍රතිපත්ති ඒකාබද්ධ කිරීම

නාම අවකාශයන් අතර සම්බන්ධතාවය

නාම අවකාශයන් සහ කරල් අනුව පෙරන්න

I සමඟ බහු ලේබල් කණ්ඩායමක්

උපජාල සහ IP ලිපින (IPBlocks)

වරාය සහ ප්රොටෝකෝල

කරල් හෝ සේවා සඳහා ප්‍රතිපත්ති නිර්වචනය කර තිබේද?

ඇතුල්වීම සහ පිටවීම යන දෙකම ලියාපදිංචි කිරීම අවශ්‍යද?

සටහන්

බාහිර සේවාවන් වෙත ගමනාගමනය පාලනය කිරීම

ප්‍රතිපත්ති පරීක්ෂාව

ක්රියාත්මක කිරීම

රාජ්ය හෝ රාජ්ය නැති?

උසස් ආරක්ෂක ප්‍රතිපත්ති කළමනාකරණය

අමතර තොරතුරු

නිගමනය

පරිවර්තකගෙන් PS

අදහස් එක් කරන්න

ආරක්ෂක වෘත්තිකයන් සඳහා Kubernetes ජාල ප්‍රතිපත්ති පිළිබඳ හැඳින්වීමක්

Kubernetes ජාල ප්රතිපත්ති

ජාල ප්‍රතිපත්ති කරල් අතර සන්නිවේදනය පාලනය කරයි

ජාල ප්‍රතිපත්ති නිර්වචනය කිරීම

ජාල ප්‍රතිපත්ති පිරිවිතර

පෙරනිමි ප්‍රතිපත්තිය Allow වේ

නාම අවකාශයන්

ප්‍රතිපත්ති නම් කිරීමේ රීති

ලේබල්

මූලාශ්රය සහ ගමනාන්තය

පිටවීම සහ DNS (වැදගත්!)

පළමු තරගය සහ රීති අනුපිළිවෙල

ඉවත් කිරීමේ රීතිය ("ප්‍රතික්ෂේප කරන්න")

සියල්ලට ඉඩ දෙන්න (ඕනෑම-ඕනෑම-ඕනෑම-අවසර)

බහුවිධ ප්‍රතිපත්ති ඒකාබද්ධ කිරීම

නාම අවකාශයන් අතර සම්බන්ධතාවය

නාම අවකාශයන් සහ කරල් අනුව පෙරන්න

I සමඟ බහු ලේබල් කණ්ඩායමක්

උපජාල සහ IP ලිපින (IPBlocks)

වරාය සහ ප්රොටෝකෝල

කරල් හෝ සේවා සඳහා ප්‍රතිපත්ති නිර්වචනය කර තිබේද?

ඇතුල්වීම සහ පිටවීම යන දෙකම ලියාපදිංචි කිරීම අවශ්‍යද?

සටහන්

බාහිර සේවාවන් වෙත ගමනාගමනය පාලනය කිරීම

ප්‍රතිපත්ති පරීක්ෂාව

ක්රියාත්මක කිරීම

රාජ්ය හෝ රාජ්ය නැති?

උසස් ආරක්ෂක ප්‍රතිපත්ති කළමනාකරණය

අමතර තොරතුරු

නිගමනය

පරිවර්තකගෙන් PS

අදහස් එක් කරන්න ඊ-මේල් මගින් පිලිතුරු දෙන්න අවලංගු

අදහස් එක් කරන්න