2017-06-01

AzureのサービスプリンシパルをAzure CLI2.0から発行する

AzureをTerraformやAnsibleから制御したかったり、Azure Container Services から Kubernetes のクラスをデプロイするときなんかに必要となるのが「サービスプリンシパル」。言葉が分かりづらいですが、SaaSでよくある「アプリケーションパスワード」みたいなものですね。

以前はこれの発行がわりと面倒だったのですが、Azure CLI 2.0 になって劇的に楽になりました。 Azure Cloud Shell から実行する前提で、ログイン等は省略してあります。

サービスプリンシパルの発行(CLI2.0対応版)

az account set --subscription "[サブスクリプションID]"
az ad sp create-for-rbac --name "[アプリケーション名]" --role Contributor

これだけです。

(追記： 2017/06/02)

「--role」オプションでRBACベースのロールを指定します。
例では、Ansible等を想定してリソースの読み書きなどが可能な「Contributor(＝共同作業者)」としてありますが、こちらを参考に適切なロールを指定して下さい。情報の取得のみであれば「Reader」あたりでも間に合いますね。

docs.microsoft.com

(追記以上)

こんな感じのレスポンスが返ってきます。パスワードはあとから照会できませんので控えておきましょう。パスワード以外の項目は、ポータルの「Azure Active Directory → アプリの登録」から確認できます。

{
    "appId": "[アプリケーションID]",
    "displayName": "[表示名]",
    "name": "[アプリケーションID/URI]",
    "password": "[パスワード]",
    "tenant": "[テナントID]"
}

発行したサービスプリンシパルでCLIからログインしてみる

az login --service-principal --username "[アプリケーションID/URI]" --password "[パスワード]" --tenant "[テナントID]"

公式のドキュメントはこちらからどうぞ。

docs.microsoft.com

(追記： 2017/06/01)

パスワードが分からなくなった場合は、ポータルからキーを新たに発行すれば良さそうです。手順はこのあたりから。

docs.microsoft.com

複数のサブスクリプションを同じディレクトリ上で運用している場合、カレントのサブスクリプションにIAM(RBAC)権限が付与されるようです。思ったのと違うところに権限が付いた場合は、ポータル等から変更しておきましょう。

そもそもサービスプリンシパルって何？という説明はこちらの公式ドキュメントをどうぞ。

docs.microsoft.com

(追記： 2017/10/26)

Terraform が Azure CLI認証に対応したそうで、そもそもサービスプリンシパル無しで走らせられるようになりました。

TerraformをAzure CLI認証で使う

2017-05-31

Azure仮想マシン用ディスクが最大4TBまで拡張されたようです

build 2017 の発表に続いてリリースが出ました。

azure.microsoft.com

さっそく検証記事が上がっていました。

qiita.com

記事がPowerShellだったので、CLIでもやってみました。 …といっても、単にCLIからManaged Diskを作っているだけですね。 Azure Cloud Shell でできるので楽ですね。

アナウンスには「West US Central Region」と書いてありますが、Japan Eastでも大きなディスクを作るだけならできました。仮想マシンにアタッチするところでエラーになるようですね。

CLIからディスクを作成する

$ az disk create --resource-group [リソースグループ名] --name [ディスク名] --sku [Standard_LRS or Premium_LRS] --location [リージョン] --size-gb [ディスクサイズ]

ディスクサイズの最大は、リリースにもあるように4,095GBです。 –sku は、Premium Disk(SSD相当)の場合は「Premium_LRS」、Standard Disk(HDD相当)の場合は「Standard_LRS」です。

既存のディスクのサイズを変更する

$ az disk update --resource-group [リソースグループ名] --name [ディスク名] --size-gb [ディスクサイズ]

2017-04-28

Azure Lシリーズ仮想マシンのストレージベンチマーク

3月に登場したLシリーズの仮想マシンですが、低遅延なワークロード向けに最適化されたストレージが接続されているということで、実際にベンチマークしてみました。比較対象は、L4s(4core, 32GBメモリ)とDS12v2(4 core, 28GBメモリ)、いずれも東日本です。

