Ansible - kho git riêng - Chuyển tiếp tác nhân SSH so với sao chép khóa SSH riêng


7

Gần đây tôi đã bắt đầu chơi xung quanh với Ansible và nó có vẻ rất hay. Tôi không có nhiều kinh nghiệm về công cụ DevOps và không bao giờ thực sự phải xử lý bất kỳ tình huống phức tạp nào. Tôi bắt đầu tạo Playbook Ansible để thay thế công cụ triển khai hiện tại của mình - Deployer PHP. Tôi đang bị mắc kẹt tại kho lưu trữ git không may. Bây giờ, tôi biết tôi cần một khóa công khai được thêm vào để cho phép truy cập vào kho git và đây là câu hỏi của tôi.

Tôi có nên sử dụng chuyển tiếp tác nhân SSH (theo cách này tôi có thể sử dụng khóa SSH cục bộ của mình) hay tôi nên lưu trữ khóa SSH riêng (được mã hóa, thêm vào kiểm soát nguồn) trong dự án ansible của mình và sao chép nó bằng Ansible vào nút mục tiêu của tôi? Tôi biết câu hỏi có thể rất rộng, vì vậy điều tôi quan tâm là ý nghĩa bảo mật của cả hai phương pháp.

Câu trả lời:



4

Nếu git repos của bạn là một github riêng tư, bạn có thể sử dụng các phương thức github (các khóa triển khai rất mạnh).

Nếu repos của bạn không được lưu trữ trên github hoặc chúng không cung cấp tính năng khóa triển khai chỉ đọc, Hai tùy chọn bạn đã đề cập đều có giá trị.

Anh chàng độc thân

Nếu bạn là người duy nhất làm việc trong dự án và Máy / máy của bạn là người duy nhất bạn sẽ chạy ansible (không có công cụ CD như jenkins và bạn bè), bạn có thể sử dụng tùy chọn chuyển tiếp đại lý: ít có khả năng là bạn quên khóa riêng của bạn không được mã hóa xung quanh.

Đội nhỏ

Nếu bạn là một nhóm người làm việc trên cùng một Playbook Ansible hoặc nhiều người chạy Playbook thì bạn có cả hai tùy chọn:

  • giữ tùy chọn chuyển tiếp đại lý; mỗi đồng đội chạy kịch bản từ máy của anh ấy.

  • tạo cặp khóa triển khai, tải lên khóa pub và mã hóa riêng tư bằng vault theo đề xuất của Berlin . Khóa được mã hóa và phạm vi của khóa riêng được giới hạn chỉ 1 hoặc một vài repos. Vấn đề với cách tiếp cận này là bạn phải xoay mật khẩu vault mỗi khi đồng đội rời khỏi đội.

Tôi sẽ không bao giờ đặt khóa riêng cá nhân của mình, có phạm vi rộng, ở bất kỳ nơi nào có thể không an toàn. Mã hóa Vault tốt như những người sử dụng nó và có rất nhiều khóa / mật khẩu trong văn bản rõ ràng :)


2

Tôi có nên sử dụng chuyển tiếp tác nhân SSH (theo cách này tôi có thể sử dụng các khóa SSH cục bộ của mình)

Vâng, đó có thể là một lựa chọn

Tôi có nên lưu trữ khóa SSH riêng tư (được mã hóa, thêm vào kiểm soát nguồn) trong dự án ansible của mình và sao chép nó bằng Ansible vào nút mục tiêu của tôi không?

Không

/server/823956/ansible-security-best-practices

Đối với máy chủ, không cho phép truy cập root thông qua ssh. Nhiều kiểm toán chế giễu điều này.

Đối với ansible, hãy để mọi quản trị viên sử dụng tài khoản cá nhân của riêng họ trên mỗi máy chủ mục tiêu và để họ sudo với mật khẩu. Cách này không có mật khẩu được chia sẻ giữa hai người. Bạn có thể kiểm tra ai đã làm gì trên mỗi máy chủ. Tùy thuộc vào bạn nếu tài khoản cá nhân cho phép đăng nhập bằng mật khẩu, chỉ khóa ssh hoặc yêu cầu cả hai.

Tóm lại, sử dụng khóa ssh với mật khẩu. Hãy để mọi người dùng sử dụng các phím ssh của riêng họ. Không bao giờ cho phép truy cập sudo qua ssh.


hmm, tôi không chắc nếu điều này áp dụng cho bối cảnh. Tôi đã hỏi về các khóa SSH được sử dụng để lấy mã (chỉ đọc) từ kho lưu trữ khi triển khai một ứng dụng. Với tác nhân SSH, tôi cần thêm khóa công khai (mỗi người dùng) vào kho lưu trữ làm khóa triển khai.
pzaj

0

Bạn có thể kể chuyện khóa riêng của mình trong một trường hợp: nếu bạn định cấu hình kho lưu trữ của mình để nó chỉ cho phép truy cập đọc cho khóa cụ thể đó và bạn không bận tâm về việc kho lưu trữ có thể đọc được công khai. Trong trường hợp này, bạn có thể dễ dàng lưu trữ khóa riêng của mình - rõ ràng tạo một khóa vứt đi mà không cần cụm mật khẩu. Nhưng như tôi đã nói, chỉ khi bạn ổn với quyền truy cập công khai vào kho lưu trữ đó.

Nếu đó không phải là trường hợp, thì có lẽ bạn đang bị mắc kẹt với tác nhân SSH. Nó không lý tưởng, vì rootcó thể lấy ổ cắm, nhưng nếu bạn đang ở trong một loại môi trường nhân từ (nghĩa là không có máy chủ web có thể tấn công ở bất cứ đâu gần), thì nó sẽ ổn.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.