Atuh0で多要素認証(MFA)を使う

 
カテゴリー SaaS   タグ

Multi-factor Authentication

Multi-factor Authenticationを有効化(One-time Password)

Security -> Multi-factor Authenticationで有効化。

Auth0 MFA width=640

One-time PasswordはGoogle Authenticatorなどのアプリケーションを使用する。
多要素認証(MFA)はRuleを使用して適用する条件を設定できるが、ここではテストのために、Require Multi-factor AuthAlwaysにして常に使用するように設定する。

Auth0 MFA width=640

Continueをクリック。

Auth0 MFA width=640

多要素認証のテスト

QRコードが表示されるので、Google Authenticatorで読み込む。

Auth0 MFA width=640

リカバリーコードが表示されるので保存しておく。

Auth0 MFA width=640

多要素認証(MFA)の登録完了。

Auth0 MFA width=640

ログイン。

Auth0 MFA width=640

複数の要素を有効化する(One-time Password + Email)

もうひとつの要素としてEmailを有効化。Email is not available as an authentication factor when using the Classic Universal Login experienceという警告が表示されており、デフォルトのClassic Universla Loginでは利用できない。

Auth0 MFA width=640

Branding -> Universla LoginをClassicからNewに変更する。

Auth0 MFA width=640

ログイン画面が赤基調から青基調に変わっている。

Auth0 MFA width=640

GitHubアカウントでログイン。

Auth0 MFA width=640

One-time Passwordの登録が優先されている。

Auth0 MFA width=640

ログイン。

Auth0 MFA width=640

改めて再ログインを試みる。登録したOne-time Passwordの入力を促されるが、最下部のTry another methodを選択。

Auth0 MFA width=640

Emailを選択。

Auth0 MFA width=640

E-Mailアドレスにコードが送られ、コードの入力画面になる。

Auth0 MFA width=640

コメント・シェア

Atuh0でソーシャルログインする

 
カテゴリー SaaS   タグ

Social Connections

Auth0はさまざまなソーシャルログイン連携をSocial Connectionsとして提供している。
これを有効化するだけで、ソーシャルログイン機能を利用することができる。

Social Connectionsの有効化

Authentication -> Socialから連携するサービスをONにする。デフォルトでGoogleが有効になっている。

Auth0 SocialConnections width=640

連携先としてGitHubを追加する。GitHubを選択すると、連携に関する設定が表示される。連携のためには各プロバイダー(Social Identity Providers)のクライアントID(Client ID)とシークレット(Client Secret)が必要だが、テストの場合指定しなくても使用することができる。

Auth0 SocialConnections width=640

Attributesとして取得する属性の値を選択する。

Auth0 SocialConnections width=640

ここではEmail Addressread userを選択した。

Auth0 SocialConnections width=640

Social Connectionsはアプリケーション毎に有効化するかどうかを選択できる。
デフォルトのDefault Appとチュートリアルで作成したtestappが表示されている。

Auth0 SocialConnections width=640

ソーシャルログインのテスト1

Default Appからログインする。画面にSign in with GitHubが現れている。

Auth0 SocialConnections width=640

Auth0自身にGitHubアカウントでログインしているので、認証プロセスは省略され、Auth0に対する認可の確認画面が表示される。Email addresses (read-only)profile information (read-only)を許可するかどうかが問われる。

Auth0 SocialConnections width=640

Authrorize auth0を選択するとログイン後のページが表示される。

Auth0 SocialConnections width=640

ソーシャルログインのテスト2

testappからログインする。

Auth0 SocialConnections width=640

同じGitHubユーザで一度ログインしているのでAuth0に対する認可画面はない。

Auth0 SocialConnections width=640

アプリに対する認可の画面が表示される。

Auth0 SocialConnections width=640

認可するとログイン後のページが表示される。

Auth0 SocialConnections width=640

Client IDとClient Secretを取得する

ログインできることを確認できたので、GitHubのクライアントID(Client ID)とシークレット(Client Secret)を取得する。

Client IDとClient Secretの発行で必要になるドメイン名を確認する。Settings -> Custom Domainsで確認。

Auth0 SocialConnections width=640

GitHubのSettings -> Developer settingsOAuth AppsRegister a new application

Auth0 SocialConnections width=640

Auth0 SocialConnections width=640

