Đi làm ở các tổ chức quân đội, nhà nước hoặc doanh nghiệp có quy định nghiêm ngặt về môi trường truy cập internet thì nhiều khi cài đặt các công cụ cũng là một task khá hay ho.
Có thể khi nghe tới Elastic trong môi trường offline thường nghĩ chỉ cần cài Elasticsearch và Kibana trong mạng nội bộ là đủ. Mình thấy thì điểm khó không nằm ở bộ cài, mà nằm ở chỗ hệ thống có còn vận hành đầy đủ khi không thể gọi ra Internet để lấy package, artifact, bản đồ, chứng chỉ hay nội dung do Fleet quản lý. Muốn triển khai ổn định, Elastic cần được nhìn như một kiến trúc hoàn chỉnh, không phải một cụm dịch vụ đứng riêng lẻ.
Bản chất tài liệu chính thức của Elastic có những hướng dẫn rất hay nên mình làm bài này chia sẻ tới anh em nào chưa biết có thể xem thử nhé.
Hiểu đúng bài toán offline
Trong môi trường offline hoặc air-gapped, vấn đề không chỉ là chặn truy cập Internet. Hệ thống còn phải tự cung cấp lại những thành phần mà ở môi trường thông thường Elastic lấy từ bên ngoài, gồm Elastic Package Registry, Elastic Artifact Registry, dịch vụ bản đồ và kho artifact cho endpoint protection. Nếu bỏ sót các mảnh ghép này, quá trình triển khai vẫn có thể hoàn tất, nhưng khi vận hành sẽ dễ gặp xuất hiện lỗi ở integration, agent upgrade, endpoint artifact hoặc geospatial data.
Mình thấy đây là điểm quan trọng nhất thấy trong tài liệu của Elastic về phần này. Giá trị không nằm ở chỗ stack có thể chạy mà không có Internet, mà nằm ở khả năng nội địa hóa toàn bộ dependency cần thiết để hệ thống vẫn giữ được đầy đủ chức năng trong mạng nội bộ.
Chọn mô hình triển khai phù hợp
Với môi trường không có mạng, hướng đi thường bắt đầu từ các mô hình non-SaaS. Nếu cần quyền kiểm soát tối đa trên VM hoặc bare metal, có thể đi theo hướng self-managed cluster. Nếu hạ tầng đã chuẩn hóa trên Kubernetes, có thể cân nhắc Elastic Cloud on Kubernetes. Nếu cần quản trị nhiều deployment ở quy mô lớn hơn, có thể xem thêm Elastic Cloud Enterprise.
Điểm mình thấy cần lưu ý là không nên chọn mô hình theo cảm giác hiện đại hơn hay đơn giản hơn trên lý thuyết. Cách chọn hợp lý nhất vẫn là mô hình nào đội vận hành có thể duy trì ổn định lâu dài trong điều kiện mạng nội bộ.
Những thành phần cần đưa vào nội bộ
Trước khi cài Elastic, anh em nên lập danh sách rõ các dependency phải host trong mạng nội bộ, mọi người tham khảo thử nhé:
- Elastic Package Registry phục vụ integration package và nội dung do Fleet quản lý
- Elastic Artifact Registry phục vụ binary download và self-upgrade của Elastic Agent
- Kho artifact cho endpoint offline phục vụ Elastic Defend trong môi trường tách biệt
- Dịch vụ bản đồ nội bộ nếu hệ thống sử dụng geospatial dashboard hoặc map layer
- Mô hình machine learning hoặc LLM nội bộ nếu triển khai các luồng AI trong mạng nội bộ
Nhìn theo hướng này sẽ thấy Elastic offline không phải bài toán cài một stack, mà là bài toán tái tạo đúng hệ sinh thái phụ trợ ngay trong mạng nội bộ. Đây là khác biệt rất lớn giữa cài được và vận hành được.
Tổ chức Layer truy cập nội bộ
Phần lớn supporting service của Elastic có thể chạy dưới dạng container và đặt sau reverse proxy như NGINX hoặc Apache. Cách tổ chức này giúp đơn giản hóa DNS, gom các điểm truy cập về một lớp chung, đồng thời thuận lợi hơn cho việc kiểm soát truy cập và triển khai TLS.
Trong môi trường offline, mình thấy layer này rất quan trọng vì nó giúp routing nhất quán hơn khi số lượng service nội bộ tăng lên. Nếu mỗi thành phần đi theo một hướng truy cập khác nhau, hệ thống sẽ nhanh chóng trở nên khó quản lý và khó xử lý sự cố.
Một mô hình triển khai hợp lý thường sẽ tách rõ ba lớp:
- Lớp truy cập chung qua reverse proxy
- Lớp dịch vụ Elastic chính như Elasticsearch, Kibana, Fleet Server
- Lớp supporting service nội bộ như registry, artifact mirror và endpoint artifact server
Cách tách này giúp hệ thống dễ kiểm soát hơn khi cần mở rộng hoặc troubleshoot.
Thiết lập TLS ngay từ đầu
Trong môi trường không có mạng, TLS không nên được xử lý sau. Elastic có tài liệu khá rõ cho việc thiết lập HTTPS cho Elasticsearch và Kibana, đồng thời hỗ trợ tạo chứng chỉ bằng elasticsearch-certutil.
Với các cụm self-managed, theo mình đây là bước nên được chuẩn hóa trước khi rollout agent hoặc integration. Nếu tổ chức đã có CA nội bộ, có thể dùng CA này để cấp chứng chỉ cho các thành phần của Elastic. Nếu chưa có, có thể tạo certificate bằng công cụ của Elastic rồi phân phối trust theo đúng topology triển khai.
Điểm quan trọng ở đây là chuỗi trust phải nhất quán giữa Elasticsearch, Kibana, Fleet Server, reverse proxy và các endpoint. Nếu phần này làm chắp vá, hệ thống vẫn có thể chạy nhưng sẽ rất dễ phát sinh lỗi kết nối về sau.
Cấu hình trust cho Fleet và Elastic Agent
Trong môi trường offline, khó khăn thường không nằm ở Elasticsearch mà nằm ở việc agent có tin cậy đúng certificate hay không. Phần này nên bám vào Fleet output settings, cấu hình trusted fingerprint và tài liệu secure connections cho self-managed Fleet Server.
Có hai cách cấu hình phổ biến mà mình thấy thực tế nhất mà tài liệu chính thức cũng nói
Dùng CA trusted fingerprint
Nếu đang dùng certificate self-signed hoặc CA nội bộ, có thể đưa SHA-256 fingerprint của CA vào phần output settings trong Fleet. Cách này phù hợp khi cần triển khai nhanh và muốn agent xác thực certificate chain mà không phải cài CA thủ công lên toàn bộ endpoint.
Elastic mô tả khá rõ phần này trong tài liệu certificate fingerprints.
Dùng Advanced YAML
Khi cần kiểm soát sâu hơn, phần Elasticsearch output settings cho phép khai báo certificate authority và các tham số TLS bằng Advanced YAML. Cách này phù hợp với hệ thống có yêu cầu chặt hơn về policy hoặc có nhiều tầng trust khác nhau.
Nếu hệ thống có nhiều loại endpoint hoặc nhiều vùng mạng tách biệt, theo mình nên ưu tiên cách cấu hình rõ ràng bằng policy thay vì xử lý thủ công trên từng máy.
Chuẩn bị cho Agent upgrade và artifact
Elastic Agent trong môi trường không có mạng sẽ không thể tải binary upgrade từ nguồn công cộng nếu không có mirror nội bộ. Đây là lý do Elastic Artifact Registry cần được dựng ngay từ đầu.
Tài liệu của Elastic cũng nêu rõ rằng trong môi trường air-gapped, Kibana phải truy cập được tới Elastic Package Registry để tải package metadata và content, còn agent phải có đường tới artifact registry để lấy binary khi nâng cấp.
Nếu hệ thống dùng Elastic Defend, cần triển khai thêm artifact server cho endpoint offline. Tài liệu này mô tả rõ cách dựng HTTP file server hoặc mirror server, cách trỏ endpoint về nguồn artifact nội bộ và cách cập nhật artifact thủ công theo chu kỳ.
Phần này theo mình rất dễ bị xem nhẹ trong giai đoạn đầu. Nhưng khi rollout agent ra diện rộng, đây lại là chỗ quyết định hệ thống có vận hành bền hay không.
Trình tự triển khai nên đi như thế nào
Một lộ trình thực tế thường sẽ gồm các bước sau.
1. Xác định phạm vi cách ly
Trước tiên cần làm rõ đây là môi trường offline hoàn toàn, restricted network hay chỉ chặn outbound Internet. Mức độ cách ly sẽ quyết định mô hình đồng bộ artifact, mirror và quy trình cập nhật.
2. Chọn mô hình cài đặt
Chọn self-managed nếu cần bám sát VM hoặc bare metal. Chọn Elastic Cloud on Kubernetes nếu đội vận hành đã quen với Kubernetes. Điều quan trọng là giữ cho cách triển khai phù hợp với khả năng vận hành lâu dài.
3. Dựng supporting service nội bộ
Dựng trước Elastic Package Registry, Elastic Artifact Registry và các kho artifact cần thiết cho endpoint. Khi các thành phần này sẵn sàng, quá trình rollout sẽ ổn định hơn nhiều.
4. Hoàn thiện HTTPS và trust chain
Thiết lập HTTPS cho Elasticsearch và Kibana, tạo chứng chỉ bằng elasticsearch-certutil nếu cần, sau đó cấu hình trust cho Fleet và agent theo đúng topology.
5. Kiểm thử trong điều kiện offline thật
Theo mình, đây là bước không nên làm qua loa. Không nên kiểm thử khi hệ thống vẫn còn đường ra Internet. Chỉ khi package, artifact, policy, certificate và routing đều đi qua nguồn nội bộ mà toàn bộ stack vẫn hoạt động bình thường, lúc đó mới có thể coi là triển khai thành công.
Kết luận
Cài đặt Elastic trong môi trường offline không khó ở bước cài phần mềm. Phần khó nằm ở việc biến toàn bộ dependency bên ngoài thành năng lực nội bộ có thể vận hành ổn định. Khi package registry, artifact registry, endpoint artifact, TLS và Fleet trust được chuẩn hóa ngay từ đầu, Elastic có thể chạy trong mạng nội bộ với mức độ hoàn chỉnh rất gần môi trường có kết nối.
Viết thấy cũng dài dài rồi, trên là những điều mình thấy điểm đáng học từ cách Elastic tiếp cận bài toán air-gapped. Không phải cố chứng minh rằng stack có thể chạy mà không có Internet, mà là tổ chức lại toàn bộ kiến trúc để hệ thống vẫn giữ được khả năng vận hành, cập nhật và mở rộng trong điều kiện nhiều env trong thực tế.