azure.microsoft.com

			#1	#2	#3	#4	#5	average
Resource Disk	simple	DS12v2	265,240	295,247	307,868	312,623	314,806	299,157
		L4s	260,160	294,480	300,374	315,354	317,482	297,570
	advanced	DS12v2	4,902	105,021	150,353	151,570	151,631	112,695
		L4s	15,867	231,738	250,393	251,296	256,432	201,145
Persistent Disk	simple	DS12v2	275,935	303,187	316,342	326,228	327,368	309,812
		L4s	277,109	306,821	319,787	324,359	329,075	311,430
	advanced	DS12v2	73,683	84,010	89,240	86,708	84,707	83,670
		L4s	177,048	199,667	251,055	252,527	250,629	226,185

			#1 (ms)	#2 (ms)	#3 (ms)	#4 (ms)	#5 (ms)	average
Resource Disk	simple	DS12v2	0.000	0.010	0.010	0.010	0.020	0.010
		L4s	0.000	0.010	0.010	0.010	0.020	0.010
	advanced	DS12v2	0.200	0.020	0.020	0.030	0.030	0.060
		L4s	0.060	0.010	0.010	0.020	0.020	0.024
Persistent Disk	simple	DS12v2	0.000	0.010	0.010	0.010	0.010	0.008
		L4s	0.000	0.010	0.010	0.010	0.010	0.008
	advanced	DS12v2	0.010	0.020	0.030	0.050	0.060	0.034
		L4s	0.010	0.010	0.010	0.020	0.020	0.014

Windows上でのベンチマーク

ついでにWindowsでも計測しました。CrystalDiskMarkでさらっと。
Windowsの場合はCドライブが永続的なディスク、Dドライブが揮発する方ですね。 Linuxと同じ傾向なので、やはりLシリーズのストレージは早いということになりそうです。

Cドライブでの比較

▼DS12v2
f:id:yhara90:20170428213126p:plain

▼L4s
f:id:yhara90:20170428213135p:plain

Dドライブでの比較

▼DS12v2
f:id:yhara90:20170428213144p:plain

▼L4s
f:id:yhara90:20170428213151p:plain

2017-04-27

BASIC認証の代わりにOTPのトークンで認証してみる

せっかくなので、BASIC認証の代わりにOTPのトークンで認証できるように設定してみましょう。

昨日の続きと言えば続き。

asazure.hatenablog.jp

前準備

$ sudo yum install -y httpd httpd-devel
$ sudo yum install -y openssl-devel
$ git clone https://github.com/archiecobbs/mod-authn-otp
$ cd mod-authn-otp
$ ./autogen.sh -c
$ make
$ sudo make install

Apacheにモジュール読み込み

$ sudo vi /etc/httpd/conf.modules.d/00-authn_otp.conf
$ sudo diff /etc/httpd/conf.modules.d/00-authn_otp.conf /etc/httpd/conf.modules.d/00-authn_otp.conf.bak
1,2d0
< LoadModule authn_otp_module   modules/mod_authn_otp.so
$ service httpd configtest
$ sudo systemctl restart httpd

ユーザーファイルを作る

$ vi ~/create_otp_userfile_sh
$ cat ~/create_otp_userfile_sh
#!/bin/bash -e
user=${1:?Usage: $0 username}
issuer=${2:-your_company_name}
secret=$(cat /dev/urandom | tr -dc 'a-z0-9' | fold -w 15 | head -n 1)
secret_base16=$(python -c "import base64; print base64.b16encode('${secret}')")
secret_base32=$(python -c "import base64; print base64.b32encode('${secret}')")
otpauth_uri="otpauth://totp/${issuer}:${user}?secret=${secret_base32}&issuer=${issuer}"
otpauth_uri=$(python -c "import urllib; print urllib.quote('${otpauth_uri}')")
qrcode_url="https://chart.googleapis.com/chart?chs=300x300&cht=qr&chl=${otpauth_uri}"

