JOSUG2014 OpenStack 4th birthday party in Japan; the way of OpenStack API Dragon

the Way of the OpenStack API Dragon
(2014/07/09, Shibuya GMO yours)
GMOインターネット株式会社
システム本部　第2サービス開発部
オープンコンピューティングチーム
　郷古直仁
　
openstack!
Open source software to build public and private clouds.
OpenStack !
4th Birthday party
“the Way of the OpenStack API Dragon”!
~GMOアプリクラウドのAPI公開への道~

Atlanta Summitから話題の
Chuck Norris
もともとUSではもうすでに慣用句らしい
(wikipedia:
チャック・ノリス・ファクト)
なんで、the OpenStack API Dragon !??

名誉海兵隊員だったりチェーンソーを素
手で受け止めたりするけど、最近では
炎のテキサスレンジャー
有名な初期の出演作は
ドラゴンへの道
なんで、the Way of the OpenStack API Dragon !??

ということで、OpenStackのAPIを
Public Network(the Internet)に公
開して、セキュリティを設定して利用で
きるようにすることを、この場では
the OpenStack API Dragon
と設定します :)
なんで、the Way of the OpenStack API Dragon !??

Atlanta summitのops Meetupで
API Endpointをどうやって守るって話
題があったみたいです
!
Atranta summit ops Meetup
http://www.slideshare.net/inouetmko/josug20140619
the OpenStack API Dragon は

API Endpointを守る(Layer 7)
Examples) ops Meetupより
- mod_security
- nginx
- NetScaler
etc.
the OpenStack API Dragon は

弊社環境でも同じようにやっています
!
GMOアプリクラウドのOpenStack
Havana環境ではこんな感じ
!
- nginx
- HAProxy

今日のLT内容
きょうは、清楚かわいい座敷わらしが
応援団長のVPSのConoHa(Grizzly)の
話ではなく、

アザトかわいいといわれる座敷童が応
援団長の「GMOアプリクラウド」が
オンプレミスの仮想化から、
OpenStack Hava
を採用して、OpenStack APIを使える
ようにしたドラゴンの道のお話
今日のLT内容:GMOアプリクラウドOpenStack API公開について

1) 課金処理が量計式ではなく、コントロールパネ
ル(web GUI)の処理に依存
(nova bootとか無理)
2) 裏の会員処理と紐付いたコントロールパネル用
のWrapper API(RESTful)を作りこんでしまっ
た
(OpenStack APIとは形式違うw)
3) OpenStack自体にも手を入れすぎちゃった
(HP Cloudの真壁さんのお話、参考になる)
では、なぜConoHaではOpenStack APIが公開できなかったの?

たとえば、2) コンパネ用API(RESTful) by ConoHa
こんなかんじに、全
く違うAPIでweb
GUIが動き、その裏
でOpenStack
APIがcallされてい
るのがConoHa

ConoHa コンパネとAPI proxy, OpenStack API
ConoHaコンパネAPIのアク
セスの関係はこんな感じ
!
できれば、今後はコンパネ
API と公開API の二重開発
みたいなことは避けたい
コントロールパネル (IIS, .Net)
API Proxy
(httpd, php
Framework: fuel php)
Grizzly
Nova API
会員システムAPI
Grizzly
Quantum API
Grizzly
Glance API
ConoHaコンパネAPI
会員DB
Grizzly
Keystone API
OpenStack API

そして、OpenStack Havanaでの開発
GMOアプリクラウドの
OpenStack Havana化
!
それまでの反省から、ほとんどの
操作系をOpenStack APIのまま
web GUIのコントロールパネル
を開発することになった
=>> その代わり、API公開を前提に、OpenStack API
のValidation checkをコンパネのためにも作ることに

1) OpenStack API validation proxy for webGUI
API公開前提でConoHaで作ったコンパネAPIで
はなく、OpenStack APIそのものにValidation
checkを
OpenStackの改変せずに
実装する
=>> API Proxy方式
web GUIでも、API公開でも間違った値では、APIに到達する前
にエラーを返す(ex: 商品スペックにないストレージサイズとか)
=> API workerの負荷コスト削減

