ಭದ್ರತಾ ವೃತ್ತಿಪರರಿಗಾಗಿ ಕುಬರ್ನೆಟ್ಸ್ ನೆಟ್ವರ್ಕ್ ನೀತಿಗಳಿಗೆ ಒಂದು ಪರಿಚಯ

ಸೂಚನೆ. ಅನುವಾದ.: ಲೇಖನದ ಲೇಖಕ, ರೆವೆನ್ ಹ್ಯಾರಿಸನ್, ಸಾಫ್ಟ್‌ವೇರ್ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ 20 ವರ್ಷಗಳ ಅನುಭವವನ್ನು ಹೊಂದಿದ್ದಾರೆ ಮತ್ತು ಇಂದು ಭದ್ರತಾ ನೀತಿ ನಿರ್ವಹಣಾ ಪರಿಹಾರಗಳನ್ನು ರಚಿಸುವ ಕಂಪನಿಯಾದ ಟುಫಿನ್‌ನ CTO ಮತ್ತು ಸಹ-ಸಂಸ್ಥಾಪಕರಾಗಿದ್ದಾರೆ. ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ನೆಟ್‌ವರ್ಕ್ ವಿಭಜನೆಗಾಗಿ ಕುಬರ್ನೆಟ್ಸ್ ನೆಟ್‌ವರ್ಕ್ ನೀತಿಗಳನ್ನು ಸಾಕಷ್ಟು ಶಕ್ತಿಯುತ ಸಾಧನವಾಗಿ ಅವರು ವೀಕ್ಷಿಸುತ್ತಿರುವಾಗ, ಅವರು ಪ್ರಾಯೋಗಿಕವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲು ಅಷ್ಟು ಸುಲಭವಲ್ಲ ಎಂದು ನಂಬುತ್ತಾರೆ. ಈ ವಸ್ತು (ಸಾಕಷ್ಟು ದೊಡ್ಡದು) ಈ ಸಮಸ್ಯೆಯ ಬಗ್ಗೆ ತಜ್ಞರ ಅರಿವನ್ನು ಸುಧಾರಿಸಲು ಮತ್ತು ಅಗತ್ಯ ಸಂರಚನೆಗಳನ್ನು ರಚಿಸಲು ಅವರಿಗೆ ಸಹಾಯ ಮಾಡಲು ಉದ್ದೇಶಿಸಲಾಗಿದೆ.

ಇಂದು, ಅನೇಕ ಕಂಪನಿಗಳು ತಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಚಲಾಯಿಸಲು ಕುಬರ್ನೆಟ್‌ಗಳನ್ನು ಹೆಚ್ಚಾಗಿ ಆಯ್ಕೆಮಾಡುತ್ತಿವೆ. ಈ ಸಾಫ್ಟ್‌ವೇರ್‌ನಲ್ಲಿ ಆಸಕ್ತಿ ತುಂಬಾ ಹೆಚ್ಚಿದ್ದು, ಕೆಲವರು ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು "ಡೇಟಾ ಸೆಂಟರ್‌ಗಾಗಿ ಹೊಸ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್" ಎಂದು ಕರೆಯುತ್ತಿದ್ದಾರೆ. ಕ್ರಮೇಣ, ಕುಬರ್ನೆಟ್ಸ್ (ಅಥವಾ k8s) ವ್ಯವಹಾರದ ನಿರ್ಣಾಯಕ ಭಾಗವಾಗಿ ಗ್ರಹಿಸಲು ಪ್ರಾರಂಭಿಸಿದೆ, ಇದು ನೆಟ್ವರ್ಕ್ ಭದ್ರತೆ ಸೇರಿದಂತೆ ಪ್ರಬುದ್ಧ ವ್ಯಾಪಾರ ಪ್ರಕ್ರಿಯೆಗಳ ಸಂಘಟನೆಯ ಅಗತ್ಯವಿರುತ್ತದೆ.

ಕುಬರ್ನೆಟ್ಸ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಮೂಲಕ ಗೊಂದಲಕ್ಕೊಳಗಾದ ಭದ್ರತಾ ವೃತ್ತಿಪರರಿಗೆ, ನೈಜ ಬಹಿರಂಗಪಡಿಸುವಿಕೆಯು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನ ಡೀಫಾಲ್ಟ್ ನೀತಿಯಾಗಿರಬಹುದು: ಎಲ್ಲವನ್ನೂ ಅನುಮತಿಸಿ.

