Elevare Digital ನಲ್ಲಿನ ನಿಮ್ಮ AI ಏಜೆಂಟ್ ಸುಮ್ಮನಾಗಿದ್ದರಿಂದ (idle), ಹೊಸದಾಗಿ ಸೇರಿಸಲಾದ PostgreSQL row-level security (RLS) ಪಾಲಿಸಿಯು ಎಲ್ಲಾ ಜಾಬ್ ರೋ (job row)ಗಳನ್ನು ಫಿಲ್ಟರ್ ಮಾಡಿಹಾಕಿತು, ಇದರಿಂದ ಕ್ಯೂ ಖಾಲಿ ಇರುವಂತೆ ಕಂಡಿತು. ಕೆಲಸಗಳು ರಾಶಿಬಿದ್ದರೂ ಈ ತಪ್ಪಿನ ಅರಿವಾಗಲಿಲ್ಲ, ಇದರಿಂದ ತಂಡವು ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಖಾಲಿ ಕ್ಯೂ ಅನ್ನು ಹೇಗೆ ಪತ್ತೆಹಚ್ಚಬೇಕು ಎಂಬುದನ್ನು ಮರು ವಿನ್ಯಾಸಗೊಳಿಸಬೇಕಾಯಿತು.

ಅರಿವಿಲ್ಲದ ಲೋಪ (The hidden blind spot)

Elevare ನ ಸ್ವಾಯತ್ತ AI ವ್ಯವಸ್ಥೆಯಾದ ARIA, ಬಾಕಿ ಇರುವ ಕೆಲಸಗಳಿಗಾಗಿ (pending jobs) PostgreSQL ಟೇಬಲ್ ಅನ್ನು ಪೋಲ್ (poll) ಮಾಡುತ್ತದೆ. ಕ್ವೇರಿ ಯಶಸ್ವಿಯಾಯಿತು, ಶೂನ್ಯ ರೋಗಳನ್ನು ನೀಡಿತು ಮತ್ತು ಏಜೆಂಟ್ ಸುಮ್ಮನಾಯಿತು. ವಾಸ್ತವದಲ್ಲಿ ಟೇಬಲ್ ತುಂಬಿತ್ತು. ಒಂದು RLS ಪಾಲಿಸಿಯು SELECT ಪ್ರವೇಶವನ್ನು ನಿರ್ದಿಷ್ಟ ಬಳಕೆದಾರರಿಗೆ ಮಾತ್ರ ಸೀಮಿತಗೊಳಿಸಿತ್ತು. ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಬೈಪಾಸ್ ಪ್ರವಿಲೇಜ್ (bypass privilege) ಇಲ್ಲದ ಸರ್ವಿಸ್ ರೋಲ್ ಮೂಲಕ ಸಂಪರ್ಕ ಸಾಧಿಸಿತ್ತು, ಆದ್ದರಿಂದ ಡೇಟಾಬೇಸ್ ಫಲಿತಾಂಶದ ಸೆಟ್‌ನಿಂದ ಪ್ರತಿಯೊಂದು ರೋವನ್ನು ಮೌನವಾಗಿ ತೆಗೆದುಹಾಕಿತು. PostgreSQL ಫಿಲ್ಟರ್ ಮಾಡಲಾದ ರೀಡ್ ಅನ್ನು ಖಾಲಿ ಟೇಬಲ್‌ನಂತೆಯೇ ಪರಿಗಣಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಯಾವುದೇ ಎರರ್ (error), ವಾರ್ನಿಂಗ್ (warning) ಅಥವಾ ಫೇಲ್ಯೂರ್ ಕೋಡ್ ಕಾಣಿಸಲಿಲ್ಲ. ಸುಮ್ಮನಾಗಿದ್ದ ಏಜೆಂಟ್‌ನಿಂದ ಬಂದ ಆರೋಗ್ಯಕರ ಹಾರ್ಟ್‌ಬೀಟ್ (heartbeat), ಏನೂ ತಪ್ಪಾಗಿದೆ ಎಂಬ ಸುಳಿವು ನೀಡಲಿಲ್ಲ.

RLS ಹೇಗೆ ತುಂಬಿದ ಕ್ಯೂ ಅನ್ನು ಮೌನವಾಗಿ ಬದಲಾಯಿಸಿತು