指定の情報を入力してRegister applicationで、Client IDとClient Secretを発行。

  • Homepage URLhttps://YOUR_DOMAIN
  • Authorization callback URLhttps://YOUR_DOMAIN/login/callback

Auth0 SocialConnections width=640

登録されたOAuth appの画面からClient IDとClient Secretを取得することができる。この画面上でこの連携を経由して連携されたユーザの数が表示されている。このGitHubアカウント以外のGitHubアカウントも連携することができる。

Auth0 SocialConnections width=640

連携時の認可画面で表示するアイコンを設定することができる。

Auth0 SocialConnections width=640

Auth0 SocialConnections width=640

Auth0 SocialConnections width=640

Client IDとClient SecretをAuth0に登録する

Client IDとClient Secretを設定していない場合、!が表示されている。

Auth0 SocialConnections width=640

Client IDとClient Secretを設定し、追加でpublic_repoを連携する。

Auth0 SocialConnections width=640

!が表示されなくなる。

Auth0 SocialConnections width=640

ソーシャルログインのテスト3

Default Appから再度ログインする。一度ログイン済のため、ログイン画面は表示されず、先ほど追加したpublic_repoを含めた認可の画面が表示される。Auth0のアイコンはGitHubで設定したアイコンに変わっている。

Auth0 SocialConnections width=640

認可後は同じ。

Auth0 SocialConnections width=640

ソーシャルログインのテスト4

testappからログインする。

Auth0 SocialConnections width=640

こんどは新しいGitHubアカウントでログインする。

Auth0 SocialConnections width=640

設定したアイコンが表示されている。

Auth0 SocialConnections width=640

GitHubで認証すると、Auth0に対する認可画面が表示される。

Auth0 SocialConnections width=640

アプリに対する認可の画面が表示される。

Auth0 SocialConnections width=640

新しいアカウントでログインしたため2アカウントが表示されている。

Auth0 SocialConnections width=640

コメント・シェア

Auth0のDjangoチュートリアル

 
カテゴリー Python SaaS Tutorial   タグ

チュートリアルの開始

Getting StartedからIntegrate Auth0 into your applicationへ。Create Applicationからチュートリアルを開始。

Auth0 Django Tutorial width=640

testappとして、Regular Web Applicationを選択。

Auth0 Django Tutorial width=640

Django選択。

Auth0 Django Tutorial width=640

作成されたアプリケーションのページ。

Auth0 Django Tutorial width=640

GitHubからサンプルをfork。

Auth0 Django Tutorial width=640

python-social-auth/social-app-django

Python Social Auth is an easy to setup social authentication/registration mechanism with support for several frameworks and auth providers.
This is the Django component of the python-social-auth ecosystem, it implements the needed functionality to integrate social-auth-core in a Django based project.

Djangoプロジェクトにソーシャル認証を組み込み、OAuthによる認証認可を行うことができる。サンプルアプリ側ではこれを利用してauth0の認証を行っている。

Get Your Application Keys

When you signed up for Auth0, a new application was created for you, or you could have created a new one.

新しアプリケーションを作成すると、以下が発行されるので、Settingsから取得する。

  • Domain
  • Client ID
  • Client Secret

Configure Callback URLs

A callback URL is a URL in your application where Auth0 redirects the user after they have authenticated.
The callback URL for your app must be whitelisted in the Allowed Callback URLs field in your Application Settings. If this field is not set, users will be unable to log in to the application and will get an error.

認証後のリダイレクト先。Settingsでホワイトリスト登録する必要がある。

Configure Logout URLs

A logout URL is a URL in your application that Auth0 can return to after the user has been logged out of the authorization server. This is specified in the returnTo query parameter.
The logout URL for your app must be whitelisted in the Allowed Logout URLs field in your Application Settings. If this field is not set, users will be unable to log out from the application and will get an error.

ログアウト後のリダイレクト先。Settingsでホワイトリスト登録する必要がある。

Django Settings

サンプルアプリはほぼ設定済で、環境変数のみ.envに設定すればOK。

1
2
3
AUTH0_CLIENT_ID={CLIENT_ID}
AUTH0_DOMAIN={DOMAIN}
AUTH0_CLIENT_SECRET={CLIENT_SECRET}

Install the Dependencies

pip install -r requirements.txtでインストール。チュートリアルのDockerイメージはビルドの中でこれらもインストールされる。

1
2
3
4
django~=2.1
social-auth-app-django~=3.1
python-jose~=3.0
python-dotenv~=0.9