ನೆಟ್‌ವರ್ಕ್ ನೀತಿಗಳ ಆಂತರಿಕ ರಚನೆಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಈ ಮಾರ್ಗದರ್ಶಿ ನಿಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ; ಸಾಮಾನ್ಯ ಫೈರ್‌ವಾಲ್‌ಗಳ ನಿಯಮಗಳಿಂದ ಅವು ಹೇಗೆ ಭಿನ್ನವಾಗಿವೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ. ಇದು ಕೆಲವು ಮೋಸಗಳನ್ನು ಸಹ ಒಳಗೊಂಡಿದೆ ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಸುರಕ್ಷಿತ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಸಹಾಯ ಮಾಡಲು ಶಿಫಾರಸುಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ.

ಕುಬರ್ನೆಟ್ಸ್ ನೆಟ್ವರ್ಕ್ ನೀತಿಗಳು

ನೆಟ್‌ವರ್ಕ್ ಲೇಯರ್‌ನಲ್ಲಿ ಪ್ಲ್ಯಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿ ನಿಯೋಜಿಸಲಾದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಪರಸ್ಪರ ಕ್ರಿಯೆಯನ್ನು ನಿರ್ವಹಿಸಲು ಕುಬರ್ನೆಟ್ಸ್ ನೆಟ್‌ವರ್ಕ್ ನೀತಿ ಕಾರ್ಯವಿಧಾನವು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ (ಒಎಸ್‌ಐ ಮಾದರಿಯಲ್ಲಿ ಮೂರನೆಯದು). ನೆಟ್‌ವರ್ಕ್ ನೀತಿಗಳು ಆಧುನಿಕ ಫೈರ್‌ವಾಲ್‌ಗಳ ಕೆಲವು ಸುಧಾರಿತ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ, ಉದಾಹರಣೆಗೆ OSI ಲೇಯರ್ 7 ಜಾರಿ ಮತ್ತು ಬೆದರಿಕೆ ಪತ್ತೆ, ಆದರೆ ಅವುಗಳು ಉತ್ತಮ ಆರಂಭದ ಹಂತವಾಗಿರುವ ನೆಟ್‌ವರ್ಕ್ ಭದ್ರತೆಯ ಮೂಲಭೂತ ಮಟ್ಟವನ್ನು ಒದಗಿಸುತ್ತವೆ.

ನೆಟ್‌ವರ್ಕ್ ನೀತಿಗಳು ಪಾಡ್‌ಗಳ ನಡುವಿನ ಸಂವಹನವನ್ನು ನಿಯಂತ್ರಿಸುತ್ತವೆ

ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿನ ಕೆಲಸದ ಹೊರೆಗಳನ್ನು ಪಾಡ್‌ಗಳಾದ್ಯಂತ ವಿತರಿಸಲಾಗುತ್ತದೆ, ಇದು ಒಟ್ಟಿಗೆ ನಿಯೋಜಿಸಲಾದ ಒಂದು ಅಥವಾ ಹೆಚ್ಚಿನ ಕಂಟೇನರ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಕುಬರ್ನೆಟ್ಸ್ ಪ್ರತಿ ಪಾಡ್‌ಗೆ ಇತರ ಪಾಡ್‌ಗಳಿಂದ ಪ್ರವೇಶಿಸಬಹುದಾದ IP ವಿಳಾಸವನ್ನು ನಿಯೋಜಿಸುತ್ತದೆ. ವರ್ಚುವಲ್ ಮೆಷಿನ್ ನಿದರ್ಶನಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ನಿಯಂತ್ರಿಸಲು ಕ್ಲೌಡ್‌ನಲ್ಲಿನ ಭದ್ರತಾ ಗುಂಪುಗಳನ್ನು ಬಳಸುವ ರೀತಿಯಲ್ಲಿಯೇ ಕುಬರ್ನೆಟ್ಸ್ ನೆಟ್‌ವರ್ಕ್ ನೀತಿಗಳು ಪಾಡ್‌ಗಳ ಗುಂಪುಗಳಿಗೆ ಪ್ರವೇಶ ಹಕ್ಕುಗಳನ್ನು ಹೊಂದಿಸುತ್ತದೆ.