file="/var/www/otp/users"
if [ ! -f "${file}" ]; then
  [ -d $(dirname "$file") ] || mkdir -p $(dirname "$file")
  touch ${file}
  chown -R apache:apache $(dirname "$file")
fi
[ -w "${file}" ] || (echo "${file}: Permission denied" && exit 1)

count=$(awk "\$2 ~ /^$user}\$/" ${file} | wc -l)
if [ $count -le 0 ]; then
  echo "HOTP/T30 $(printf '%-12s' $user) - ${secret_base16}" >> ${file}
  echo "$qrcode_url"
else
  echo "User '$user' already exists"
fi
$ sudo ./create_otp_userfile_sh haray2 isaotestweb

出力されたURLにアクセスして、表示されたQRコードをアプリでスキャンして登録。

※ユーザーファイルの生成はこちらからスクリプトを借りました。

qiita.com

「引数にUsernameを指定して実行すると、必要な項目を埋めた行が /var/www/otp/users に追記され、標準出力にGoogle Authenticator登録用のQRコードが表示されるURLが出力されます。」という優しい仕様。ありがとうございます。

BASIC認証の設定

$ sudo vi /etc/httpd/conf/httpd.conf
$ diff /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf.bak
159,170d158
< <Location />
<     AuthType Basic
<     AuthName "Mamoru OTP"
<     AuthBasicProvider OTP
<     Require valid-user
<     OTPAuthUsersFile /var/www/otp/users
<     OTPAuthMaxLinger 3600
<     OTPAuthMaxOTPFailure 20
<     OTPAuthPINAuthProvider file
<     OTPAuthLogoutOnIPChange On
< </Location>
$ service httpd configtest
$ sudo systemctl restart httpd

これで設定終わりです。ブラウザからアクセスするとBASIC認証のダイアログが表示されるので、「ユーザー名」にはスクリプトで作成したユーザー名を、「パスワード」にはアプリに表示されているOTPを、それぞれ入力します。

f:id:yhara90:20170427211508p:plain

2017-04-27

CentOSの認証にTOTPを使う

個人的なメモを残しておきます。

前準備

$ sudo yum -y groupinstall "Development Tools"
$ sudo yum -y install pam-devel

Google Authenticatorのpamモジュールをインストールする

github.com

$ git clone https://github.com/google/google-authenticator-libpam.git
$ cd google-authenticator-libpam/
$ ./bootstrap.sh
$ ./configure
$ make
$ sudo make install

sshdとpamの設定

$ sudo cp /usr/local/lib/security/pam_google_authenticator.so /usr/lib64/security/
$ sudo cp -p /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
$ sudo vi /etc/ssh/sshd_config
$ sudo diff /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
82,83c82,83
< ChallengeResponseAuthentication yes
< #ChallengeResponseAuthentication no
---
> #ChallengeResponseAuthentication yes
> ChallengeResponseAuthentication no
$ sudo sshd -t
$ sudo systemctl restart sshd
$ sudo vi /etc/pam.d/google-auth
$ cat /etc/pam.d/google-auth
#%PAM-1.0
auth required pam_env.so
auth sufficient pam_google_authenticator.so try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so
$ sudo cp -p /etc/pam.d/sshd /etc/pam.d/sshd.bak
$ sudo vi /etc/pam.d/sshd
$ sudo diff /etc/pam.d/sshd /etc/pam.d/sshd.bak
3c3
< #auth       substack     password-auth
---
> auth       substack     password-auth
21,22d20
< auth substack google-auth

OTPの設定(このときにQRコードも表示されるのでアプリを設定する)

$ google-authenticator

sudoにも適用してみよう

$ sudo cp /etc/pam.d/sudo /etc/pam.d/sudo.bak
$ sudo vi /etc/pam.d/sudo
$ diff /etc/pam.d/sudo /etc/pam.d/sudo.bak
2d1
< auth       substack     google-auth

2017-04-22

Azureの東日本から近い海外リージョンは？

