2015-07-29 17 views
7

Tôi khá mới với đường ray, nhưng tôi có một số chương trình kinh nghiệm trong PHP và các ngôn ngữ khác. Tôi thực sự thích đường ray, và tôi đang làm việc trên một ứng dụng cho công ty của tôi, nhưng tôi vẫn không hoàn toàn hiểu cách thức tệp tin secret.yml hoạt động với git và heroku. Tôi hiểu rằng những bí mật được sử dụng để xác thực, nhưng tôi không hiểu chính xác làm thế nào để giữ bí mật chúng trong khi vẫn triển khai đến heroku thông qua git.Làm cách nào để giữ bí mật bí mật trong đường ray?

Câu hỏi đầu tiên là, tôi có thực sự cần giữ bí mật phát triển và kiểm tra bí mật của mình không? Rails tự động đặt bí mật phát triển sản xuất vào bí mật môi trường (mà tôi vẫn chưa hiểu hết), nhưng tại sao nó lại quan trọng nếu mọi người biết bí mật phát triển và kiểm thử của tôi là gì?

Thứ hai, một nguồn lực tốt để hiểu rõ hơn bằng cách sử dụng tệp tin bí mật.yml kết hợp với git là gì? Các hướng dẫn đường ray dường như không tài liệu sử dụng nó rất tốt (chỉ có một đoạn được dành riêng cho secrets.yml), và điều này có vẻ như một chủ đề khá quan trọng có thể dẫn đến một lỗ hổng bảo mật nghiêm trọng trong ứng dụng của bạn.

Cuối cùng, làm cách nào để người khác bảo vệ bí mật của họ? Nhìn vào một số ứng dụng ví dụ trên github, tôi đã nhận thấy rằng hầu hết mọi người dường như không thực hiện bất kỳ bước nào để giữ tệp bí mật trong .gitignore. Đây có phải chỉ là một sự giám sát, hay là vì nó không nghiêm trọng về vấn đề an ninh như tôi nghĩ?

Tôi đánh giá cao bất kỳ trợ giúp nào tôi có thể nhận được. Tôi đã nghiên cứu vấn đề cụ thể này một thời gian và chưa thực sự nhận được bất kỳ giải pháp toàn diện nào cho vấn đề này. Tôi muốn trình bày dự án của mình với công ty và giải thích các lợi thế của việc sử dụng các hệ thống kiểm soát phiên bản như git, nhưng tôi cũng muốn ứng dụng đủ an toàn để tin tưởng rằng nó giữ dữ liệu của công ty tôi an toàn.

+0

Lưu ý rằng Heroku đẩy bạn đặt biến môi trường với cấu hình ứng dụng của bạn - xem tại đây: https://devcenter.heroku.com/articles/config-vars – elithrar

Trả lời

2

Tất cả các câu hỏi rất hay. Mặc dù có thể không có tác hại nghiêm trọng trong việc không đảm bảo bí mật phát triển và kiểm tra, nhưng thực hành tốt là điều tốt. Không có sự lộn ngược trong việc tiết lộ thông tin có khả năng khiến một diễn viên xấu truy cập vào mã hoặc dữ liệu ứng dụng của bạn dễ dàng hơn.

Do Rails 4.1, config/secrets.yml có thể được sử dụng để quản lý tất cả bí mật ứng dụng của bạn. Điều này được mô tả trong Rails 4.1 release notes. Nếu bạn quản lý các bí mật của mình trong tệp này, bạn chắc chắn nên đưa tệp vào .gitignore để bí mật của bạn không hiển thị trong kho lưu trữ mã của bạn, ngay cả khi nó hiện đang ở chế độ riêng tư. Bạn không bao giờ biết liệu bạn có muốn mở mã nguồn của mình trong tương lai hay chia sẻ kho lưu trữ riêng của bạn với một cộng tác viên khác hay không. Như bạn có thể biết, một khi bạn đặt một tập tin trong git, nó có thể là một quá trình liên quan để loại bỏ tất cả dấu vết của nó. Ngoài ra, bạn có thể duy trì một mẫu secret.yml trong git để bạn có quyền kiểm soát nguồn của định dạng tệp bí mật của mình, nhưng giữ bí mật thực tế trong một tệp riêng biệt.

Cách bạn quản lý bí mật trong sản xuất tùy thuộc vào nền tảng triển khai của bạn. Nếu bạn triển khai đến máy chủ của riêng mình, bạn chỉ cần đảm bảo rằng bạn có một cơ chế để duy trì riêng việc triển khai secrets.yml, vì nó sẽ không có sẵn trong kho git của bạn. Bạn sẽ có thể quản lý điều này thông qua quá trình triển khai của mình bằng cách sử dụng công cụ như Capistrano hoặc Mina. Nếu bạn triển khai vào Heroku, bạn cần phải đặt các biến cấu hình thông qua Heroku CLI hoặc bảng điều khiển Heroku như được mô tả trong documentation.

Hy vọng điều này sẽ hữu ích.

+0

cảm ơn bạn Steve - nói cách khác - giả sử tôi là triển khai cho Heroku: (i) tôi sẽ thêm bí mật vào .gitignore và (ii) tôi sẽ thêm secret_key_base theo cách thủ công cho môi trường phát triển, thử nghiệm và proudction theo cách thủ công thông qua CLI Heroku - tôi có đang theo dõi bạn một cách chính xác không? – BKSpurgeon

0

tắt Trước tiên, tôi luôn thêm tất cả .yml file đến file .gitignore của tôi, như thế này:

*.yml 