ನೆಟ್‌ವರ್ಕ್ ನೀತಿಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುವುದು

ಇತರ ಕುಬರ್ನೆಟ್ಸ್ ಸಂಪನ್ಮೂಲಗಳಂತೆ, ನೆಟ್‌ವರ್ಕ್ ನೀತಿಗಳನ್ನು 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

ಲೇಬಲ್‌ಗಳು

ಪಾಡ್‌ಗಳು ಮತ್ತು ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳಂತಹ ಕುಬರ್ನೆಟ್ಸ್ ವಸ್ತುಗಳಿಗೆ ನೀವು ಕಸ್ಟಮ್ ಲೇಬಲ್‌ಗಳನ್ನು ಲಗತ್ತಿಸಬಹುದು. ಲೇಬಲ್‌ಗಳು (ಲೇಬಲ್ಗಳು - ಟ್ಯಾಗ್‌ಗಳು) ಕ್ಲೌಡ್‌ನಲ್ಲಿರುವ ಟ್ಯಾಗ್‌ಗಳಿಗೆ ಸಮನಾಗಿರುತ್ತದೆ. ಕುಬರ್ನೆಟ್ಸ್ ನೆಟ್‌ವರ್ಕ್ ನೀತಿಗಳು ಆಯ್ಕೆ ಮಾಡಲು ಲೇಬಲ್‌ಗಳನ್ನು ಬಳಸುತ್ತವೆ ಬೀಜಕೋಶಗಳುಅವರು ಅನ್ವಯಿಸಲು:

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 ಗೆ ವಿಶೇಷ ಗಮನ ಕೊಡಿ - 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

ಕೆಳಗಿನ ನೀತಿಯು ಕ್ಲಸ್ಟರ್‌ನ ಹೊರಗಿನ ಯಾವುದೇ 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 ಜೊತೆಗೆ ಸಂಯೋಜಿಸಲಾಗಿದೆ

ಆದರೆ ಅವುಗಳನ್ನು ಸಂಯೋಜಿಸುವಾಗ, ಅದರ ಮೇಲೆ ಒಂದು ಮಿತಿ ಇದೆ ಗಮನಸೆಳೆದಿದ್ದಾರೆ ಕ್ರಿಸ್ ಕೂನಿ: ಕುಬರ್ನೆಟ್‌ಗಳು ವಿಭಿನ್ನ ನೀತಿಗಳೊಂದಿಗೆ ಮಾತ್ರ ನೀತಿಗಳನ್ನು ಸಂಯೋಜಿಸಬಹುದು 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?

ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳು ಮತ್ತು ಪಾಡ್‌ಗಳ ಮೂಲಕ ಫಿಲ್ಟರ್ ಮಾಡಿ

ಕುಬರ್ನೆಟ್ಸ್ ಆವೃತ್ತಿ 1.11 ಮತ್ತು ಹೆಚ್ಚಿನದು ಆಪರೇಟರ್‌ಗಳನ್ನು ಸಂಯೋಜಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ namespaceSelector и podSelector ತಾರ್ಕಿಕ ಮತ್ತು ಬಳಸಿ. ಇದು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

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 ತಾರ್ಕಿಕ ಅಥವಾ ಬಳಸಿ.

ನಿರ್ದಿಷ್ಟ ಲೇಬಲ್‌ನೊಂದಿಗೆ ಪಾಡ್‌ಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ಎಲ್ಲಾ ನಾಮಸ್ಥಳಗಳಲ್ಲಿ, ಖಾಲಿ ನಮೂದಿಸಿ 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 ವಿಳಾಸಗಳು ಮತ್ತು ಸಬ್‌ನೆಟ್‌ಗಳನ್ನು ಬಳಸುತ್ತವೆ.

ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ, 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 ಗೆ ಪ್ರವೇಶವನ್ನು ನಿಷೇಧಿಸಲಾಗಿದೆ. ಆದ್ದರಿಂದ, ಮೂಲಭೂತವಾಗಿ, ನೀವು ಆಂತರಿಕ ಕುಬರ್ನೆಟ್ಸ್ 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 ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಬೇಕು.