SELECT ಮಾಡುವಾಗ RLS ಪ್ರತಿ ರೋಗೆ ಒಂದು ಪ್ರೆಡಿಕೇಟ್ (predicate) ಅನ್ನು ಸೇರಿಸುತ್ತದೆ. ಪ್ರೆಡಿಕೇಟ್ ಸುಳ್ಳಾಗಿದ್ದರೆ (false), ಆ ರೋ ಫಲಿತಾಂಶದಿಂದ ಮಾಯವಾಗುತ್ತದೆ. ಕ್ಲೈಂಟ್ ಪಾಲಿಸಿಯನ್ನು ಪೂರೈಸುವ ರೋಗಳನ್ನು ಮಾತ್ರ ನೋಡುತ್ತದೆ; ರೋಗಳು ಅಡಗಿವೆಯೆಂದು ಅದಕ್ಕೆ ಎಂದಿಗೂ ತಿಳಿಯುವುದಿಲ್ಲ. ಕ್ಯೂ ವರ್ಕರ್ (queue worker) ಗೆ, ಖಾಲಿ ಫಲಿತಾಂಶದ ಸೆಟ್ ನಿಜವಾಗಿಯೂ ಖಾಲಿ ಇರುವ ಕ್ಯೂನಂತೆಯೇ ಕಾಣುತ್ತದೆ. ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ "ರೋಗಳಿಲ್ಲ = ಕೆಲಸವಿಲ್ಲ" ಎಂದು ಭಾವಿಸಿತು ಮತ್ತು ಕೆಲಸಗಳು ತೆರೆಯ ಮರೆಯಲ್ಲಿ ಸಂಗ್ರಹವಾಗುತ್ತಿರುವಾಗ ಅದು ತನ್ನ ಐಡಲ್ ಲೂಪ್ (idle loop) ಗೆ ಪ್ರವೇಶಿಸಿತು.

ಓದುವಿಕೆಯನ್ನು ವೈಯಕ್ತಿಕ ಬಳಕೆದಾರರಿಗೆ ಸೀಮಿತಗೊಳಿಸಲು ಉದ್ದೇಶಿಸಲಾದ ಪಾಲಿಸಿಯು ಅಕಸ್ಮಾತ್ತಾಗಿ ಸರ್ವಿಸ್ ರೋಲ್ ಅನ್ನುವನ್ನೂ ಒಳಗೊಂಡಿತ್ತು ಎಂದು ತಂಡವು ಕಂಡುಕೊಂಡಿತು. ಆ ರೋಲ್‌ನಲ್ಲಿ ವಿಶೇಷ "bypass RLS" ಗುಣಲಕ್ಷಣ ಇರದ ಕಾರಣ, ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ನೀಡಿದ ಪ್ರತಿಯೊಂದು ಕ್ವೇರಿಗೂ ಪಾಲಿಸಿಯು ಅನ್ವಯಿಸಿತು. ಇದು ಕ್ಲಾಸಿಕ್ security-vs-observability (ಭದ್ರತೆ ಮತ್ತು ವೀಕ್ಷಣಾರ್ಹತೆ) ನಡುವಿನ ಸಮತೋಲನದ ಸಮಸ್ಯೆಯನ್ನು ತೋರಿಸುತ್ತದೆ: RLS ಅನಧಿಕೃತ ಬಳಕೆದಾರರಿಂದ ಡೇಟಾವನ್ನು ರಕ್ಷಿಸುತ್ತದೆ, ಆದರೆ ಇದು ದೃಶ್ಯೀಕರಣದ (visibility) ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುವ ಸಿಸ್ಟಮ್ ಘಟಕಗಳಿಗೆ ಉಪಯುಕ್ತವಾದ ಫೇಲ್ಯೂರ್ ಸಿಗ್ನಲ್ ಅನ್ನು ಸಹ ತೆಗೆದುಹಾಕುತ್ತದೆ.

ಕ್ಯಾನರಿ-ಚೆಕ್ ಪ್ಯಾಟರ್ನ್ (The canary-check pattern)