今だと香港より韓国Regionのほうが近いんかな
— こすもす.えび (@kosmosebi) 2017年4月22日

「Azureの日本リージョンに何かあったときに東アジアに逃がす」という話の流れから、「香港より韓国の方が近いのでは？」という指摘を見かけたので実測してみました。

各リージョンにCentOSのVMを立てて、東日本のVMからnpingを100回ずつ飛ばしました。

sudo nping --tcp -c 100 -p 22 (宛先IPアドレス)

▼結果

東日本(japaneast)
Max rtt: 9.026ms | Min rtt: 0.629ms | Avg rtt: 1.179ms

西日本(japanwest)
Max rtt: 15.846ms | Min rtt: 8.869ms | Avg rtt: 9.298ms

東アジア(eastasia)
Max rtt: 55.422ms | Min rtt: 51.305ms | Avg rtt: 51.707ms

韓国中部(koreacentral)
Max rtt: 36.775ms | Min rtt: 34.438ms | Avg rtt: 34.722ms

韓国南部(koreasouth)
Max rtt: 44.547ms | Min rtt: 40.182ms | Avg rtt: 40.558ms

ということで、今のところ韓国中部(koreacentral)が近いようです。

(追記)

VM消す前に /proc/cpuinfo を見てみたら、韓国リージョンの方がCPUがちょっと新しくて早いようです。やっぱり新しいDCいいですね。

Intel(R) Xeon(R) CPU E5-2673 v3 @ 2.40GHz

東日本、西日本、東アジアはこんな感じ。

Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz

2017-03-25

SQL Database のアップデート

Announcing Azure SQL Database Premium RS, 4TB storage options, and enhanced portal experience | Blog | Microsoft Azure azure.microsoft.com

こちらも少し古くなってしまいましたが、SQL Databaseについて2件。
いずれもパブリックプレビューです。

1つめは価格階層の新設。
「Premium RS」が設けられたようで、Premiumから性能は変えずに信頼性を落として(冗長度を下げて)安くしたということのようです。ストレージの最大容量も500GBまで、となっていますね。障害発生時には最大5分間分巻き戻る可能性があるということなので、テスト用や検証環境用にちょうど良さそうですね。本番用でも、アクティブgeoレプリケーションを設定しておけば使えるような気はします。

2つめは、P11とP15でストレージの4TBオプションが追加されました。
追加費用無しで拡張できます。おそらくプレビューゆえのようですが、現時点では次のような制約があります。

いったん4TBに設定するとダウングレードできない
容量縮小できない
アクティブgeoレプリケーションもP11かP15が必要
Elastic Poolに追加できない

これに合わせてだと思いますが、ポータル上からスケール操作をする際のUIも変わりました。価格階層(StandardとかPremiumとか)をタブで選んで、DTUとストレージサイズをスライダーで指定する形になっています。

浅草橋青空市場

Microsoft Azure のニュースや情報を中心にあれこれと

AzureのサービスプリンシパルをAzure CLI2.0から発行する

サービスプリンシパルの発行(CLI2.0対応版)

発行したサービスプリンシパルでCLIからログインしてみる

Azure仮想マシン用ディスクが最大4TBまで拡張されたようです

CLIからディスクを作成する

既存のディスクのサイズを変更する

Azure Lシリーズ仮想マシンのストレージベンチマーク

Linux上でのベンチマーク

準備

計測用ディレクトリとファイルの作成

設定ファイルの作成

ベンチマークの実行(simpleモード： readのみ)

ベンチマークの実行(advancedモード： read/write)

結果のまとめ(IOPS)

結果のまとめ(Latency)

Windows上でのベンチマーク

Cドライブでの比較

Dドライブでの比較

BASIC認証の代わりにOTPのトークンで認証してみる

前準備

Apacheにモジュール読み込み

ユーザーファイルを作る

BASIC認証の設定

CentOSの認証にTOTPを使う

sudoにも適用してみよう

Azureの東日本から近い海外リージョンは？

SQL Database のアップデート