ಅಂತಹ ಕಾರ್ಯವಿಧಾನವನ್ನು ಉಪೋತ್ಕೃಷ್ಟವೆಂದು ಪರಿಗಣಿಸಬೇಕು: ಸೇವೆಯ ಆಂತರಿಕ ರಚನೆಯು (ಪಾಡ್‌ಗಳು ಕೇಳುವ ಪೋರ್ಟ್‌ಗಳು) ಬದಲಾದರೆ, ನೆಟ್‌ವರ್ಕ್ ನೀತಿಗಳನ್ನು ನವೀಕರಿಸಬೇಕಾಗುತ್ತದೆ.

ಸೇವಾ ಮೆಶ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಹೊಸ ವಾಸ್ತುಶಿಲ್ಪದ ವಿಧಾನ (ಉದಾಹರಣೆಗೆ, ಕೆಳಗೆ ಇಸ್ಟಿಯೊ ಬಗ್ಗೆ ನೋಡಿ - ಅಂದಾಜು. ಅನುವಾದ.) ಈ ಸಮಸ್ಯೆಯನ್ನು ನಿಭಾಯಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.

ಪ್ರವೇಶ ಮತ್ತು ಎಗ್ರೆಸ್ ಎರಡನ್ನೂ ನೋಂದಾಯಿಸುವುದು ಅಗತ್ಯವೇ?

ಸಣ್ಣ ಉತ್ತರವು ಹೌದು, ಪಾಡ್ ಬಿ ಯೊಂದಿಗೆ ಪಾಡ್ ಎ ಸಂವಹನ ನಡೆಸಲು, ಹೊರಹೋಗುವ ಸಂಪರ್ಕವನ್ನು ರಚಿಸಲು ಅದನ್ನು ಅನುಮತಿಸಬೇಕು (ಇದಕ್ಕಾಗಿ ನೀವು ಎಗ್ರೆಸ್ ನೀತಿಯನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ), ಮತ್ತು ಪಾಡ್ ಬಿ ಒಳಬರುವ ಸಂಪರ್ಕವನ್ನು ಸ್ವೀಕರಿಸಲು ಶಕ್ತವಾಗಿರಬೇಕು ( ಇದಕ್ಕಾಗಿ, ಅದರ ಪ್ರಕಾರ, ನಿಮಗೆ ಪ್ರವೇಶ ನೀತಿಯ ಅಗತ್ಯವಿದೆ).

ಆದಾಗ್ಯೂ, ಪ್ರಾಯೋಗಿಕವಾಗಿ, ನೀವು ಒಂದು ಅಥವಾ ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಸಂಪರ್ಕಗಳನ್ನು ಅನುಮತಿಸಲು ಡೀಫಾಲ್ಟ್ ನೀತಿಯನ್ನು ಅವಲಂಬಿಸಬಹುದು.

ಕೆಲವು ಪಾಡ್ ಇದ್ದರೆ-ಮೂಲ ಒಬ್ಬರು ಅಥವಾ ಹೆಚ್ಚಿನವರು ಆಯ್ಕೆ ಮಾಡುತ್ತಾರೆ ಹೊರಹೋಗು-ರಾಜಕಾರಣಿಗಳು, ಅದರ ಮೇಲೆ ವಿಧಿಸಲಾದ ನಿರ್ಬಂಧಗಳನ್ನು ಅವರ ವಿರಾಮದಿಂದ ನಿರ್ಧರಿಸಲಾಗುತ್ತದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನೀವು ಪಾಡ್‌ಗೆ ಸಂಪರ್ಕವನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಅನುಮತಿಸಬೇಕಾಗುತ್ತದೆ -ವಿಳಾಸದಾರರಿಗೆ. ಯಾವುದೇ ನೀತಿಯಿಂದ ಪಾಡ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡದಿದ್ದರೆ, ಅದರ ಹೊರಹೋಗುವ (ಹೊರಹೋಗುವ) ಸಂಚಾರವನ್ನು ಡಿಫಾಲ್ಟ್ ಆಗಿ ಅನುಮತಿಸಲಾಗುತ್ತದೆ.