ಮೌನವಾದ ಖಾಲಿ ಫಲಿತಾಂಶದ ಮೇಲಿನ ಅವಲಂಬನೆಯನ್ನು ತಪ್ಪಿಸಲು, Elevare ಒಂದು "ಕ್ಯಾನರಿ" (canary) ಚೆಕ್ ಅನ್ನು ಸೇರಿಸಿತು. ಹೊಸ ಪ್ರಕ್ರಿಯೆಯೆಂದರೆ:

  1. ಬಾಕಿ ಇರುವ ಕೆಲಸಗಳ (pending-jobs) ಟೇಬಲ್ ಅನ್ನು ಕ್ವೇರಿ ಮಾಡಿ.
  2. ರೋಗಳು ಬಂದಲ್ಲಿ, ಮೊದಲಿನಂತೆಯೇ ಅವುಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿ.
  3. ಫಲಿತಾಂಶ ಖಾಲಿ ಇದ್ದರೆ, ಯಾವಾಗಲೂ ಇರಲೇಬೇಕಾದ ಮೀಸಲಾದ ಕ್ಯಾನರಿ ರೋ (canary row) ವಿರುದ್ಧ ಎರಡನೇ ಕ್ವೇರಿಯನ್ನು ನಡೆಸಿ.
  4. ಕ್ಯಾನರಿ ಕ್ವೇರಿಯು ನಿರೀಕ್ಷಿತ ರೋವನ್ನು ನೀಡಿದರೆ, ಕ್ಯೂ ನಿಜವಾಗಿಯೂ ಖಾಲಿ ಇದೆ; ಐಡಲ್ ಹಾರ್ಟ್‌ಬೀಟ್ ಅನ್ನು ಲಾಗ್ ಮಾಡಿ.
  5. ಕ್ಯಾನರಿ ಕ್ವೇರಿಯು ಕೂಡ ಏನನ್ನೂ ನೀಡದಿದ್ದರೆ, ಏಜೆಂಟ್ ಅಂಧವಾಗಿದೆ (blind); ತಕ್ಷಣವೇ ಅಲರ್ಟ್ (alert) ಕಳುಹಿಸಿ.

ಈಗ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಮೂರು ಸ್ಥಿತಿಗಳನ್ನು ಗುರುತಿಸುತ್ತದೆ:

  • Jobs found – ಸಾಮಾನ್ಯ ಪ್ರಕ್ರಿಯೆ.
  • No jobs, canary OK – ನಿಜವಾದ ಐಡಲ್ ಅವಧಿ.
  • No jobs, canary failed – ಅಡಗಿರುವ RLS ಬ್ಲಾಕ್, ಅಲರ್ಟ್ ಟ್ರಿಗ್ಗರ್ ಮಾಡಿ.

ಕ್ಯಾನರಿ ಟೇಬಲ್ ಎಂಬುದು ಎಂದಿಗೂ ಬದಲಾಗದ ಒಂದೇ ಒಂದು ರೋ ಆಗಿದೆ. ಇದನ್ನು ಹೊಂದಿಸಲು ಸುಮಾರು ಒಂದು ಗಂಟೆ ಬೇಕಾಯಿತು, ಆದರೆ ಇದು ಮೌನ ವೈಫಲ್ಯಗಳ ಇಡೀ ವರ್ಗವನ್ನೇ ನಿರ್ಮೂಲನೆ ಮಾಡುತ್ತದೆ.

ತಂಡಗಳು ಏನು ಮಾಡಬೇಕು

ನೀವು PostgreSQL ಅಥವಾ ಅದರ ಮೇಲೆ ನಿರ್ಮಿಸಲಾದ ಹೋಸ್ಟೆಡ್ ಸೇವೆಯನ್ನು (ಉದಾಹರಣೆಗೆ Supabase) ಬಳಸುತ್ತಿದ್ದರೆ, ಈ ಹಂತಗಳನ್ನು ಅನುಸರಿಸಿ:

  • "bypass RLS" ಫ್ಲಾಗ್ ಹೊಂದಿರುವ service-role credential ಅನ್ನು ಬಳಸಿ. ಇದು ಬಳಕೆದಾರ ಮಟ್ಟದ ಪಾಲಿಸಿಗಳ ಹೊರತಾಗಿಯೂ ಸಿಸ್ಟಮ್ ಘಟಕಗಳು ಎಲ್ಲಾ ರೋಗಳನ್ನು ನೋಡಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.
  • ಸರ್ವಿಸ್ ರೋಲ್‌ಗಳಿಗೆ ಮಿಸ್ಸಿಂಗ್ ಬೈಪಾಸ್ ಅನುಮತಿಗಳಿಗಾಗಿ RLS ಪಾಲಿಸಿಗಳನ್ನು ಆಡಿಟ್ (audit) ಮಾಡಿ. ಬಳಕೆದಾರರಿಗೆ ಸರಿಯಾಗಿ ಕಾಣುವ ಪಾಲಿಸಿಯು ಅಕಸ್ಮಾತ್ತಾಗಿ ಆಂತರಿಕ ಸೇವೆಗಳನ್ನು ಸಿಲುಕಿಸಬಹುದು.
  • ಕ್ಯಾನರಿ ಟೇಬಲ್ ಅನ್ನು ಸೇರಿಸಿ (ಅಥವಾ ಯಾವಾಗಲೂ ಇರುವ ಸಮಾನವಾದ ರೋ) ಮತ್ತು ವರ್ಕರ್‌ನ ಐಡಲ್ ಲಾಜಿಕ್‌ನಲ್ಲಿ ಕ್ಯಾನರಿ ಚೆಕ್ ಅನ್ನು ಸೇರಿಸಿ. ಹೆಚ್ಚುವರಿ ಕ್ವೇರಿಯು ಅಗ್ಗವಾಗಿದೆ ಮತ್ತು ಸ್ಪಷ್ಟವಾದ ಸುರಕ್ಷತಾ ಜಾಲವನ್ನು ಒದಗಿಸುತ್ತದೆ.

