ಪ್ರಾಕ್ಸಿ ವೈಫಲ್ಯವು ಯಾವ Docker CA ಸ್ಟೋರ್‌ಗೆ ಸೂಚಿಸುತ್ತದೆ?
ಅಧಿಕೃತ ತಪಾಸಣೆ CA ಅನ್ನು ನಂಬುವಾಗ ಇಮೇಜ್ ಪುಲ್, ಬಿಲ್ಡ್ ಡೌನ್‌ಲೋಡ್ ಮತ್ತು ಕಂಟೇನರ್ ಅಪ್ಲಿಕೇಶನ್ ವಿನಂತಿಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಿ.
ಕಂಟೇನರ್ ಒಳಗೆ ಕಂಪನಿ CA ಸೇರಿಸುವುದರಿಂದ ಸಹೋದ್ಯೋಗಿಯ ವಿಫಲ ಇಮೇಜ್ ಪುಲ್ ಸರಿಯಾಗುವುದಿಲ್ಲ. ಯಶಸ್ವಿ ಪುಲ್ ಕೂಡ ಇಮೇಜ್ ಒಳಗಿನ ಅಪ್ಲಿಕೇಶನ್ ತಪಾಸಣೆ ಮಾಡಿದ HTTPS ಸೇವೆಯನ್ನು ನಂಬುತ್ತದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.
| ಕಾರ್ಯಾಚರಣೆ | ತನಿಖೆ ಮಾಡಬೇಕಾದ ನಂಬಿಕೆ |
|---|---|
| ಸಂಸ್ಥೆಯ ತಪಾಸಣೆ ಪ್ರಾಕ್ಸಿ ಮೂಲಕ ಇಮೇಜ್ ಪುಲ್ ಮಾಡುವುದು | ಪುಲ್ ಮಾಡುವ ಹೋಸ್ಟ್ ಅಥವಾ Docker ಪರಿಸರ |
| ಇಮೇಜ್ ಬಿಲ್ಡ್ ಸಮಯದಲ್ಲಿ ಡೌನ್‌ಲೋಡ್ ಮಾಡುವುದು | ಬಿಲ್ಡ್ ಪರಿಸರ ಮತ್ತು ಅದರ ಡೌನ್‌ಲೋಡರ್ |
| ಚಾಲ್ತಿಯಲ್ಲಿರುವ ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದ HTTPS ಸೇವೆ ಕರೆಯುವುದು | ಇಮೇಜ್‌ನ OS ಸ್ಟೋರ್ ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್‌ನ ಸ್ವಂತ ನಂಬಿಕೆ ಸಂರಚನೆ |
ದೋಷವನ್ನು ಎದುರು ಪಕ್ಷವನ್ನು ಪರಿಶೀಲಿಸುವ ಪ್ರಕ್ರಿಯೆಯವರೆಗೆ ಜಾಡಿಸಿ, ನಂತರ ನೀಡುಗರು, ಹೋಸ್ಟ್‌ಹೆಸರು ಮತ್ತು ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಹಂತವನ್ನು ದೃಢೀಕರಿಸಿ. ಅಧಿಕೃತ ತಪಾಸಣೆ ಸೇವೆ ಸಂಸ್ಥೆಯ CA ಯೊಂದಿಗೆ ಗಮ್ಯ ಪ್ರಮಾಣಪತ್ರಕ್ಕೆ ಸಹಿ ಮಾಡಬಹುದು. HTTPS ಪ್ರಾಕ್ಸಿ ಶ್ರೋತೃದಲ್ಲಿ TLS ವೈಫಲ್ಯ ಅದರ ಮೂಲಕ ತಲುಪುವ ಗಮ್ಯ ಪ್ರಮಾಣಪತ್ರದ ವೈಫಲ್ಯವಲ್ಲ. ಪ್ರಾಕ್ಸಿ IP ನಮೂದಿಸುವುದರಿಂದ ಯಾವುದೇ ನಂಬಿಕೆ ಸಾಮಗ್ರಿ ಸಿಗುವುದಿಲ್ಲ.
ಅನುಮೋದಿತ ಸಾರ್ವಜನಿಕ ನೀಡುಗರ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಸಂಬಂಧಿತ ಹೋಸ್ಟ್, ಇಮೇಜ್ ವಿತರಣೆ ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್‌ನ ಬೆಂಬಲಿತ ವಿಧಾನದ ಮೂಲಕ ಸ್ಥಾಪಿಸಿ. Docker ನ CA ಮಾರ್ಗದರ್ಶನ ಹೋಸ್ಟ್ ಮತ್ತು ಕಂಟೇನರ್ ಸ್ಟೋರ್‌ಗಳನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ, ಆದರೆ CentOS ಮಾರ್ಗವು Debian ಅಥವಾ Windows ಗೆ ಸಾಗಿಸಬಹುದಾದ ಸೂಚನೆಯಲ್ಲ. ರಚಿಸಿದ ಬಂಡಲ್‌ಗೆ ಸೇರಿಸಿದ್ದನ್ನು ನವೀಕರಣ ರದ್ದುಗೊಳಿಸಬಹುದು; Java ಅಪ್ಲಿಕೇಶನ್ ಅಥವಾ ಸ್ವಂತ CA ಸಂರಚನೆ ಹೊಂದಿರುವ ಇತರ ಕ್ಲೈಂಟ್ OS ಬಂಡಲ್ ಅನ್ನು ಸಂಪೂರ್ಣ ನಿರ್ಲಕ್ಷಿಸಬಹುದು.
ಶಾಶ್ವತ ಅಪ್ಲಿಕೇಶನ್ ನಂಬಿಕೆಗಾಗಿ ಬದಲಾವಣೆಯನ್ನು ಅನುಮೋದಿತ ಇಮೇಜ್ ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್ ಸಂರಚನೆ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಇರಿಸಿ. ಚಾಲ್ತಿಯಲ್ಲಿರುವ ಒಂದು ಕಂಟೇನರ್‌ನಲ್ಲಿ ಮಾಡಿದ ಸಂವಾದಾತ್ಮಕ ಸಂಪಾದನೆ ಇಮೇಜ್‌ನಿಂದ ರಚಿಸಲಾದ ಮುಂದಿನ ಕಂಟೇನರ್‌ನಲ್ಲಿ ಇರುವುದಿಲ್ಲ.
ಅಗತ್ಯವಿರುವ ಸಾರ್ವಜನಿಕ ನಂಬಿಕೆ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಮಾತ್ರ ಅಧಿಕೃತ ಮಾರ್ಗದ ಮೂಲಕ ವಿತರಿಸಿ. ಎಂದಿಗೂ ಇಮೇಜ್‌ನಲ್ಲಿ CA ಖಾಸಗಿ ಕೀಲಿಯನ್ನು ಇಡಬೇಡಿ ಮತ್ತು ಅಪರಿಚಿತ ಸಾರ್ವಜನಿಕ ಪ್ರಾಕ್ಸಿಯ root-ಸ್ಥಾಪನೆ ವಿನಂತಿಯನ್ನು ಸಾಮಾನ್ಯ ಸೆಟಪ್ ಎಂದು ಪರಿಗಣಿಸಬೇಡಿ. ಉದ್ದೇಶಿತ ಸ್ಟೋರ್ ಸಂರಚಿಸಿದ ನಂತರ ಹೋಸ್ಟ್‌ಹೆಸರು ಮತ್ತು ಸರಪಳಿ ಪರಿಶೀಲನೆಯನ್ನು ಸಕ್ರಿಯವಾಗಿರಿಸಿ.