ಅಂತೆಯೇ, ಪಾಡ್ನ ಅದೃಷ್ಟವಿಳಾಸದಾರ, ಒಬ್ಬರು ಅಥವಾ ಹೆಚ್ಚಿನವರು ಆಯ್ಕೆ ಮಾಡಿದ್ದಾರೆ ಪ್ರವೇಶ-ರಾಜಕಾರಣಿಗಳು, ಅವರ ವಿಘಟನೆಯಿಂದ ನಿರ್ಧರಿಸಲಾಗುತ್ತದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಮೂಲ ಪಾಡ್‌ನಿಂದ ದಟ್ಟಣೆಯನ್ನು ಸ್ವೀಕರಿಸಲು ನೀವು ಅದನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಅನುಮತಿಸಬೇಕು. ಯಾವುದೇ ನೀತಿಯಿಂದ ಪಾಡ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡದಿದ್ದರೆ, ಅದರ ಎಲ್ಲಾ ಪ್ರವೇಶ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಡಿಫಾಲ್ಟ್ ಆಗಿ ಅನುಮತಿಸಲಾಗುತ್ತದೆ.

ಕೆಳಗೆ ಸ್ಟೇಟ್‌ಫುಲ್ ಅಥವಾ ಸ್ಟೇಟ್‌ಲೆಸ್ ಅನ್ನು ನೋಡಿ.

ದಾಖಲೆಗಳು

ಕುಬರ್ನೆಟ್ಸ್ ನೆಟ್‌ವರ್ಕ್ ನೀತಿಗಳು ಟ್ರಾಫಿಕ್ ಅನ್ನು ಲಾಗ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ನೀತಿಯು ಉದ್ದೇಶಿತವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸಲು ಇದು ಕಷ್ಟಕರವಾಗಿಸುತ್ತದೆ ಮತ್ತು ಭದ್ರತಾ ವಿಶ್ಲೇಷಣೆಯನ್ನು ಹೆಚ್ಚು ಸಂಕೀರ್ಣಗೊಳಿಸುತ್ತದೆ.

ಬಾಹ್ಯ ಸೇವೆಗಳಿಗೆ ಸಂಚಾರ ನಿಯಂತ್ರಣ

ಕುಬರ್ನೆಟ್ಸ್ ನೆಟ್‌ವರ್ಕ್ ನೀತಿಗಳು ಎಗ್ರೆಸ್ ವಿಭಾಗಗಳಲ್ಲಿ ಸಂಪೂರ್ಣ ಅರ್ಹವಾದ ಡೊಮೇನ್ ಹೆಸರನ್ನು (DNS) ನಿರ್ದಿಷ್ಟಪಡಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುವುದಿಲ್ಲ. ಸ್ಥಿರ IP ವಿಳಾಸವನ್ನು ಹೊಂದಿರದ (aws.com ನಂತಹ) ಬಾಹ್ಯ ಸ್ಥಳಗಳಿಗೆ ಸಂಚಾರವನ್ನು ಮಿತಿಗೊಳಿಸಲು ಪ್ರಯತ್ನಿಸುವಾಗ ಈ ಅಂಶವು ಗಮನಾರ್ಹ ಅನಾನುಕೂಲತೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ.

ನೀತಿ ಪರಿಶೀಲನೆ

