Kubeflow là gì
Trong bài viết ngắn này, tôi sẽ cố gắng nắm bắt những điểm khác biệt chính giữa các công cụ MLops Ploomber và KubeFlow. Chúng tôi sẽ trình bày một số thông tin cơ bản về đường ống Ploomber, Kubeflow là gì và tại sao chúng ta cần những công cụ đó để giúp cuộc sống của chúng ta dễ dàng hơn. Show Chúng ta sẽ thấy sự khác biệt trong 3 lĩnh vực chính:
Vì vậy, chúng ta hãy đi sâu vào! Bối cảnh Thông thường, khi một tổ chức có dữ liệu và đang tìm cách tạo ra thông tin chi tiết hoặc dự đoán từ đó (để thúc đẩy kết quả kinh doanh), họ đưa các Nhà khoa học dữ liệu hoặc MLEs đến để khám phá dữ liệu, chuẩn bị cho việc tiêu thụ và tạo ra một mô hình. Sau đó, 3 nhiệm vụ này có thể được thống nhất thành một đường ống dữ liệu với các nhiệm vụ tương quan, lấy dữ liệu, làm sạch nó và đào tạo một mô hình. Kiến trúc này khá cơ bản cho một đường ống dữ liệu, chúng ta sẽ có một đầu vào và đầu ra cho mỗi tác vụ và đó là những gì xác định các phụ thuộc trong đường ống. Kiến trúc của ML-Basic: Một ví dụ về tất cả các tác vụ mà chúng tôi đang chạy (lấy dữ liệu, thiết kế các tính năng, kết hợp dữ liệu) để phù hợp với mô hình của chúng tôi. (Tôi thấy cách giải thích về cốt truyện dễ dàng hơn thay vì đi sâu vào mã, toàn bộ “Một bức tranh đáng giá một nghìn từ”) Dàn nhạc là gì và tại sao chúng ta cần nó? Kubeflow vs Ploomber Dễ sử dụng Bây giờ quay lại thiết lập nó, tôi cũng phát hiện ra có 2 phiên bản sau khi cài đặt nên tôi tiếp tục sử dụng phiên bản cũ (không có cách nào tôi phải trải qua quá trình cài đặt dài này một lần nữa). Khi cụm được định cấu hình trên tài khoản đám mây mà tôi đã mở cho nó, tôi nhận ra rằng mình phải sử dụng apis phức tạp cho python và có một số hạn chế để chạy trên docker (phải giữ các tác vụ dưới dạng văn bản miễn phí). Trong suốt quá trình này, tôi đã thử một trong những khuôn khổ được cho là sẽ giúp tôi giảm bớt tất cả, đặc biệt là với máy tính xách tay, Kale - nhưng không thành công. Mặt khác, với Ploomber, bắt đầu cục bộ thật dễ dàng, tất cả những gì tôi phải làm là chạy pip install ploomber, sau đó tôi có thể bắt đầu từ một đường ống mẫu và phát triển trên máy tính xách tay của mình. Các tài liệu được cấu trúc theo cách mà mọi trường hợp sử dụng đều có một sách dạy nấu ăn và các khái niệm được giải thích ở một nơi. Nó cho phép triển khai cả cục bộ và trên đám mây nên sau khi hoàn thành các bước lặp, tôi có thể gửi công việc cho cụm Kubeflow của mình. Có api CLI cho các hành động cơ bản và api python cho người dùng nâng cao hơn. Cộng tác và lặp lại nhanh chóng Gỡ lỗi, kiểm tra và khả năng tái tạo Một ví dụ về phiên tương tác bên trong phiên bản Jupyter, xem dag và các tác vụ của nó so với hộp đen chạy từ xa. Khi Kubeflow sẽ có ý nghĩa Kết luận Cảm ơn vì đã đọc tất cả các cách! Nếu bạn đang tìm kiếm một giải pháp tốt hơn để sắp xếp quy trình công việc của mình, hãy đưa ra Ploomber một sự cố gắng. Ido Michael đồng sáng lập Ploomber để giúp các nhà khoa học dữ liệu xây dựng nhanh hơn. Anh ấy đã từng làm việc tại các nhóm khoa học / kỹ thuật dữ liệu hàng đầu của AWS. Anh ấy đã tự tay xây dựng 100 đường ống dẫn dữ liệu trong những lần tương tác với khách hàng đó cùng với nhóm của mình. Xuất thân từ Israel, ông đến NY để lấy bằng Thạc sĩ tại Đại học Columbia. Anh ấy tập trung vào việc xây dựng Ploomber sau khi anh ấy liên tục nhận thấy rằng các dự án dành khoảng 30% thời gian của họ chỉ để cấu trúc lại công việc của nhà phát triển (nguyên mẫu) thành một quy trình sản xuất.
Bảo mật vẫn luôn là mối quan tâm hàng đầu của các tất cả doanh nghiệp hiện nay. Tuy nhiên, đối với các tổ chức sử dụng Kubernetes (nền tảng mã nguồn mở), người ta lại ít bận tâm tới mức độ bảo mật không cao vốn có của nó. Thay vào đó họ phần lớn chỉ chú ý đến mức độ phức tạp của Kubernetes, và thực tế cũng cho thấy ngay cả các chuyên gia lành nghề cũng gặp khó khăn nất định khi sử dụng công cụ. Theo báo cáo gần đây của StackRox, các vấn đề như chưa được đào tạo, thiếu kinh nghiệm hay cấu hình sai là nguyên nhân lớn nhất gây ra sự cố bảo mật Kubernetes. Sau khi khảo sát hơn 540 tham gia vào năm ngoái,kết quả cho thấy có đến hơn 94% trong số đó đã gặp sự cố bảo mật với Kubernetes. Tuy nhiên, không chỉ những người tham gia kẻ trên mà các trường hợp được liệt kê trong danh sách dưới đây cũng đã gặp sự cố tương tự. Vậy họ đã giải quyết lỗi bảo mật Kubernetes như thế nào, và chúng ta có thể học được gì từ đó? Tìm hiểu 5 sự cố bảo mật Kubernetes qua bài viết của Bizfly Cloud dưới đây nhé. Capital OneĐây là sự cố bảo mật Kubernetes khá lớn và dường như là tiếng chuông cảnh tỉnh cả cộng đồng. Sự cố xảy ra đúng một năm trước, một vụ rò rỉ 30GB dữ liệu tín dụng ảnh hưởng đến khoảng 106 triệu người. Lỗ hổng thường thấy trong nền tảng Kubernetes thường bắt nguồn từ một cấu hình lỗi. Cụ thể, một tường lửa có cấu hình sai đã tạo điều kiện cho hacker tấn công truy vấn dữ liệu nội bộ và có được thông tin xác thực về IAM (quản lý truy cập và nhận dạng) của Amazon Web Services. Một trong những bài học quan trọng mà chúng ta học được từ sự cố này là cần cẩn trọng hơn khi phân chia IAM role. Hầu hết mọi người vội vàng kích hoạt Kubernetes và bỏ qua các phần cần lưu tâm như quản lý dữ liệu quan trọng và phân chia IAM theo từng nhóm thay vì từng ứng dụng. Một nhiệm vụ quan trọng khác là thường xuyên cập nhật thông tin đăng nhập, tốt nhất là dùng một dịch vụ giới hạn thời gian đăng nhập. Điều này giúp đặt ra nhiều hạn chế về thời gian hoạt động của các hoạt động vi phạm trên hệ thống. Docker HubVới Kubernetes, trong các container và môi trường phân tán, phạm vi tấn công ngày càng lớn theo cấp số nhân và bạn không thể truy vết cuộc tấn công đó đến từ đâu. Ví dụ, khi hacker tấn công trình quản lý của Docker Hub để tạo ra những docker image gắn mã độc trong Docker Hub vào năm ngoái, khiến bất cứ ai sử dụng docker image đó đều bị mã hóa. Người dùng vô tình triển khai các công cụ khai thác tiền điện tử dưới dạng Docker containers, sau đó nó chuyển hướng tài nguyên sang khai thác cho kẻ tấn công. Đây chỉ là một trong số các cuộc tấn công bị phát hiện gần đây. Tương tự như Capital One, cần thay đổi mật khẩu và thông tin đăng nhập thường xuyên để tránh loại tình huống này. Ngoài ra, đối với Kubernetes, cần thay phiên thông tin bí mật và kiểm tra docker image thường xuyên để đảm bảo chỉ những hình ảnh đã xác minh mới được sử dụng nhằm đảm bảo an ninh. Docker image gắn mã độc khá khó bị phát hiện, đặc biệt nó mất nhiều thời gian hơn. Đây là lý do vì sao các kiểm tra bổ sung sẽ sàng lọc bất kỳ sai lệch nào trong ứng dụng và phát hiện các quy trình ẩn được cài đặt trong hệ thống. Kiểu tấn công này khá hiệu quả. Microsoft AzureMicrosoft cũng nằm trong số những cái tên gặp rắc rối về tiền điện tử. Họ tiết lộ rằng, đã có một cuộc tấn công tiền điện tử quy mô lớn chống lại tổ hợp Kubernetes trong Azure vào tháng 4 năm nay, một chiến dịch tương tự được phát hiện vào tháng 6 nhằm vào các container Kubeflow được cấu hình sai để biến chúng thành tiền điện tử. Tương tự như trường hợp Docker Hub, Kubeflow sử dụng một số dịch vụ cho phép người dùng dùng ditto được tùy chỉnh như với Katib và Jupyter Notebook. Đối với Jupyter, hình ảnh được chọn không phải là hình ảnh hợp pháp và đó là kẽ hở cho các kẻ xấu tấn công. Nếu xem xét nguyên nhân dẫn đến cấu hình sai thì đó là do tính thiếu kiên nhẫn, lười biếng và thiếu kiến thức. Bảng điều khiển UI của Kubeflow theo mặc định chỉ có thể truy cập nội bộ thông qua cổng Istio. Tuy nhiên, một số người dùng muốn rút ngắn công đoạn để truy cập trực tiếp vào bảng điều khiển mà không thông qua máy chủ API Kubernetes và không nhận ra rằng khi họ tiết kiệm được thời gian thì nó cũng đang mở ra một số backtime trong quy trình. Họ đã để lộ cổng xâm nhập Istio vào internet, cho phép mọi người đều truy cập được vào bảng điều khiển. Bài học ở đây là đảm bảo bảo mật cho mọi cài đặt hoặc thay đổi cấu hình đang dùng. TeslaVới trị giá tiền điện tử tăng vọt và tài nguyên khai thác vô hạn trong Cloud, việc chiếm đoạt tài nguyên sẽ sinh lợi cao hơn việc đánh cắp thông tin. Nhà sản xuất ô tô nổi tiếng Tesla là một trong những nạn nhân của tiền điện tử khi cụm Kubernetes bị xâm phạm do bảng điều khiển không được bảo vệ. RedLock Cloud Security Intelligence phát hiện và công khai trong một báo cáo đã nêu rõ việc cấu hình sai đã tạo điều kiện những kẻ tấn công nắm giữ vùng chứa thông tin xác thực AWS S3 của Tesla. Những thông tin đăng nhập sau đó được sử dụng để chạy các tập lệnh được mã hóa trên một nhóm. Điều thú vị trong cuộc tấn công là số lượng thủ thuật được thực hiện để tránh bị phát hiện. Ngoài việc không sử dụng nhóm khai thác đã bị phát hiện thay vào đó là một nhóm không công khai, chúng còn sử dụng dịch vụ CDN của Cloudflare để ẩn IP của chúng. Những kẻ tấn công cũng thiết lập tập lệnh khai thác không sử dụng hết tài nguyên CPU để tránh gây ra báo động hoặc bị phát hiện và nghe trên một cổng không chính thức, khiến việc phát hiện dựa trên lưu lượng truy cập hầu như không thể. Cách duy nhất để phát hiện vi phạm này là chủ động giám sát các cấu hình để đảm bảo tất cả các chính sách bảo mật đang được tuân thủ. JenkinsCùng với sự cố Tesla, tin tặc đã khai thác lỗ hổng trong Jenkins để mã hóa khoảng 3,5 triệu đô la, hay 10.800 Monero trong 18 tháng. Moreno là một loại tiền điện tử có liên quan đến sự cố hình ảnh độc hại Docker Hub được nhắc đến trước đó. Trong trường hợp của Docker Hub, người ta đã phát hiện có 6 hình ảnh gắn mã độc được kéo hơn 2 triệu lần, đó là 2 triệu người dùng bị kẻ tấn công tận dụng để khai thác Monero một cách khá kỳ công. Sự cố bảo mật Kubernetes của Jenkins vẫn là một trong những vi phạm nghiêm trọng nhất được phát hiện cho đến nay. Nó sử dụng các máy Windows và máy tính cá nhân dễ bị tấn công và cũng nhắm vào các máy chủ của Jenkins CI. Nó liên tục tự cập nhật và thay đổi nhóm khai thác để tránh bị phát hiện. Việc nó có thể nhắm vào các máy chủ là một bước tiến mới của những kẻ tấn công đến từ Trung Quốc. Nếu họ có thể thu về hơn 3 triệu đô la từ máy tính bàn thì các máy chủ mạnh mẽ có thể mang lại nguồn lợi có giá trị thêm vài số 0 nữa. Bảo mật Kubernetes gia tăng nhờ không gian tấn công ngày càng đa dạng Sự cố bảo mật Kubernetes đang gia tăng vì môi trường tấn công cũng đang trở nên đa dạng vô cùng tận với các cụm Cloud, trung tâm dữ liệu tại chỗ, thiết bị IoT, máy tính cá nhân… Bảo mật khép kín không còn tồn tại nữa - khi bạn chỉ tập trung vào ứng dụng của mình và để phần công việc còn lại cho tường lửa phòng thủ. Mối đe dọa có thể đến từ một dịch vụ đang được sử dụng ngay trong hệ thống hoặc từ bên cung cấp dịch vụ thứ ba bạn đang sử dụng. Giờ đây, bảo mật là trách nhiệm chung của tất cả mọi người, các nhà cung cấp dịch vụ Cloud hay quản lý Kubernetes chỉ có thể đảm nhiệm tốt phần công việc của họ mà thôi. Cryptojacking (khai thác tiền ảo) chỉ thực sự phát triển khi chúng nắm được lỗ hổng bảo mật đó và sẽ khá khó để phát hiện trừ khi bạn thực hiện các kiểm tra hóa đơn dịch vụ Cloud và phát hiện định mức cao bất thường. Tham khảo Techgenx.com >> Có thể bạn quan tâm: BizFly Cloud chính thức ra mắt Kubernetes Engine đầu tiên tại Việt Nam BizFly Cloud là hệ sinh thái điện toán đám mây được vận hành bởi VCCorp - Công ty dẫn đầu trong lĩnh vực công nghệ và truyền thông tại Việt Nam. Với đội ngũ kỹ thuật viên trình độ cao và kinh nghiệm lâu năm làm việc trên các công nghệ khác nhau như cloud, mobile, web..., chúng tôi có đủ khả năng để hỗ trợ đưa ra những giải pháp và công nghệ toàn diện giúp doanh nghiệp chuyển đổi số thành công. Hãy tăng tốc thích nghi cho doanh nghiệp cùng các giải pháp công nghệ của BizFly Cloud tại đây. |