以下のDockerfileが用意されており、サンプルアプリを利用可能な状態になっている。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
FROM python:3.6

WORKDIR /home/app

#If we add the requirements and install dependencies first, docker can use cache if requirements don't change
ADD requirements.txt /home/app
RUN pip install --no-cache-dir -r requirements.txt

ADD . /home/app

# Migrate the database
RUN python manage.py migrate

CMD python manage.py runserver 0.0.0.0:3000

EXPOSE 3000

docker-composeで操作したいので、docker-compose.ymlを作成する。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
version: '3'

services:
auth0:
container_name: auth0-django
build:
context: .
dockerfile: Dockerfile
tty: true
ports:
- "3000:3000"
environment:
AUTH0_CLIENT_ID: ${AUTH0_CLIENT_ID}
AUTH0_DOMAIN: ${AUTH0_DOMAIN}
AUTH0_CLIENT_SECRET: ${AUTH0_CLIENT_SECRET}
1
2
3
$ docker-compose up -d
Creating network "01-login_default" with the default driver
Creating auth0-django ... done

サンプルアプリへのログイン

【GET /】http://localhost:3000にアクセス。

Auth0 Django Tutorial width=640

【GET /login/auth0】auth0のユニバーサルログインページに転送され、ログインすると…

Auth0 Django Tutorial width=640

【GET /dashboard】属性情報を表示されるアプリに転送され、渡されたユーザデータが表示される。

Auth0 Django Tutorial width=640

アプリサイドのログ

この時のサーバログは以下の内容

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Creating network "01-login_default" with the default driver
Creating auth0-django ... done
Attaching to auth0-django
auth0-django | Watching for file changes with StatReloader
auth0-django | Performing system checks...
auth0-django |
auth0-django | System check identified no issues (0 silenced).
auth0-django | June 05, 2020 - 11:14:04
auth0-django | Django version 2.2.13, using settings 'webappexample.settings'
auth0-django | Starting development server at http://0.0.0.0:3000/
auth0-django | Quit the server with CONTROL-C.
auth0-django | [05/Jun/2020 11:14:13] "GET / HTTP/1.1" 200 899
auth0-django | [05/Jun/2020 11:14:18] "GET /login/auth0 HTTP/1.1" 302 0
auth0-django | [05/Jun/2020 11:14:29] "GET /complete/auth0?code=kOYVXXXXXMVD8Sl&state=s0l9XXXXXXXXXXXXbPBNzeaA HTTP/1.1" 302 0
auth0-django | [05/Jun/2020 11:14:29] "GET /dashboard HTTP/1.1" 200 1371

Auth0サイドのログ

Auth0のログ

Auth0 Django Tutorial width=640

Type:Success ExchangeAuthorization Code for Access TokenというDescriptionが付与されており、前述のGET /complete/auth0?code=で指定している認可コードを取得している。

内容はにRawContextDataとしてJSON形式で確認できる。

Rawでは以下が表示され、アプリからのリクエスト情報が記録されている。
User-Agentはアプリであり、内部的に使用されるPython RequestsのUser-Agentが記録されている。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
{
"date": "2020-06-05T11:14:28.994Z",
"type": "seacft",
"description": "Authorization Code for Access Token",
"connection_id": "",
"client_id": "orEXXXXXXXXXXXXXXXXXIFWsMF",
"client_name": "testapp",
"ip": "XXX.XXX.XXX.XXX",
"user_agent": "Python Requests 2.23.0 / Other 0.0.0",
"details": {
"code": "*************8Sl"
},
"hostname": "devXXXXXXXXXXXXX.auth0.com",
"user_id": "auth0|XXXXXXXXXXXXXXXXXXXXXXXXXXXX",
"user_name": "XXXXXXXXXXXXX@xxxxxxx.xxxxxx",
"log_id": "9002020XXXXXXXXXXXXXXXXXXXXXXXXXXXX08290750546",
"_id": "9002020XXXXXXXXXXXXXXXXXXXXXXXXXXXX08290750546",
"isMobile": false
}

ContextDataにはdetailsの内容が入っている。

1
2
3
{
"code": "*************8Sl"
}