này phục vụ để giữ bất kỳ tập tin cấu hình tắt của git.Tuy nhiên, tôi cũng tạo "tệp phân phối" để tiếp tục sử dụng git. Về cơ bản, sao chép somefile.yml đến somefile.yml.dist và xóa các giá trị thực, nhưng giữ nguyên cấu trúc/khóa, vì vậy bất kỳ ai khác sử dụng mã của bạn đều có thể tự điền vào các ô trống.

Giữ bí mật phát triển/kiểm tra của bạn không quan trọng, miễn là chúng khác với bí mật sản xuất của bạn. Một số bí mật (như nếu bạn đang sử dụng Cloudinary) là giống nhau cho tất cả các môi trường, vì vậy bạn không muốn chia sẻ chúng.

+0

Không nên là '.gitignore' là'/config/*. Yml'? Ngoài ra, tôi sẽ không được như vậy cavalier về môi trường phát triển và thử nghiệm của bạn. Như bạn nói, bí mật có thể được chia sẻ giữa chúng, cộng với nếu bạn không cẩn thận về vệ sinh dữ liệu, bạn có thể kết hợp với dữ liệu sản xuất trong môi trường thử nghiệm để kiểm tra tải, gặp sự cố sản xuất, v.v. –

+0

Tôi không hiểu cách loại trừ tất cả các tệp '.yml' của tôi sẽ dẫn đến các vấn đề về dữ liệu chéo. –

2

Theo như tôi có thể nói Rails chưa giải quyết vấn đề này (như của Rails 4.2).

Dưới đây là một vĩ đại summary of the mess situation

Từ Rails 4.1 có một tập tin secrets.yml mà là cho tất cả những bí mật của bạn, nhưng nó không có trong .gitignore theo mặc định. Mọi người bảo bạn đặt nó vào .gitignore nhưng điều đó không giúp người dùng Heroku đưa nó vào sản xuất. Có a gem có thể trợ giúp về điều đó. Nếu bạn làm điều đó thì bạn có thể cũng chỉ cần sử dụng Figaro gem mà làm tất cả những gì trong một cách neater.

Từ nội dung mặc định của tệp secrets.yml trông giống như các nhà phát triển Rails dự định đưa vào kho mã nguồn, nhưng đối với bất kỳ bí mật thực nào bạn phải sử dụng biến môi trường và nhập những bí mật đó tập tin, mà gần như đánh bại mục đích.

Nếu bạn muốn sử dụng biến môi trường để giữ bí mật, điều đó có nghĩa là hệ điều hành bên dưới lưu trữ chúng cho bạn và khi bạn cần sử dụng chúng, bạn hỏi hệ điều hành biến là gì, theo cách đó không có trong mã của bạn tất cả các. Lệnh để đặt biến môi trường trên Heroku trông như sau:

heroku config:set YOUR_SECRET_VAR_NAME=your_secret 

Có những bất lợi khi thực hiện theo cách này. Nếu bạn có rất nhiều bí mật, mọi thứ sẽ nhanh chóng bị lộn xộn và sẽ rất khó để thiết lập nó trên một máy tính mới.

các dotenv gem giải quyết các vấn đề này cho phép bạn thực hiện các biến môi trường mà không có tất cả những nhược điểm của chúng. Tôi khuyên bạn nên sử dụng dotenv kết hợp với secrets.yml mà không cần đặt sectrets.yml trong .gitignore và đặt biến môi trường theo cách thủ công trên Heroku.

5

Đây là hướng dẫn từng bước (hy vọng đơn giản) CHO HEROKU cần được thực hiện trước khi đẩy tệp (secrets.yml) sang GitHub hoặc máy chủ lưu trữ khác.

* Tôi không phải là một chuyên gia về chủ đề này nhưng điều này làm việc tốt cho tôi và có vẻ như là một giải pháp tốt. Nó kết hợp thông tin từ câu trả lời cho câu hỏi này cũng như câu trả lời cho câu hỏi này (Step by Step explanation for using Rails secrets.yml without exposing keys to public repo when deploying to Heroku) để cung cấp một hướng dẫn đơn giản :)

1) Copy secrets.yml khác file có tên secrets_backup.yml

bây giờ bạn nên có hai tệp có cùng nội dung như secrets.yml

2) Thêm secrets_backup.yml vào của bạn.gitignore

3) Thay đổi văn bản trong secrets.yml như sau

development: 
    secret_key_base: <%= ENV["SECRET_KEY_BASE_DEV"] %> 
test: 
    secret_key_base: <%= ENV["SECRET_KEY_BASE_TEST"] %> 
production: 
    secret_key_base: <%= ENV["SECRET_KEY_BASE"] %> 

4) cd đến đường ray của bạn thư mục dự án trên dòng lệnh

5) Trong các loại thiết bị đầu cuối heroku config:set SECRET_KEY_BASE_TEST=<pasted key>, nơi <pasted key> nên được sao chép và dán từ số test: secret_key_base:<key> trong số secrets_backup.yml

6) Trong loại thiết bị đầu cuối heroku config:set SECRET_KEY_BASE_DEV=<pasted key>, nơi <pasted key> nên được sao chép và dán từ development: secret_key_base:<key> mà là ở secrets_backup.yml

7) tập tin secrets.yml của tôi đã có SECRET_KEY_BASE thay vì chìa khóa thực tế, vì vậy tôi nghi ngờ bạn sẽ quá. Nhưng nếu không, hãy đặt biến SECRET_KEY_BASE khi hai biến còn lại được đặt ở trên.

8) Đẩy repo của bạn để GitHub và Heroku

9) Nụ cười bởi vì bạn là G.O.A.T và khoe website ngọt ngào của bạn!

Các vấn đề liên quan