ಫೈರ್‌ವಾಲ್‌ಗಳು ನಿಮಗೆ ಎಚ್ಚರಿಕೆ ನೀಡುತ್ತವೆ ಅಥವಾ ತಪ್ಪು ನೀತಿಯನ್ನು ಸ್ವೀಕರಿಸಲು ನಿರಾಕರಿಸುತ್ತವೆ. ಕುಬರ್ನೆಟ್ಸ್ ಸಹ ಕೆಲವು ಪರಿಶೀಲನೆಯನ್ನು ಮಾಡುತ್ತಾರೆ. kubectl ಮೂಲಕ ನೆಟ್‌ವರ್ಕ್ ನೀತಿಯನ್ನು ಹೊಂದಿಸುವಾಗ, ಕುಬರ್ನೆಟ್ಸ್ ಅದು ತಪ್ಪಾಗಿದೆ ಎಂದು ಘೋಷಿಸಬಹುದು ಮತ್ತು ಅದನ್ನು ಸ್ವೀಕರಿಸಲು ನಿರಾಕರಿಸಬಹುದು. ಇತರ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಕುಬರ್ನೆಟ್ಸ್ ಪಾಲಿಸಿಯನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತಾರೆ ಮತ್ತು ಕಾಣೆಯಾದ ವಿವರಗಳೊಂದಿಗೆ ಅದನ್ನು ಭರ್ತಿ ಮಾಡುತ್ತಾರೆ. ಆಜ್ಞೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಅವುಗಳನ್ನು ಕಾಣಬಹುದು:

kubernetes get networkpolicy <policy-name> -o yaml

ಕುಬರ್ನೆಟ್ಸ್ ಮೌಲ್ಯೀಕರಣ ವ್ಯವಸ್ಥೆಯು ತಪ್ಪಾಗುವುದಿಲ್ಲ ಮತ್ತು ಕೆಲವು ರೀತಿಯ ದೋಷಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳಬಹುದು ಎಂಬುದನ್ನು ನೆನಪಿನಲ್ಲಿಡಿ.

ಮರಣದಂಡನೆ

ಕುಬರ್ನೆಟ್ಸ್ ಸ್ವತಃ ನೆಟ್‌ವರ್ಕ್ ನೀತಿಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದಿಲ್ಲ, ಆದರೆ ಇದು ಕೇವಲ API ಗೇಟ್‌ವೇ ಆಗಿದ್ದು ಅದು ಕಂಟೈನರ್ ನೆಟ್‌ವರ್ಕಿಂಗ್ ಇಂಟರ್ಫೇಸ್ (CNI) ಎಂಬ ಆಧಾರವಾಗಿರುವ ಸಿಸ್ಟಮ್‌ಗೆ ನಿಯಂತ್ರಣದ ಹೊರೆಯನ್ನು ನಿಯೋಜಿಸುತ್ತದೆ. ಸೂಕ್ತವಾದ CNI ಅನ್ನು ನಿಯೋಜಿಸದೆಯೇ Kubernetes ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ನೀತಿಗಳನ್ನು ಹೊಂದಿಸುವುದು ಫೈರ್‌ವಾಲ್‌ಗಳಲ್ಲಿ ಅವುಗಳನ್ನು ಸ್ಥಾಪಿಸದೆಯೇ ಫೈರ್‌ವಾಲ್ ನಿರ್ವಹಣಾ ಸರ್ವರ್‌ನಲ್ಲಿ ನೀತಿಗಳನ್ನು ರಚಿಸುವಂತೆಯೇ ಇರುತ್ತದೆ. ನೀವು ಯೋಗ್ಯವಾದ CNI ಅನ್ನು ಹೊಂದಿರುವಿರಿ ಅಥವಾ ಕುಬರ್ನೆಟ್ಸ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳ ಸಂದರ್ಭದಲ್ಲಿ, ಕ್ಲೌಡ್‌ನಲ್ಲಿ ಹೋಸ್ಟ್ ಮಾಡಿರುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು ನಿಮಗೆ ಬಿಟ್ಟದ್ದು (ನೀವು ಪೂರೈಕೆದಾರರ ಪಟ್ಟಿಯನ್ನು ನೋಡಬಹುದು ಇಲ್ಲಿ - ಅಂದಾಜು ಟ್ರಾನ್ಸ್.), ನಿಮಗಾಗಿ CNI ಅನ್ನು ಹೊಂದಿಸುವ ನೆಟ್‌ವರ್ಕ್ ನೀತಿಗಳನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿ.

ಸೂಕ್ತವಾದ ಸಹಾಯಕ CNI ಇಲ್ಲದೆ ನೀವು ನೆಟ್‌ವರ್ಕ್ ನೀತಿಯನ್ನು ಹೊಂದಿಸಿದರೆ ಕುಬರ್ನೆಟ್ಸ್ ನಿಮಗೆ ಎಚ್ಚರಿಕೆ ನೀಡುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ಗಮನಿಸಿ.