Type:Success Loginはクライアントのログイン認証の成功を示している。利用者からの認証であり、User-Agentは利用者のブラウザの情報が記録されている。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
{
"date": "2020-06-05T11:14:28.363Z",
"type": "s",
"connection": "Username-Password-Authentication",
"connection_id": "con_XXXXXXXXXXXXXXv7",
"client_id": "orEXXXXXXXXXXXXXXXXXIFWsMF",
"client_name": "testapp",
"ip": "XXX.XXX.XXX.XXX",
"user_agent": "Chrome 83.0.4103 / Windows 10.0.0",
"details": {
"prompts": [
{
"name": "lock-password-authenticate",
"initiatedAt": 1591355668017,
"completedAt": 1591355668324,
"connection": "Username-Password-Authentication",
"connection_id": "con_XXXXXXXXXXXXXXv7",
"strategy": "auth0",
"identity": "5edXXXXXXXXXXXXXXXcf9",
"stats": {
"loginsCount": 6
},
"session_user": "5edaXXXXXXXXXXXXXXX2e9d36",
"elapsedTime": 307
},
{
"name": "login",
"flow": "login",
"initiatedAt": 1591355658531,
"completedAt": 1591355668329,
"user_id": "auth0|XXXXXXXXXXXXXXX6ecf9",
"user_name": "XXXXXXXXXXXXX@xxxxxxx.xxxxxx",
"elapsedTime": 9798
}
],
"initiatedAt": 1591355658530,
"completedAt": 1591355668362,
"elapsedTime": 9832,
"session_id": "0FetBO15mf0vQs_YfMoZTQdeItwyJKdH",
"stats": {
"loginsCount": 6
}
},
"hostname": "dev-e6hrtsp8.auth0.com",
"user_id": "auth0|5ed5fb1b424ed40bee36ecf9",
"user_name": "XXXXXXXXXXXXX@xxxxxxx.xxxxxx",
"strategy": "auth0",
"strategy_type": "database",
"log_id": "900202XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX7572418",
"_id": "900202XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX7572418",
"isMobile": false,
"description": "Successful login"
}

コメント・シェア

認証プラットフォームAuth0

 
カテゴリー SaaS   タグ

Auth0

IDaaS(Identity as a Service)

STANDARD PROTOCOLS

SAML, OpenID Connect, JSON Web Token, OAuth 2.0, OAuth 1.0a, WS­-Federation and OpenID.

標準的なプロトコルに対応。

  • SAML … XMLベースの標準シングルサイオン形式のフレームワーク
  • OpenID Connect … 認証・認可プロトコル、属性情報を取得する機能も含む
  • JWT(JSON Web Token) … 安全にクレームを表現するための方式
  • OAuth 1.0a/2.0 … 認可プロトコル
  • WS-Federation … SAMLライクなクレームベース認証仕様(Microsoft, IBM, Novel)
  • OpenID … 認証プロトコル(認可はしない)

MULTIFACTOR AUTHENTICATION

Typically, Multifactor Authentication requires a combination of something the user knows, something the user has, and sometimes something the user is.

  • Knowledge factors, such as passwords, PINs, or secret questions.
  • Possesion factors, such as an access card, phone, or hardware key.
  • Inherence factors, which are biometric information, such as the user’s fingerprint, face, or voice.

多要素認証はユーザが「知っていること」「持っていること」「自身であること」を組み合わせて認証する。

  • 知っていること … パスワード、PIN、秘密の質問
  • 持っていること … アクセスカード、ハードウェアキー、電話
  • 自身であること … 指紋、顔、声などの生体情報

「記憶」「所持」「バイオメトリクス」であったり「SYK:Something You Know」「SYH:Something You Have」「SYA:Something You Are」など、表現はいろいろあるが、認証の3要素として基本。
多要素認証はこれら異なる要素を用いる認証方式のことで、同じ要素の認証を複数組み合わせる場合は多段階認証(Multi Step Authentication)である。

ADAPTIVE CONTEXT-AWARE MULTIFACTOR
Adaptative Context-aware Multifactor allows you to enforce MFA or additional layers of authentication based on different conditions such as: geographic location, time of day/week, type of network, custom domains or certain IPs, or any arbitrary condition that can be expressed in code on the Auth0 platform.

地理的位置、時刻、ネットワークの種類、カスタムドメイン、特定のIPなどの条件でMFAや追加の認証レイヤーを適用することができる。

いわゆるステップアップ認証やリスクベース認証を実現する機能で、Ruleによって多要素認証を適用する条件を記述する。

CUSTOM MFA PROVIDERS
If you are using a different MFA provider or want to build your own, you can use the redirect protocol in Auth0.