1) OpenStack Havana API validation proxy for webGUI
GMO Apps CloudのOpenStack API
のアクセスの関係はこんな感じ
コントロールパネル(httpd, php)
API wrapper proxy
(httpd, php
Havana
Nova API
Havana
Quantum API
Havana
Glance API
OpenStack API for
input validation
会員DB
Havana
Keystone API
OpenStack API
Havana
Cinder API
Havana
Ceilometer API
=>> コンパネが公開後のOpenStack API
と同じものにアクセスする想定で構成

1) OpenStack Havana API validation proxy for API公開
GMO Apps CloudのOpenStack API
のアクセスの関係はこんな感じ
コントロールパネル(httpd, php)
API wrapper proxy
(httpd, php
Havana
Nova API
Havana
Quantum API
Havana
Glance API
OpenStack API for
input validation
会員DB
Havana
Keystone API
OpenStack API
Havana
Cinder API
Havana
Ceilometer API
=>> コンパネが公開後のOpenStack API
と同じものにアクセスする想定で構成
Endpoint L7:reverse proxy
Havana
Swift Proxy

1) OpenStack Havana アプリクラウド公開API
というわけで、2014/07/08にbetaと
してまずは公開しました
http://cloud.gmo.jp/docs
!
コンパネから使えるOpenStack APIを
公開した(client API)ので、少ないです
API: 31個

1) OpenStack Havana アプリクラウド公開API

2) 公開API Endpointのセキュリティ対策
Endpoint L7:reverse proxy
そして、API Endpointの部分
=> 公開なので、できればTCP 80 or 443で
!
!
!
SSL(https): reverse proxyにやらせる
(SSL Termination)
!
=> https(443 port)にしただけで、かなり変なアク
セスはなくなる

2) 公開API Endpoint: Reverse Proxyの選択
Reverse proxyにはたくさん種類
- nginx (ver. 1.6.0)
- HAProxy (ver. 1.5.0)
他:Varnish, apache mod_proxy, etc.
その中でもこの２つをなぜ選んだ?
!
=> 使い分け、適材適所、SSL可能

2) 公開API Endpoint: Reverse Proxy: nginx
nginx (ver. 1.6.0)
- lua, mrubyと組み合わせたりできる(要rebuild)
- 標準buildでもそこそこL7のロジックが書ける
(公式 rpm repositoryのbuild)
!
欠点: request自体をtemporary dirにキャッシュしてからバッ
クエンドに転送処理する
=> Glance image upload, Swiftなどのdata streamには向
かない
(ex: 5GBのSwiftのupload: nginxのサーバ上に5GBのファイ
ルが作成される)

2) 公開API Endpoint: Reverse Proxy: HAProxy
HAProxy (ver. 1.5.0)
- ver. 1.5.0からSSL可能
- OpenStackでの構成でもLBaaSでも使われるのでお馴染み
- そこそこ、ルールが書ける
- socket to socketで処理するので、nginxのような
temporary fileを作らない
=> Glance image upload, Swiftなどに適用可能
!
欠点: config fileはinclude機能がない、 -f オプションで複数
ファイル指定はできるみたいだけど
また、細かいロジックはnginxに負ける

2) 公開API Endpoint: Reverse Proxyの適用
下記のように適用しています
- nginx (ver. 1.6.0)
- keystone: host filter, URI filter(API), SSL Termination,
request limit filter (1MB, 3r/s)
- nova: host filter, URI filter(API), SSL Termination
- neutron: host filter, URI filter(API), SSL Termination
- cinder: host filter, URI filter(API), SSL Termination
- glance: host filter, URI filter(API: list images), SSL Termination
- HAProxy (ver. 1.5.0)
- Swift: host filter, URI filter, SSL Termination
!
!
!
!

2) 公開API Endpoint: Reverse Proxy: swift
HAProxy (ver. 1.5.0)適用
[root@ext-obj-reverse-proxy haproxy]# cat haproxy.cfg ¦ grep -v '#'
global
log 127.0.0.1 local0
maxconn 131072
user haproxy
group haproxy
daemon
stats socket /var/run/haproxy.sock mode 600 level admin
stats timeout 2m
tune.chksize 16384000
tune.bufsize 16384000
!
!
!
!
!
!

