MastodonでLDAP認証を利用する
マストドンでは通常ローカルに認証情報を持つローカル認証を利用します。
しかし特殊な状況では外部の認証サービスを利用して認証を行うことができます。 Mastodon v3.1.4ではLDAP, PAM, CAS, SAMLに対応しています。
LDAP認証は実装された当初はバグっていたのですがいつの間にか改修されて使えるようになっていました。 LDAP認証を使う人はほとんどいないと思いますが、設定は解説がないので解説してみます。
LDAP認証設定
設定値は.env.production.sample
にあります。
# LDAP authentication (optional) # LDAP_ENABLED=true # LDAP_HOST=localhost # LDAP_PORT=389 # LDAP_METHOD=simple_tls # LDAP_BASE= # LDAP_BIND_DN= # LDAP_PASSWORD= # LDAP_UID=cn # LDAP_MAIL=mail # LDAP_SEARCH_FILTER=(|(%{uid}=%{email})(%{mail}=%{email})) # LDAP_UID_CONVERSION_ENABLED=true # LDAP_UID_CONVERSION_SEARCH=., - # LDAP_UID_CONVERSION_REPLACE=_
LDAP_METHOD
simple_tls
か start_tls
を選択できます。
実は LDAP_TLS_NO_VERIFY
というパラメーターが存在しており、 LDAP_TLS_NO_VERIFY=true
とすることでSSL/TLSで暗号化されないLDAPを利用することができます。
LDAP_BASE
ベース DNを記載します。
LDAP_BIND_DN
バインド DNを記載します。今のところ匿名バインド(anonymous bind)は設定できません。
LDAP_UID
MastodonのユーザーIDと対応させるLDAP属性を指定します。
一般的にはcn
でよいと思いますが、sAMAccountName
も使えるかもしれません。
LDAP_MAIL
メールアドレスが入っているLDAP属性を指定します。
LDAP_SEARCH_FILTER
LDAPの中からユーザーを探すときの検索フィルタを指定できます。 検索フィルタ自体の文法は RFC 4515を読んで頂くしかありません。
デフォルトでは
LDAP_SEARCH_FILTER=(|(%{uid}=%{email})(%{mail}=%{email}))
となっていますが、%{uid}
はLDAP_UID
で、%{mail}
はLDAP_MAIL
でそれぞれ置き換えられます。
%{email}
はログイン時にユーザーの入力したメールアドレスになります。
デフォルトの設定例ではLDAP認証時に
(|(cn=%{hoge@example.com})(email=hoge@example.com))
がフィルタとして利用されることになります。
LDAP_UID_CONVERSION_ENABLED
マストドンのユーザー名(username)には利用できる文字の制限があります。
使える文字は以下のようになっています。
/[a-z0-9_]+([a-z0-9_\.-]+[a-z0-9_]+)?/i
そうするとLDAPには存在するが、マストドンでは使えない文字が登場することがあります。 その場合にいい感じに変換してくれる機能がLDAP_UID_CONVERSIONになります。
LDAP_UID_CONVERSION_SEARCH
には、LDAPには存在するがマストドンでは使えない文字を指定します。
LDAP_UID_CONVERSION_REPLACE
にはそれらの文字が登場したときにマストドン上でのユーザー名に置き換える文字を指定します。
デフォルトの例だとLDAP上のユーザー名の中に含まれる., -
の3文字を_
で置き換えるようになります。
例えばLDAP上にkazuki-h
というユーザーがいた場合には、マストドン上でのユーザー名はkazuki_h
になります。
マストドンのユーザー名で使える文字種は増えているので使う機会はあまりないかもしれませんね。
LDAP認証を有効にするとどうなる?
新規登録が必要なくなる
マストドンに登録していない状態でログインすると、LDAP認証が成功すればその時点でユーザーアカウントが作成されます。 新規登録を「誰も許可しない」設定にしている場合でもLDAP認証によるアカウント作成は行うことができます。 このとき認証メールは送信されません。
運用途中でLDAP認証を有効にした場合は?
途中でLDAP認証を有効にした場合は、ローカル認証とLDAP認証が両方有効になった状態になります。 まず最初にLDAP認証でパスワードの確認が行われ、LDAPが通らなかった場合はローカルでの認証が行われます。 既存のユーザーはLDAPのパスワードも、ローカルのパスワードも両方使うことができます。 またLDAPには存在しないユーザーも残しておくことができますし、新規に作成することもできます。
一度も乗ったことのない車について
タイムズカープラスに入会した
マストドンセキュリティガイドライン
これからマストドンのインスタンスを建てようと思っている鯖缶の人たちへ セキュリティに関して気をつけるべき事項をまとめます。
ドメイン
Whois
それぞれのドメインには管理者の情報が登録されており、迷惑行為があった場合などに管理者に連絡がとれるように情報が検索できるようになっています。
実際に whois
コマンドを使って検索することができます。
[~] whois kantei.go.jp Domain Information: [ドメイン情報] a. [ドメイン名] KANTEI.GO.JP e. [そしきめい] f. [組織名] 内閣総理大臣官邸 g. [Organization] The Prime Minister's Official Residence k. [組織種別] 政府機関 l. [Organization Type] Government m. [登録担当者] MK072JP n. [技術連絡担当者] KW15930JP p. [ネームサーバ] ns7.kantei.go.jp p. [ネームサーバ] ns8.kantei.go.jp s. [署名鍵] [状態] Connected (2019/06/30) [登録年月日] 1994/06/24 [接続年月日] 1994/06/27 [最終更新] 2018/07/01 01:05:05 (JST)
もし特定のサイトから迷惑メールを送りつけられるとか、攻撃的なアクセスがあった場合などはここの情報をもとに連絡を取ることになります。
ここに表示される情報はトップレベルドメイン(TLD)ごとにポリシーが異なりますが、デフォルトの状態では個人でドメインを買った場合でも本名、メールアドレス、住所、電話番号などがそのまま掲載されてしまいます。 個人の場合は公開されたくないでしょうからその場合は ほとんどのレジストラで提供しているWhois情報公開代行サービスを最初から設定しておきましょう(後から設定すると追加料金を取るレジストラもあります)。
情報公開代行を行った場合は一旦レジストラが連絡を受けてドメインの登録者に中継してくれるようになります。ただしTLDによっては公開代行を禁止しているものもありますので、ドメインを取る前にポリシーを確認しましょう。
DNS CAA
DNS Certification Authority Authorization (CAA) は証明書の誤発行を防止する仕組みです。
設定しておくと証明書を発行できる認証局を制限することができます。実際に認証局が誤って証明書を発行してしまうということも起きていますのでなるべく設定しておきましょう。
Webサーバ
HTTPS (TLS)
マストドンはHTTPSの利用が必須です。 HTTPSの設定確認には Qualys SSL LABS SSL Server Test が便利です。レーティングがA以上になれば問題ありません。
どういうTLSの設定が良いかわからない場合はMozilla SSL Configuration Generator を利用するのはおすすめです。
TLSのバージョンですが、マストドンは新しいブラウザしかサポートされていないため、TLS1.2のみをサポートするようにすれば問題ありません。Mozilla SSL Configuration GeneratorではModernの設定がおすすめです。
HSTS
HTTP Strict Transport Security (HSTS) はHTTPの代わりにHTTPSを使って通信するようにブラウザに伝えるための機能です。一度アクセスしてしまえばたとえ http でアクセスしてもブラウザが自動でより安全な https で接続しに行くようになります。mastodonはhttpsしかサポートされていないためこの設定も入れておくと良いでしょう。Mozilla SSL Configuration GeneratorではHSTSの設定を追加することができます。
HTTPヘッダ
HTTPヘッダにはデフォルトではいろいろな情報が含まれています。 Apche HTTPDやnginxはOSやWebサーバのバージョンなどの情報を出力します。 最新のバージョンを利用するのは当たり前ですが、無駄に情報を与えてもいいことはありませんので設定で出力しないようにしましょう。
securityheaders.comではサーバが送信してくるヘッダの一覧を確認することができます。
nginxでサーバのバージョン情報を隠蔽したい場合は以下のように設定します。
http { server_tokens off; }
SSH
管理用にSSHを有効にすると思いますが、パスワード認証は絶対に使わないようにしましょう。絶対に破られます。 公開鍵認証を設定し、十分に長い鍵を利用しましょう。
SSHでログインした際には /etc/ssh/sshrc
が実行されるますのでログインした場合にメールなどで通知するようにすればより安全です。
さらにはインターネット側からSSHにアクセスするのではなく、AWS VPCなどを利用してプライベートネットワークからのみ接続できるようにするとより安全です。
ポートスキャン
必要最低限のポートしかアクセスできないようにするというのが基本です。 マストドンの場合は443番だけ開いていればサービスが可能です。同時に立ち上げる必要があるPostgresSQL、Redis、ElasticSearchのサービスがインターネットからアクセスできないようにiptablesやfirewalldを設定しましょう。
特定のポートが開いていないかしらみつぶしに調べる方法をポートスキャンと呼びます。
自分でポートスキャンを行うにはnmapコマンドを使って調べることができます。 自分の管理しているホスト以外には実行しないこと!!
[~] sudo nmap -v -sS -oA nmap_outout --port-ratio=0.0 example.jp Starting Nmap 7.70 ( https://nmap.org ) at 2018-08-26 22:18 JST Initiating Ping Scan at 22:18 Scanning example.jp (192.0.2.0) [4 ports] ...snip... PORT STATE SERVICE 80/tcp open http 443/tcp open https
DDoS
個人でDDoS対策をするのはかなり難しいです。 どうしても対策したい場合はAWSであればELBでAWS Shield Standardが無料で使えるのでそれを入れるか、Cloudflare を導入するのが簡単です。
IPv6
IPv6を設定する場合はiptablesに注意しましょう。IPv6はip6tablesに設定を書く必要がありますがこれを忘れてIPv6だけ穴だらけという事例が散見されます。
またIPv4でICMPをフィルタしている場合があるかと思いますが、IPv6ではICMPをすべてフィルタすると通信できなくなります。これはPath MTU Discoveryが必要になっているためです。よく考えて設定しましょう。
メールサーバ
マストドンはメール通知の仕組みがあります。 ユーザー登録時はメールで送られてくる認証リンクを踏む必要があり、メールがとどかないことは問題になります。 一般的にメールサーバを運用することはかなり難しく、また手間もかかります。 Mailgun や Amazon SES を利用するのがおすすめです。
ブラックリスト
自分でメールを送信する場合は気をつけることがたくさんあります。 まずメールの出口に割り当てられたグローバルIPアドレスを確認します。 通常IPアドレスは複数のユーザ間で使い回されるものですが、以前に使っていたユーザが迷惑メールをばらまいていたかもしれません。その場合ブラックリストに載っているかもしれません。
メールを受け取る方はいくつかのブラックリストを参照して、危ないホストからはメールを受け取らないように設定されていることがほとんどです。
複数あるブラックリストは MX Toolbox BLACKLIST CHECK でチェックできます。IPアドレスを設定した時点で最初にチェックしておきましょう。
SPF
Sender Policy Framework (SPF) は送信ドメイン認証のひとつです。差出人のメールアドレスが他のドメインになりすましをしていないか検出することができます。
SPFはドメインのTXTレコードに記載します。digコマンド を使って以下のように調べることができます。
[~] dig +short TXT muknown.jp "v=spf1 ip4:133.130.97.174 include:muknown.jp ~all"
上記はmuknown.jpが差出人になっているメールは「133.130.97.174」からのみ送信するという意味ですので、受け取る方はこのアドレス以外からのメールは破棄するようになります。
SPFはちゃんとかけているか確認するのが難しいのですが、 MxToolBox でチェックすることができます。
逆にメールを送らないホストがある場合にも、メールは送らないと書いておくと迷惑メールになりすまされてしまうことがなくなります。
料金監視
クラウド利用の場合一番怖いのが従量課金です。従量課金がないConohaなどを利用するのも手ですが、AWSを利用している場合はCloudwatchで料金監視を入れることができます。
プロバイダ責任制限法
プロバイダ責任制限法とは名誉毀損、著作権侵害、プライバシー侵害などの権利侵害が発生した場合に損害賠償責任を制限する法律です。ここでのプロバイダとはインターネットサービスプロバイダ(ISP) に限らずコンテンツプロバイダなどを含みます。つまりマストドンの管理をする上では必ず目を通しておく必要があります。
通常掲示板などで権利侵害が発生した場合、権利を侵害した側、権利侵害がを受けた側の双方からサーバの管理者が訴訟の対象になる可能性があります。 ただしこの法律に従って運用している限りは管理者は免責されます。
権利侵害が発生したことにを認識しながら対応を放置してると管理者にも損害賠償責任が発生する可能性があります。なにか起こる前に確認しておきましょう。
さいごに
インターネットは怖いところです。初心者であったとしてもそこは魔王城の前の毒の沼地です。ご丁寧にスライムを配置した街からスタートできるわけではありません。 常に最新の情報を仕入れて対応するようにしましょう。
pͪoͣnͬpͣoͥnͭpͣa͡inͥ を分解する
不思議なハッシュタグ #pͪoͣnͬpͣoͥnͭpͣa͡inͥ
これどうなってるんでしょうか? さっそくコードポイントを調べますが、お手軽にrubyで見てみましょう。
irb(main):001:0> 'pͪoͣnͬpͣoͥnͭpͣa͡inͥ'.each_codepoint { |cp| puts "U+#{sprintf('%04X', cp)} #{cp.chr('UTF-8')}" } U+0070 p U+036A ͪ U+006F o U+0363 ͣ U+006E n U+036C ͬ U+0070 p U+0363 ͣ U+006F o U+0365 ͥ U+006E n U+036D ͭ U+0070 p U+0363 ͣ U+0061 a U+0361 ͡ U+0069 i U+006E n U+0365 ͥ
ponponpain は通常のASCII文字ですが、間に何か入っていますね。
上についている文字は Combining Latin Small Letter で ͣ ͤ ͥ ͦ ͧ ͨ ͩ ͪ ͫ ͬ ͭ ͮ ͯ
が定義されています。アルファベットが全部定義されているわけではないのでharaitaiは奇跡の組み合わせです。
これはダイアクリティカルマーク(発音区別符号)と言って、文字につけて発音を区別したりするようです。ドイツ語のウムラウトがそうですね。
ちなみにひらがなや漢字と組み合わせてもうまくレンダリングできませんでした。
世界一美しい散歩道ミルフォードトラックを歩いてきた
ミルフォードトラック(Milford Track)は、ニュージーランド南島のフィヨルドランド国立公園内にある全長53.5kmのトレッキングコースです。 「世界一美しい散歩道」と評される、氷河が削ったその急峻な大地はまさに絶景の一言です。
ミルフォードトラック
ミルフォードトラックは一日90名の入場制限がかかっており、一方通行で自由に歩くことはできません。事前に全ての山小屋を予約してから決められたコースを歩くことになります。このため非常に人気のあるコースですが、とても静かに歩くことができます。
このトレッキングに参加するにはUltimet Hikes社の実施するガイド付きウォーク(Guided Walk)に参加するか、公営の山小屋を手配して自分で歩く個人ウォーク(Individual Walk)とする方法があります。今回私は2017年11月25日から4泊5日のガイド付きウォークに参加しました。
1日目(クイーンズタウンからグレードハウス)
ミルフォードトラックの近くには大きな街がありませんので、拠点は少し離れたクイーンズタウンになります。クイーンズタウンは小さい町ですが、様々なアクティビティの拠点になっているため各種アウトドアショップが揃っており準備には最適な場所です。
ガイド付きウォークではクイーンズタウンからの送迎が付いており、まずはバスで5 時間ほどかけてテ・アナウまで移動します。
実はこのミルフォードトラック、高い山に阻まれ登山道にアクセスするのが容易ではありません。そのためテ・アナウダウンズという場所からまで行って、そこから船に乗って約1時間ほどテアナウ湖を横断します。
ちなみに扉峠(Door Pass)という場所を通って陸路でアクセスすることもできますが、かなりの上級者向けコースとなっています。
ここから約20分ほど歩くだけで最初の宿泊場所グレードハウスに到着です。
ガイド付きウォークと個人ウォークでは宿泊する場所が異なっており、ガイド付きウォークではUltimet Hikes社の所有するプライベートロッジに宿泊することができます。このプライベートロッジはフルコースの料理に、シャワー、強力な乾燥室、またプランによっては個室も選ぶことができます!
個人ウォークで宿泊する山小屋は自炊小屋で管理人はいますが、2段ベッドと自炊設備のみになります。個人ウォークの宿泊場所はガイドウォークのロッジのだいたい1時間先に設置されています。
ネイチャーウォーク
初日はそのままネイチャーウォークといってロッジ周辺をぐるりと回ってガイドの方が周辺の植生や、鳥について解説をしてくれます。
フィヨルドランド国立公園は非常に降水量が多い地域として知られています。屋久島の倍以上、年間8000mmも降る雨ばかりの土地です。 このような土地なので非常に美しい苔を見ることができます。
グレードハウス
プライベートロッジにはこのように広々としたロビーがあって、到着後くつろぐことができます。
ガイド付きツアー最大の魅力は食事かもしれません。
前菜、メイン、デザートのコースで提供されます。メインは毎日3種類の中から選ぶことができ、牛肉など、鶏肉または魚、ベジタリアンミールから選ぶことができます。
この日は鹿肉を選んでみました。
2日目(グレードハウスからポンポローナロッジ)
昼食作り
朝食の前にその日のお昼に食べるサンドイッチをみんなで作ります。 チョコレートやナッツ、バナナやリンゴなどのフルーツ類も持っていくことができるので行動食も準備不要です。
クリントン川
クリントン川沿いに進んでいきます。
2日目は16kmほど歩きますが、一番ラクな道のりです。 この写真のように道は非常によく整備されており、路肩や看板、小さい橋から大きい橋までまったく不備がありません。
ほぼ平坦な道のりなのでゆっくり歩くことができます。
ガイド付きウォークには最大50人参加することができ、ガイドが4人付きます。日本のようにまとまって1列に歩くわけではなく、先頭と最後に2人、真ん中に2人のガイドが列の中を行き来してくれ、参加者は自分のペースで自由に歩くことができます。 ガイドは4人中1人が日本人の方でした。
まったく迷う心配がない道で危険な場所もほとんどないためゆっくり楽しみながら歩くことができるのがこのコースの良いところです。
ニュージーランドといえばマヌカハニーを思いかべるかもしれません。マヌカの木はここミルフォードトラックにも自生しています。
ミルフォードトラックには倒木がたくさんあります。氷河削った土地は斜面が急すぎて土壌が薄く、ある程度大きくなった木々は倒れていってしまうそうです。 倒木には苔が生え、また新しい芽が出て育っていきます。
ミルフォードトラックはこのような谷を歩いて行くコースです。 周りの山は2000m程度の山が連なっていますが、1万年前まではここはすべて氷河の下でした。
長い年月をかけて氷河が海に流れていく過程で谷を2000m削り、今のような地形ができがったのです。 森を抜けると迫力満点の谷が迫ってくるようです。
スイミングプール
この日の最後の目玉はプレイリー湖です。Swimming Poolと名前がついており、泳げるとのことでしたが、この日は日中22度ほど。歩くには暑いのですが、キンキンに冷えており泳ぐには厳しい感じです。みんな靴を脱いで足湯のようにつかって涼んでいました。
バス停
この日宿泊地ポンポローナロッジまではもう少しなのですが、突然バス停が現れます。
実はこの先の川が、雨が降るとよく通れなくなるためここで雨宿りをするのです。 どうしても通れないほどに雨が降ってしまった場合はヘリコプター移動となってしまうこともあるそうです。
ポンポローナロッジ
実はこのロッジ、たくさんの特別があるんです。
100年前に建てられたときから受け継がれてきたオリジナルレシピのスコーンが出迎えてくれます。
夕食はココナッツカレーを選びました。
デザートはおいしそうなクリームブリュレでした。
とってもイタズラ好きなオウムのキアが遊びに来ます。 飾ってある登山靴はキア用のおもちゃで、夕食時になるとこのようによく遊びに来ます。好奇心が強く人が近寄っても逃げません。
また朝食は特別メニューとしてエッグベネディクトを注文することができます。
3日目(ポンポローナロッジからクィンティンロッジ)
3日目はこのミルフォードトラックの最高地点であるマッキノン峠を超える15kmの道で、峠越えになる一番きつい日になります。700m登って900mほど降りる計算になります。
飛べない鳥ウェカ
ニュージーランドはもともと哺乳類はコウモリの2種類しかおらず、蛇などもいない特殊な環境であったため鳥類が反映しました。天敵がいなかったためニュージーランドの国鳥であるキーウィー(Kiwi)やウェカ(Weka)などの飛べない鳥をたくさん見ることができます。
ここの鳥は警戒心というものがないのか、まったく逃げません。野鳥観察にはもってこいです。
マッキノン峠
ミルフォードトラックの最高点がこのマッキノン峠です。ここは1,140mしかないのですが、森林限界は7、800m程度にあり抜群に景色がいい場所になっています。ぜひ晴れてほしい場所です。
風景を撮っていたらキアが写りに来てくれました。
3日目のお昼はここで食べます。写真は世界一眺めのいいトイレ(笑)。
エマージェンシートラック
ミルフォードトラックは雪崩の名所です。氷河が削った急峻な大地はいたるところで雪崩を発生させます。コースがオープンするは11月からですが、12月の上旬ごろまでは雪崩発生があるため一部通れないコースが設定されることがあります。
エマージェンシートラックはいわゆる旧道というやつになっています。新道よりは短いのですがその分急になっており膝に注意です。
ところで参加者は日本からのツアーとあたってしまったようで半分以上日本人という構成になっていました。通常日本人は50人中1、2組とのことです。
新婚旅行で来ていたカップルが4組もいました。おすすめです。
サザーランド滝
クィンティンロッジに着いたら荷物をおろしてサザーランド滝を見に行きます。 クィンティンロッジの裏から道が続いています。
落差580mは世界第5位だそうで、ニュージーランドで最大の滝です。 この日は晴れ続きで水量が少なかったそうですが、それでも近づくとカメラを出せないくらいに浴びることができます。
クィンティンロッジ
ご飯を食べる場所。どこにもピアノが置いてあります。 本当にここは山小屋なんだろうか?
本日はステーキとなっております(ちょっとかたかった)。
ちなみにホットドリンクは飲み放題で、紅茶や緑茶、ミロ、コーヒー、エスプレッソが用意されています。 コーラやスプライトなどのコールドドリンクや、ワインやビールなどのアルコールは有料になっています。ワインは結構種類が豊富でそんなに高くありません。
4日目(クィンティンロッジからマイターピーク)
いよいよ歩行最終日。最終日はなんと21kmも歩きますが、ほとんど平坦なので心配はいりません。
深い森、深い谷、交互に色んな表情を見せてくれます。 ここで子連れのウェカを見つけました。
ここは南半球。紫外線には注意です。
お昼ポイントのジャイアントゲート滝。 あまりにも気持ちが良いので長居をしてしまいます。
残り1マイルの標識が見えてきました。だんだん名残惜しくなってきてのでちょいちょい寄り道をします。
終点サンドフライポイントです。ここまでで33.5マイル、35.5km完走です。
サンドフライとはアブの1種なのですが、ミルフォードトラックにはこのサンドフライがものすごい数飛んでおり、噛まれたときの被害は甚大です。マオリの伝説にはあまりにもすばらしいこの地に人が長居しないように神が作ったとあるそうです。
サンドフライポイントで船に乗って最後の宿泊地マイターピークロッジへ向かいます。
マイターピークロッジ
最後はミルフォードサウンド内唯一の宿泊施設マイターピークロッジへ向かいます。 マイターピークロッジはこのツアー専用のプライベートロッジになっており、ガイド付きウォークに参加しないと泊まることができません。ミルフォードサウンドは非常に有名な観光地で観光客も多数訪れるのですが、この景色を見ながら泊まれるのはここが唯一の特別なロッジなのです。
この景色最高です。
最終日はラム肉。とっても柔らかくおいしかったです。
5日目(マイターピークからクイーンズタウン)
ミルフォードサウンド クルージング
最終日のトレッキングはありません。ミルフォードサウンドで2時間ほどのクルージングがツアーに含まれています。
ここミルフォードサウンドは野生のペンギンや、アザラシなどを間近に見ることが非常に貴重な場所です。望遠レンズを持っていけばよかった。
できるならもっと歩いていたい、すばらしいトレッキングになりました。
drone.io v1.0に向けて
この記事は drone.io Advent Calendar 2017 - Adventar 最終日の記事です。
drone.io は Goで作られたオープンソースのCD (Continuous Delivery)環境です。
droneは現在v0.8.3が最新版となっています。次はv0.9が予定されています*1が、v1.0ではどのようになるのか予想してみたいと思います。
新機能予想
Kubernetes サポート
作者はdroneの実行環境としてKubernetesは重要であると考えており*2、まだ利用はされていませんがKubernetes APIを利用するコードがコミットされています。*3
現在のagentはdocker socketをvolume mountする仕様になっていますので、Kubetnets上では制約が出てきてしまいますし、スケーラビリティを確保したい場合はこの対応が必須になります。
Windows サポート
近いうちにありそうなのがWindowsコンテナのサポートです。WindowsコンテナはWindows Server 2016から対応しています。マルチプラットフォーム対応自体は行われていますので難しくはないと思われますが、まだいくつかタスクが残っているようです*4。
コントリビュートしてくれるひとがいればもう少しはやく進むかもしれません。
ネイティブ実行モード
WindowsやmacOSでのネイティブ実行がサポートされるかもしれません*5。これができるとiOSのビルドができるようになり非常に便利ですが、ビルドの隔離をどうやるかが課題なのですぐには入らないかと思われます。Vagrantのような仕組みを使って仮想マシンベースの仕組みになるかもしれません。
v1.0に向けて
v1.0 まではいくつかのIssueが残るのみです*6。 大きな機能追加等はv1.0までに行われ、その後は安定性の向上やコードの改善に注力すると表明されています。 これまでのバージョンアップでは毎回破壊的な変更が起きていましたが、そろそろ落ち着くことになりそうです。
これからのdrone先生の活躍にもご期待下さい!
*1:https://github.com/drone/drone/projects/4
*2:https://gcppodcast.com/post/episode-70-drone-ci-with-brad-rydzewksi-and-jessie-frazelle/
*3:https://github.com/cncd/pipeline/blob/master/pipeline/backend/kubernetes/kubernetes.go
*4:https://github.com/drone/drone/issues/1330#issuecomment-330394262