To use a custom MFA provider, you can interrupt the authentication transaction and redirect the user to an arbitrary URL where an additional authentication factor can happen. After this completes (successfully or not), the transaction can then resume in Auth0 for further processing.

途中で別のMFAプロバイダーにredirectして処理できる。リダイレクト先の処理が完了すると成功か否かにかかわらずAuth0側での処理が再開される。

SINGLE SIGN ON

You can enable Single Sign On for your corporate applications like Salesforce, Dropbox, Slack, and much more! With Auth0, this is just a few clicks away. Auth0 provides out-of-the-box support for more than 15 cloud applications.
These applications are: Microsoft Azure Active Directory, Box, CloudBees, Concur, Dropbox, Microsoft Dynamics CRM, Adobe Echosign, Egnyte, New Relic, Office 365, Salesforce, Sharepoint, Slack, Springcm, Zendesk, and Zoom.

標準で多くのクラウドアプリにシングルサインオンできる。

SINGLE LOG OUT
Single Log Out is the inverse process of Single Sign On, once you log out of one of the configured applications, your session will end in all of them. You will save time, and will never forget your sessions opened again.

シングルサインアウトもできる。

LAST MILE INTEGRATION THROUGH JAVASCRIPT
If you need further customization, you can always use Auth0’s rules engine. Rules are JavaScript code snippets that run in Auth0 and empowers you to control and customize any stage of the authentication and authorization pipeline. We know that every case is completely different!
See the Rules documentation for more information.

JavaScriptでRuleを記述し、認証パイプラインを構築できる。

SOCIAL LOGIN

SOCIAL PROVIDERS WITH AUTH0
Auth0 supports 30+ social providers: Facebook, Twitter, Google, Yahoo, Windows Live, LinkedIn, GitHub, PayPal, Amazon, vKontakte, Yandex, 37signals, Box, Salesforce, Salesforce (sandbox), Salesforce Community, Fitbit, Baidu, RenRen, Weibo, AOL, Shopify, WordPress, Dwolla, miiCard, Yammer, SoundCloud, Instagram, The City, The City (sandbox), Planning Center, Evernote, Evernote (sandbox), and Exact. Additionally, you can add any OAuth2 Authorization Server you need.

標準で多くのソーシャルプロバイダーをサポート。さらにOAuth2の認証サーバを追加することができる。

Every provider has its own profile properties, required headers, and response format, and some use OAuth1 (Twitter) while others use OAuth2. Auth0 simplifies this for you, encapsulating the differences, and unifying the way to call providers and the information retrieved from all of them.

各プロバイダーが持つ独自のプロファイルプロパティやヘッダー情報、応答フォーマット、プロトコルの違い(OAuth1, OAuth2)を吸収する。

料金

Get Auth0 for free with up to 7,000 active users, unlimited logins. No credit card required.

7000アクティブユーザまで無料。登録ユーザ数ではなくアクティブユーザである点は素晴らしい。

サインアップ

Auth0 width=640

Auth0 width=640

Auth0 width=640

ソーシャルログインに対応している。ここではGitHubアカウントを使用する。

Auth0 width=640

Auth0 width=640

Auth0 width=640

Auth0 width=640

REGIONを選択。後から変更することはできない。

Auth0 width=640

Auth0 width=640

Auth0 width=640

使ってみる

Try your Login boxからログインを試すことができる。Try it outを押すとログイン画面が表示される。

Auth0 width=640

Auth0 width=640

Auth0 width=640

Auth0 width=640

コメント・シェア

DooD(Docker outside of Docker)

起動したDockerコンテナの中で、dockerを利用する方法の1つで、Dockerデーモンはホスト側にバイパスしてDockerコンテナを動作させる方法。dockerやdocker-composeの操作をdockerコンテナ内で行っていても、コンテナから起動したコンテナはホスト側で動いている。

コンテナにDockerをインストール

起動させるコンテナ側でdockerやdocker-composeのCUIを使用するので、必要パッケージをインストール。

1
2
apt-get install -y --no-install-recommends docker.io
apt-get install -y --no-install-recommends docker-compose

Dockerサーバの共有

Dockerのホスト側へは/var/run/docker.sockをバイパスすることでアクセス。
docker-comopose.yml/var/run/docker.sockをvolumeとしてマウント。

1
2
volumes:
- /var/run/docker.sock:/var/run/docker.sock

