Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

servers.csv の「公開鍵」欄は無くすべきか? #56

Open
miya0001 opened this issue Aug 31, 2017 · 12 comments
Open

servers.csv の「公開鍵」欄は無くすべきか? #56

miya0001 opened this issue Aug 31, 2017 · 12 comments

Comments

@miya0001
Copy link
Member

サーバーを本来の管理者の代理で申請している例が散見されますが、以下の点でちょっと問題がある気がします。

  • 代理で申請する理由自体がそもそもろくなものじゃない気がする。
  • 本人確認がさらに困難。ほんとに依頼されたのかというリスクがある。
  • 公開鍵の所有者が完全に外部の人であることを確認することが困難。

改善案

現状の DojoPaas から公開鍵の列を削除して、プルリクをくれた人のGitHubユーザー名から公開鍵を取得する。
こうすることで、公開鍵に対する本人確認が可能。

@yasulab
Copy link
Member

yasulab commented Aug 31, 2017

Pros は description に書かれた通りで、僕もその指摘には同意する立場です。一方、あえて Cons 側も挙げておくと、例えば代理申請を拒否する場合、サーバーについて詳しくない人がサーバー申請しづらくなる、という点があります。

現状の DojoPaas から公開鍵の列を削除して、プルリクをくれた人のGitHubユーザー名から公開鍵を取得する。こうすることで、公開鍵に対する本人確認が可能。

また、GitHubのユーザー名から公開鍵を取得しても、本人確認は結局のところできないのではないか、というのが僕の認識です。例えば悪意を持ってGitHubの新規アカウントを作り、代表者の名前を騙って申請された場合、僕ら (Admin権限を持っているチーム) にはそのアカウントが本人なのかどうか確認できないと思うのですが、いかがでしょうか? 🤔 @miya0001

@miya0001
Copy link
Member Author

miya0001 commented Aug 31, 2017

サーバーについて詳しくない人がサーバー申請しづらくなる

あっ、これはデメリットじゃないとも言えるかもですね。笑
実際僕はむしろそうしたほうがいいかなと。

また、GitHubのユーザー名から公開鍵を取得しても、本人確認は結局のところできないのではないか、という認識です。悪意を持ってGitHubの新規アカウントを作り、代表者の名前を偽り、代表と名乗って申請した場合、本人確認はできないと思うのですが、いかがでしょうか?

まあたしかにそうですが、今よりはマシかなと。あとOrganizationとしてそのユーザーをブロックすることもできます。

@miya0001
Copy link
Member Author

miya0001 commented Aug 31, 2017

チャンピオンじゃなくてもいいのでちゃんと管理ができる人が申請したほうがいいんじゃないかなと。
あと同じ道場のチャンピオンからもコメントをもらうようにするとか。

管理ができない人がサーバーの申請を誰かに頼む。そのとき公開鍵はだれのものなんでしょうね?
たとえば、以下の場合、本来の申請者さんはプルリクができないけど証明書はその人のものってことになっているようです。
#55
この場合、最悪のシナリオは秘密鍵を共有されちゃうことかなと。

@yasulab
Copy link
Member

yasulab commented Aug 31, 2017

チャンピオンじゃなくてもいいのでちゃんと管理ができる人が申請したほうがいいんじゃないかなと。
あと同じ道場のチャンピオンからもコメントをもらうようにするとか。

@miya0001 あれ、僕の認識ではこれが現状の体制だという認識ですが、そこの認識ってもしかして食い違っていますか? 💦

なお、代理での申請も受け付けております。その場合は代表から代理人に移譲された旨をプルリクエストにコメントしていただけると幸いです (参考: 代理申請の例)。

引用元: https://github.com/coderdojo-japan/dojopaas/blob/master/README.md#1-サーバーがほしい方へ

@miya0001
Copy link
Member Author

あっ、代理の意味が食い違ってました。
チャンピオンから委任されて代理でサーバーを管理するならいいんですが、 #55 の例では、サーバーを管理しない人がチャンピオンの鍵をもらって申請しているようです。

@miya0001
Copy link
Member Author

申請者さんは、CSVに記載された公開鍵の所有者さんじゃないという意味での代理です。

@yasulab
Copy link
Member

yasulab commented Aug 31, 2017

なるほど! そうすると本 Issue の内容はこんな感じになるわけですね🤔

  1. サーバー申請は代理人でも可
    • ただし、他人の公開鍵を借りた代理申請は不可
  2. 常に公開鍵とアカウントを紐づければ、上記を防げる
  3. そのためには、公開鍵を "github.com/#{username}.keys" から取ってくれば良い

みたいな認識ですかね! とても納得のいくストーリーな気がします 😆

@miya0001
Copy link
Member Author

もしワークフローで解決するなら、サーバーを管理する人がチャンピオンから委任されたことを宣言した上で申請。
チャンピオンも同じプルリクに確かに委任しましたとの旨を書いてもらう感じですかね。

じゃないと実際にサーバーに何かする人をトラッキングできないんじゃないかなーと。

@yasulab
Copy link
Member

yasulab commented Aug 31, 2017

もしワークフローで解決するなら、サーバーを管理する人がチャンピオンから委任されたことを宣言した上で申請。
チャンピオンも同じプルリクに確かに委任しましたとの旨を書いてもらう感じですかね。

ですね。READMEに記載されているとおり、現状ではこのワークフローで解決する方法を採用していて、代理申請の場合は #45 のような形で申請・承認するフローを採っています ✅

@yasulab yasulab changed the title 代理申請等の拒否 servers.csv の「公開鍵」欄は無くすべきか? Aug 31, 2017
@yasulab
Copy link
Member

yasulab commented Aug 31, 2017

Issue タイトルを具体化してみました。もし認識が間違っていたら適宜修正してもらえると助かります 🙏

@yasulab
Copy link
Member

yasulab commented Aug 31, 2017

公開鍵の所有者が完全に外部の人であることを確認することが困難。

もう1つ、ほとんど似たような解決策ですが、例えば pubkey 欄を github 欄に変えてみるという手もあるのかなと思いつきました🤔 というのも、「公開鍵からの本人確認が面倒」「PRに慣れていない場合にもうまく対応したい」の2つが今回のポイントかなと感じていて、その両方をうまく解決した方が申請も運用も楽になりそうだからです。

具体的には、次の2つのユースケースに対応できるのがこの方法の良いところかなと考えています 💭

  1. github欄を見れば、本人申請か代理申請かの判別が楽
  2. 不備のあるPRだった場合、管理者がgithub欄を修正してあげることができる
    • 例: CoderDojo 藤沢 #55 の場合、「代理人のGitHubアカウント名に修正しておきますね」みたいなサポートができる

(あと細かな点ですが、servers.csvを後で見返したとき、「誰がアクセス権限を持っているか」が一覧できるという点もありそうです)

まとめると、不備のあるPRは今後もあると思うので、github欄を設けることで運用で解決できる余地を残す、って感じですかね🤔 といっても公開鍵を参照するフローは全く同じなので、その点ではほとんど似たアプローチではありますね 😅 (提案していただいたフローの微修正版、みたいな)

@miya0001
Copy link
Member Author

なるほど。アクセス権の一覧という効果は美味しいですね。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants
@yasulab @miya0001 and others