defaults
log global
mode http
option log-separate-errors
log-format [%pid] [%Ts.%ms] %ac/%fc/%bc/%bq/%sc/%sq/%rc %Tq/%Tw/%Tc/%Tr/
%Tt %tsc %ci:%cp %ﬁ:%fp %si:%sp %ft %sslc %sslv %{+Q}r %ST %b:%s "%CC"
"%hr""%CS" "%hs" req_size=%U resp_size=%B
option dontlognull
retries 3
option redispatch
maxconn 2000
contimeout 5000
clitimeout 50000
srvtimeout 50000
option forwardfor
!

listen hastats *:10080
mode http
maxconn 64
stats enable
stats uri /hastats
stats realm Haproxy statistics
stats auth system:hogehogepass
stats refresh 10s
!
frontend https_frontend
bind *:443 ssl crt /etc/ssl/certs/ast.app-sys.jp/ast.app-sys.jp-haproxy.pem
mode http
acl is_v1_api url_beg /v1
acl host_s3 hdr(host) -i swift3-r1nd1001.app-sys.jp
acl host_swift hdr(host) -i objectstore-r1nd1001.app-sys.jp
acl host_ote_s3 hdr(host) -i ote-swift3-r1nd1001.app-sys.jp
acl host_ote_swift hdr(host) -i ote-objectstore-r1nd1001.app-sys.jp
reqadd X-Forwarded-Proto: https

use_backend swift_proxy_server if is_v1_api
use_backend swift_proxy_server if host_s3
use_backend swift_proxy_server if host_swift
use_backend repos_server if host_repos
default_backend null_server
!
backend swift_proxy_server
mode http
balance leastconn
option httpchk HEAD /healthcheck HTTP/1.0
option forwardfor
server s1 10.199.199.91:8080 weight 10 check inter 2000
server s2 10.199.199.92:8080 weight 10 check inter 2000
!
backend null_server
mode http
option httpchk HEAD / HTTP/1.0
option forwardfor
server n1 127.0.0.1:18080 check inter 2000

!
こんな感じ
!

3) API versionの固定, JSON
API versionでURI filterで固定して通しています。
!
また、APIのrequest/responseフォーマットを
JSON(Default)で固定しちゃいました
=> XMLの処理を今は作ってない
=> http://developer.openstack.org/api-ref.html でも
XML見掛けなくなった
!
!
!
Format Accept Header Query Extension
ある場合
Default
JSON application/json .json Yes
XML application/xml .xml No

3) JSONのみだとマ…マズイ…(Ｔ∼;Ｔ)
Swift:
<< keystoneアクセスがXMLで実装されたクライアントソフト
が意外に多い
(ex: CloudBerry Explorer)
!
- S3 API module: swift3と同時に使われる場合があるので
XML必要な場合
- S3 clientとして先に作っていたclientのOpenStackへの
portingの場合、XMLのみの実装になっていることも
!
!

API公開での the Way of the OpenStack API Dragon は
betaなんで…
と言いつつも、動かないものがあったりとか
!
ex) python-cinderclient version違いで動いたり…
version. 1.0.7) 動く
version. 1.0.9) 動かない(Icehouse client)
=> endpoint のparseがうまく行ってない?
!
API Proxyでのパラメータ変換?
JSONの構成が違うのかな

ということで
- Validation check
- L7:Reverse Proxy(Private Cloudでも利用可能)
でAPI Endpointを防御して、運用しています
!
!
!
俺達の戦いはこれからだ

終劇

JOSUG2014 OpenStack 4th birthday party in Japan; the way of OpenStack API Dragon

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to JOSUG2014 OpenStack 4th birthday party in Japan; the way of OpenStack API Dragon

Similar to JOSUG2014 OpenStack 4th birthday party in Japan; the way of OpenStack API Dragon (20)

More from Naoto Gohko

More from Naoto Gohko (20)

JOSUG2014 OpenStack 4th birthday party in Japan; the way of OpenStack API Dragon