DooDで起動したDockerでVolumeマウント

ボリュームマウントは注意が必要。
Dockerデーモンが動作する親ホスト、そこから起動した子コンテナ、DooDでさらに起動する孫コンテナとした場合、孫コンテナが行うボリュームマウントは親ホストのボリュームで、子コンテナのボリュームではない。

子コンテナが親ホストのボリュームをマウントする場合

親ホスト側でdocker-compose.ymlを記述する場合、以下のような相対パスで指定できる。
これはdocker-composeを起動しているのは親ホストで、相対パスは自身の認識する相対パスだから可能。

1
2
volumes:
- .:/work/:rw

孫コンテナが親ホストのボリュームをマウントする場合

子コンテナで起動するdocker-compose.ymlでは相対パスで記述することはできない。
記述してもエラーにはならないが、空のディレクトリとしてマウントされるだけだ。DooDの仕組みから考えれば直感的に理解できる。

1
2
volumes:
- /host/full/path:/work/:rw

どちらでも起動できるようにするには

docker-compose.ymlは動かす環境ごとに記述したくないので、docker-compose.yml内で、環境変数を使って環境ごとにボリューム先を変える。

1
2
volumes:
- ${WORK_DIR}:/work/:rw

親ホストで実行する場合は.envファイルでWORK_DIR=.を指定する。
子コンテナから起動する場合は親ホストのフルパスを環境変数としてWORK_DIRを実行ホストの絶対パスで指定する。

コメント・シェア

DockerでCIFSマウントする

 
カテゴリー Container Git   タグ

cifs-utilsのインストール

1
apt-get install -y --no-install-recommends cifs-utils

cifs-utilsがない場合はmount: /mnt: cannot mount //xxx.xxx.xxx.xxx/xxxxxx read-only.となる。

コンテナからcifs-utilsでマウントする例

ENTRYPOINTでCIFSをマウントするにはcifs-utilsをインストールして、mount -t cifsでマウントする。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
#
# CIFS Mount
#
if [ -z ${CIFS_USER} ] || [ -z ${CIFS_PASS} ] || [ -z ${CIFS_HOST} ] || [ -z ${CIFS_REMOTE_PATH} ] || [ -z ${CIFS_LOCAL_PATH} ]; then
echo "need export CIFS_XXXXXX"
exit 1
fi

mkdir -p ${CIFS_LOCAL_PATH}
mount -t cifs -o username=${CIFS_USER},password=${CIFS_PASS} //${CIFS_HOST}${CIFS_REMOTE_PATH} ${CIFS_LOCAL_PATH}
MOUNT_STATUS=$?
if [ ${MOUNT_STATUS} = "0" ]; then
echo "Mount Status: ${MOUNT_STATUS}"
echo "Mount From: ${CIFS_HOST}:${CIFS_REMOTE_PATH}"
echo "Mount To: ${CIFS_LOCAL_PATH}"
else
echo "Mount Status: ${MOUNT_STATUS}"
exit 1
fi

…略…

#
# CIFS Umount
#
umount ${CIFS_LOCAL_PATH}

権限がない(privilegedとcapabilities)

デフォルトでDockerでmountを試みた場合、Unable to apply new capability set.でマウントできない。

これはDockerのRuntime privilege and Linux capabilitiesに記載がある。

By default, Docker containers are “unprivileged” and cannot, for example, run a Docker daemon inside a Docker container. This is because by default a container is not allowed to access any devices, but a “privileged” container is given access to all devices (see the documentation on cgroups devices).

デフォルトではDockerコンテナはunprivilegedで動作し、デバイスへのアクセスを許可されていない。

When the operator executes docker run –privileged, Docker will enable access to all devices on the host as well as set some configuration in AppArmor or SELinux to allow the container nearly all the same access to the host as processes running outside containers on the host.

docker run --privilegedで実行したとき、privileged状態で起動することができる。その場合、Dockerはホストすべてのデバイスにアクセス可能で、AppArmorやSELinuxの設定を行い、他のホスト上のプロセスと同じ権限を与えてしまう。

If you want to limit access to a specific device or devices you can use the –device flag. It allows you to specify one or more devices that will be accessible within the container.

--device付きで実行すれば、特定のデバイスの利用許可を与えることができる。