ಸ್ಟೇಟ್ಫುಲ್ ಅಥವಾ ಸ್ಟೇಟ್ಲೆಸ್?

ನಾನು ಎದುರಿಸಿದ ಎಲ್ಲಾ Kubernetes CNI ಗಳು ಸ್ಥಿತಿವಂತವಾಗಿವೆ (ಉದಾಹರಣೆಗೆ, ಕ್ಯಾಲಿಕೊ Linux conntrack ಅನ್ನು ಬಳಸುತ್ತದೆ). ಇದು ಪಾಡ್ ಅನ್ನು ಮರು-ಸ್ಥಾಪಿಸದೆಯೇ ಅದು ಪ್ರಾರಂಭಿಸಿದ TCP ಸಂಪರ್ಕದಲ್ಲಿ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ಅನುಮತಿಸುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಸ್ಥಿತಿವಂತಿಕೆಯನ್ನು ಖಾತರಿಪಡಿಸುವ ಕುಬರ್ನೆಟ್ಸ್ ಮಾನದಂಡದ ಬಗ್ಗೆ ನನಗೆ ತಿಳಿದಿಲ್ಲ.

ಸುಧಾರಿತ ಭದ್ರತಾ ನೀತಿ ನಿರ್ವಹಣೆ

ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಭದ್ರತಾ ನೀತಿ ಜಾರಿಯನ್ನು ಸುಧಾರಿಸಲು ಕೆಲವು ಮಾರ್ಗಗಳು ಇಲ್ಲಿವೆ:

1. ಸೇವೆಯ ಮಟ್ಟದಲ್ಲಿ ವಿವರವಾದ ಟೆಲಿಮೆಟ್ರಿ ಮತ್ತು ಟ್ರಾಫಿಕ್ ನಿಯಂತ್ರಣವನ್ನು ಒದಗಿಸಲು ಸರ್ವಿಸ್ ಮೆಶ್ ಆರ್ಕಿಟೆಕ್ಚರಲ್ ಮಾದರಿಯು ಸೈಡ್‌ಕಾರ್ ಕಂಟೈನರ್‌ಗಳನ್ನು ಬಳಸುತ್ತದೆ. ಉದಾಹರಣೆಯಾಗಿ ನಾವು ತೆಗೆದುಕೊಳ್ಳಬಹುದು ಇಸ್ಟಿಯೊ.
2. ಕೆಲವು CNI ಮಾರಾಟಗಾರರು ಕುಬರ್ನೆಟ್ಸ್ ನೆಟ್‌ವರ್ಕ್ ನೀತಿಗಳನ್ನು ಮೀರಿ ತಮ್ಮ ಪರಿಕರಗಳನ್ನು ವಿಸ್ತರಿಸಿದ್ದಾರೆ.
3. ತುಫಿನ್ ಓರ್ಕಾ ಕುಬರ್ನೆಟ್ಸ್ ನೆಟ್‌ವರ್ಕ್ ನೀತಿಗಳ ಗೋಚರತೆ ಮತ್ತು ಸ್ವಯಂಚಾಲಿತತೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ.

Tufin Orca ಪ್ಯಾಕೇಜ್ ಕುಬರ್ನೆಟ್ಸ್ ನೆಟ್‌ವರ್ಕ್ ನೀತಿಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ (ಮತ್ತು ಮೇಲಿನ ಸ್ಕ್ರೀನ್‌ಶಾಟ್‌ಗಳ ಮೂಲವಾಗಿದೆ).

ಹೆಚ್ಚುವರಿ ಮಾಹಿತಿ

• GKE ನಿಂದ ಅಹ್ಮತ್ ಆಲ್ಪ್ ಬಾಲ್ಕನ್ ಸಿದ್ಧಪಡಿಸಿದ ನೆಟ್‌ವರ್ಕ್ ನೀತಿಗಳ ಉದಾಹರಣೆಗಳು;
• ಅಧಿಕೃತ ಕುಬರ್ನೆಟ್ಸ್ ವೆಬ್‌ಸೈಟ್‌ನಿಂದ ದಾಖಲೆ;
• ಕುಬರ್ನೆಟ್ಸ್ ನೆಟ್‌ವರ್ಕಿಂಗ್ ಮಾಡೆಲ್‌ಗೆ ಮಾರ್ಗದರ್ಶಿ;
• ನೆಟ್‌ವರ್ಕ್ ನೀತಿಗಳನ್ನು ಪರಿಶೀಲಿಸಲು ಸ್ಕ್ರಿಪ್ಟ್.