ಸಮತೋಲನ (The trade-off)

ಸೂಕ್ಷ್ಮ ಡೇಟಾ ಪ್ರವೇಶವನ್ನು (fine-grained data access) ಜಾರಿಗೊಳಿಸಲು RLS ಇನ್ನೂ ಒಂದು ಶಕ್ತಿಯುತ ಸಾಧನವಾಗಿದೆ. ಇದು ಅಕಸ್ಮಾತ್ತಾಗಿ ಡೇಟಾ ಸೋರಿಕೆಯನ್ನು ತಡೆಯುತ್ತದೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್-ಮಟ್ಟದ ಫಿಲ್ಟರ್‌ಗಳನ್ನು ಕೋಡ್‌ಬೇಸ್‌ನಾದ್ಯಂತ ಹರಡದೆ ಮಲ್ಟಿ-ಟೆನಾಂಟ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ. ಇದರ ಅನಾನುಕೂಲವೆಂದರೆ, "ಮಾಡಲು ಏನೂ ಇಲ್ಲ" ಎಂಬ ಸರಳ "ರೋಗಳಿಲ್ಲ" ಎಂಬ ಸಿಗ್ನಲ್ ಅನ್ನು ನಿರೀಕ್ಷಿಸುವ ಘಟಕಗಳಿಂದ ವೈಫಲ್ಯಗಳನ್ನು ಇದು ಮರೆಮಾಚಬಹುದು. ಕ್ಯಾನರಿ ಪ್ಯಾಟರ್ನ್ RLS ಅನ್ನು ದುರ್ಬಲಗೊಳಿಸುವುದಿಲ್ಲ; ಇದು ವೀಕ್ಷಣಾರ್ಹತೆಯನ್ನು (observability) ಮರುಸ್ಥಾಪಿಸುವ ಲಘು ಪರಿಶೀಲನಾ ಹಂತವನ್ನು ಸೇರಿಸುತ್ತದೆ.

ಸಾರಾಂಶ (Takeaway)

ಅಡಗಿರುವ RLS ಪಾಲಿಸಿಯು ಕಾರ್ಯನಿರತ ಕ್ಯೂ ಅನ್ನು ಮೌನವಾದ ಅಂತ್ಯದ ಹಾದಿಯಾಗಿ ಬದಲಾಯಿಸಬಹುದು, ಇದರಿಂದ ಕೆಲಸಗಳು ರಾಶಿಬಿದ್ದರೂ AI ಏಜೆಂಟ್‌ಗಳು ಸುಮ್ಮನಾಗುತ್ತವೆ. ಸರ್ವಿಸ್ ರೋಲ್‌ಗಳಿಗೆ ಸರಿಯಾದ ಬೈಪಾಸ್ ಪ್ರವಿಲೇಜ್ ನೀಡಿ ಮತ್ತು ಪ್ರತಿ ಖಾಲಿ-ಕ್ಯೂ ರೀಡ್ ಅನ್ನು ಕ್ಯಾನರಿ ಚೆಕ್‌ನೊಂದಿಗೆ ಜೋಡಿಸಿ; ತಂಡಗಳು ತಮ್ಮ ಸ್ವಾಯತ್ತ ವರ್ಕರ್ಸ್‌ಗಳನ್ನು ನಿಖರವಾಗಿಡಬಹುದು ಮತ್ತು ದುಬಾರಿ ಅರಿವಿಲ್ಲದ ಲೋಪಗಳನ್ನು ತಪ್ಪಿಸಬಹುದು.