In addition to –privileged, the operator can have fine grain control over the capabilities using –cap-add and –cap-drop. By default, Docker has a default list of capabilities that are kept. The following table lists the Linux capability options which are allowed by default and can be dropped.

--privilegedに加えて、--cap-addで細かく権限を制御することができる。

docker-composeで権限付与を行う

privilegedはprivileged: trueで有効化することができる。
privilegedはすべての権限を付与するので以下の例に意味はないが、--cap-addcap_addとして設定することができる。

1
2
3
4
5
6
7
8
9
10
11
12
…略…
volumes:
- /var/run/docker.sock:/var/run/docker.sock
environment:
CIFS_USER: ${CIFS_USER}
CIFS_PASS: ${CIFS_PASS}
CIFS_HOST: ${CIFS_HOST}
CIFS_REMOTE_PATH: ${CIFS_REMOTE_PATH}
CIFS_LOCAL_PATH: ${CIFS_LOCAL_PATH}
privileged: true
cap_add:
- SYS_ADMIN

コメント・シェア

Dockerでsudoを実行する

 
カテゴリー Container Git   タグ

Dockerでsudoしようとするとエラーになる

Dockerでsudoを実行すると、パスワード入力を求められるためエラーになる。

1
2
3
4
5
6
7
8
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.

sudo: no tty present and no askpass program specified

対話型でパスワードを入力しないようにecho "<user> ALL=(ALL) NOPASSWD: ALL" > /etc/sudoersで指定ユーザはパスワードなしで実行可能にする。

環境変数が引き継がれない

sudoで実行した場合、環境変数が引き継がれない。これはenv_resetが有効になっているため。Defaults:<user> !env_resetで指定ユーザのみenv_resetを無効化することができる。

sudoを利用するためのDockerfile記述内容

1
2
3
4
RUN apt-get install -y --no-install-recommends sudo && \
echo "Defaults:<user> !env_reset" > /etc/sudoers && \
echo "<user> ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers
USER <user>

コメント・シェア

GitHub APIでSecretを同期する

 
カテゴリー CI/CD Git Python   タグ

.envファイルとGitHub Secretの同期

環境変数を記述した.envファイルの内容とGitHUbのSecretを同期する。

GitHub APIでSecretsを操作する

  • REST API v3 Secrets

  • 一覧取得 GET /repos/:owner/:repo/actions/secrets

  • Secret取得 GET /repos/:owner/:repo/actions/secrets/:secret_name

  • Secret更新 PUT /repos/:owner/:repo/actions/secrets/:secret_name

Name Type Description
encrypted_value string Value for your secret, encrypted with LibSodium using the public key retrieved from the Get a repository public key endpoint.
key_id string ID of the key you used to encrypt the secret.

暗号化した値を作成する必要がある。

Pythonの例は以下だが、GET /repos/:owner/:repo/actions/secrets/public-keyからpublic-keyを取得する必要がある。

1
2
3
4
5
6
7
8
9
from base64 import b64encode
from nacl import encoding, public

def encrypt(public_key: str, secret_value: str) -> str:
"""Encrypt a Unicode string using the public key."""
public_key = public.PublicKey(public_key.encode("utf-8"), encoding.Base64Encoder())
sealed_box = public.SealedBox(public_key)
encrypted = sealed_box.encrypt(secret_value.encode("utf-8"))
return b64encode(encrypted).decode("utf-8")

登録/削除

シークレットの登録~削除の流れは以下。secret_value.pyは前述のスクリプトをコマンドライン引数を受けて実行するようにしたもの。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
PUBLIC_KEY=$(curl --silent -H "Authorization: token ${GITHUB_TOKEN}" "https://api.github.com/repos/${GITHUB_USER}/${REPO_NAME}/actions/secrets/public-key" | jq '.key')
PUBLIC_KEYID=$(curl --silent -H "Authorization: token ${GITHUB_TOKEN}" "https://api.github.com/repos/${GITHUB_USER}/${REPO_NAME}/actions/secrets/public-key" | jq '.key_id')
ENCRYPTED_VALUE=$(python secret_value.py ${PUBLIC_KEY} ${SECRET_VALUE})

$ curl -H "Authorization: token ${GITHUB_TOKEN}" -X PUT -d "{ \"encrypted_value\": \"${ENCRYPTED_VALUE}\", \"key_id\": \"${PUBLIC_KEYID}\" }" -i "https://api.github.com/repos/${GITHUB_USER}/${REPO_NAME}/actions/secrets/testkey"
HTTP/1.1 201 Created
…略…