ತೀರ್ಮಾನಕ್ಕೆ

ಕುಬರ್ನೆಟ್ಸ್ ನೆಟ್‌ವರ್ಕ್ ನೀತಿಗಳು ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ವಿಭಜಿಸಲು ಉತ್ತಮ ಸಾಧನಗಳನ್ನು ನೀಡುತ್ತವೆ, ಆದರೆ ಅವುಗಳು ಅರ್ಥಗರ್ಭಿತವಾಗಿಲ್ಲ ಮತ್ತು ಅನೇಕ ಸೂಕ್ಷ್ಮತೆಗಳನ್ನು ಹೊಂದಿವೆ. ಈ ಸಂಕೀರ್ಣತೆಯ ಕಾರಣದಿಂದಾಗಿ, ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಅನೇಕ ಕ್ಲಸ್ಟರ್ ನೀತಿಗಳು ದೋಷಯುಕ್ತವಾಗಿವೆ ಎಂದು ನಾನು ನಂಬುತ್ತೇನೆ. ಈ ಸಮಸ್ಯೆಗೆ ಸಂಭವನೀಯ ಪರಿಹಾರಗಳಲ್ಲಿ ಸ್ವಯಂಚಾಲಿತ ನೀತಿ ವ್ಯಾಖ್ಯಾನಗಳು ಅಥವಾ ಇತರ ವಿಭಜನಾ ಸಾಧನಗಳನ್ನು ಬಳಸುವುದು ಸೇರಿವೆ.

ಈ ಮಾರ್ಗದರ್ಶಿ ಕೆಲವು ಪ್ರಶ್ನೆಗಳನ್ನು ತೆರವುಗೊಳಿಸಲು ಮತ್ತು ನೀವು ಎದುರಿಸಬಹುದಾದ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.

ಅನುವಾದಕರಿಂದ PS

ನಮ್ಮ ಬ್ಲಾಗ್‌ನಲ್ಲಿಯೂ ಓದಿ:

• "ಇಸ್ಟಿಯೊ ಜೊತೆಗೆ ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗೆ ಹಿಂತಿರುಗಿ": ಭಾಗ 1 (ಮುಖ್ಯ ವೈಶಿಷ್ಟ್ಯಗಳ ಪರಿಚಯ), ಭಾಗ 2 (ರೂಟಿಂಗ್, ಸಂಚಾರ ನಿಯಂತ್ರಣ), ಭಾಗ 3 (ಭದ್ರತೆ);
• "ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ನೆಟ್ವರ್ಕಿಂಗ್ಗೆ ಒಂದು ಸಚಿತ್ರ ಮಾರ್ಗದರ್ಶಿ": ಭಾಗಗಳು 1 ಮತ್ತು 2 (ನೆಟ್‌ವರ್ಕ್ ಮಾದರಿ, ಓವರ್‌ಲೇ ನೆಟ್‌ವರ್ಕ್‌ಗಳು), ಭಾಗ 3 (ಸೇವೆಗಳು ಮತ್ತು ಸಂಚಾರ ಪ್ರಕ್ರಿಯೆ);
• «ಭದ್ರತಾ-ಸೂಕ್ಷ್ಮ ಪರಿಸರದಲ್ಲಿ ಡಾಕರ್ ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್";
• «ಕುಬರ್ನೆಟ್ಸ್ ಭದ್ರತೆಗಾಗಿ 9 ಅತ್ಯುತ್ತಮ ಅಭ್ಯಾಸಗಳು";
• «ಕುಬರ್ನೆಟ್ಸ್ ಹ್ಯಾಕ್‌ನ ಬಲಿಪಶುವಾಗಲು (ಅಲ್ಲ) 11 ಮಾರ್ಗಗಳು».

ಮೂಲ: www.habr.com