$ curl -H "Authorization: token ${GITHUB_TOKEN}" -i "https://api.github.com/repos/${GITHUB_USER}/${REPO_NAME}/actions/secrets"
HTTP/1.1 200 OK
…略…

{
"total_count": 1,
"secrets": [
{
"name": "testkey",
"created_at": "2020-05-21T03:30:27Z",
"updated_at": "2020-05-21T03:30:27Z"
}
]
}

$ curl -H "Authorization: token ${GITHUB_TOKEN}" -i "https://api.github.com/repos/${GITHUB_USER}/${REPO_NAME}/actions/secrets/testkey"
HTTP/1.1 200 OK
…略…
{
"name": "testkey",
"created_at": "2020-05-21T03:30:27Z",
"updated_at": "2020-05-21T03:30:27Z"
}

$ curl -H "Authorization: token ${GITHUB_TOKEN}" -X DELETE -i "https://api.github.com/repos/${GITHUB_USER}/${REPO_NAME}/actions/secrets/testkey"
HTTP/1.1 204 No Content
…略…

$ curl -H "Authorization: token ${GITHUB_TOKEN}" -i "https://api.github.com/repos/${GITHUB_USER}/${REPO_NAME}/actions/secrets/testkey"
HTTP/1.1 404 Not Found
…略…
{
"message": "Not Found",
"documentation_url": "https://developer.github.com/v3/actions/secrets/#get-a-secret"
}

$ curl -H "Authorization: token ${GITHUB_TOKEN}" -i "https://api.github.com/repos/${GITHUB_USER}/${REPO_NAME}/actions/secrets"
HTTP/1.1 200 OK
…略…
{
"total_count": 0,
"secrets": [

]
}

コメント・シェア

OneDriveが同期に失敗してクラッシュ

同期しようとして…クラッシュ。
何度再起動してもクラッシュするようになってしまった。

OneDrive width=320

1
2
3
4
5
6
7
8
9
10
11
障害が発生しているアプリケーション名: OneDrive.exe、バージョン: 20.52.311.11、タイム スタンプ: 0x95f7bd77
障害が発生しているモジュール名: SyncEngine.DLL、バージョン: 20.52.311.11、タイム スタンプ: 0x12301d0c
例外コード: 0xc0000005
障害オフセット: 0x0010080e
障害が発生しているプロセス ID: 0x1ee8
障害が発生しているアプリケーションの開始時刻: 0x01d62f0647ccdb4b
障害が発生しているアプリケーション パス: C:\Users\XXXX\AppData\Local\Microsoft\OneDrive\OneDrive.exe
障害が発生しているモジュール パス: C:\Users\XXXX\AppData\Local\Microsoft\OneDrive\20.052.0311.0011\SyncEngine.DLL
レポート ID: 56XXXXfd-XXXX-XXXX-a9c3-9360XXXXf3e7
障害が発生しているパッケージの完全な名前:
障害が発生しているパッケージに関連するアプリケーション ID:

状態をリセットする

コマンドプロンプトでOneDriveをリセットする。

1
C:\Users\ユーザ名\AppData\Local\Microsoft\OneDrive\OneDrive.exe /reset

Ctrl+Rのコマンド実行から%localappdata%を使用して省略実行。

1
%localappdata%\Microsoft\OneDrive\OneDrive.exe /reset

大量のファイルが再チェックされる。

OneDrive width=320

うまくマージできなかったファイルはコピーが残り、通知される。

OneDrive width=320

コメント・シェア

Windows Power Toys

 
カテゴリー Windows   タグ

Windows Power Toys v0.18

GitHubで公開されている。

PowerToys width=640

FancyZones

シフトキー押しながらWindowを移動すると、設定したレイアウトに配置できる。

PowerToys width=640

File Explorer Preview

エクスプローラーのプレビュー機能にSVGとMarkdownを追加。

PowerToys width=640

Image Resizer

画像ファイルリサイズ機能。

PowerToys width=640

Keyboard Manager

キーボードのショートカットリマッピング。

PowerToys width=640

PowerRename

正規表現を使ったファイルリネーム。

PowerToys width=640

PowerToys Run

ランチャー機能。

PowerToys width=640

Shortcut Guide

ショートカットガイド機能。

PowerToys width=640

コメント・シェア

nullpo

めも


募集中


Japan