1. Oracle Advanced AuthenticationおよびOracle Adaptive Risk Managementの管理
  2. Oracle Advanced AuthenticationおよびOracle Adaptive Risk Managementのインストール
  3. OAAおよびOARMのインストール手順

3 OAAおよびOARMのインストール手順

トピック

3.1 管理コンテナについて

管理コンテナは、新規または既存のKubernetesクラスタにOAAおよびOARMをインストールするために必要なすべてのスクリプトとツールが含まれるコンテナです。

このコンテナは、Kubernetesクラスタでポッドとして実行されます。それ自体はOAAおよびOARMデプロイメントの一部ではありませんが、KubernetesクラスタへのOAAやOARMのデプロイをスムーズにします。

管理コンテナ・ポッドには、zip、iputils、net-tools、vimなどの標準のlinuxユーティリティに加え、oraclelinuxに基づいて、次のバイナリがインストールされています:
  • kubectl
  • helm
  • sqlplus: instantclient_19_10
  • openssl

管理コンテナの詳細は、次の各トピックを参照してください:

3.1.1 管理コンテナのコンポーネント

この項では、管理コンテナ・ポッド内の重要なファイルおよびフォルダの概要を説明します。

表3-1 管理コンテナのファイルおよびフォルダ・リファレンス

ファイルおよびフォルダ 説明
OAA.sh このスクリプト・ファイルは、OAAおよびOARMのインストールに使用されます。OAA、OAA-OARMおよびOARMをインストールするためのスクリプトの引数として、installOAA.propertiesファイルを指定する必要があります。

詳細は、「OAAおよびOARMインストール用のプロパティ・ファイルの準備」を参照してください
installsettings このフォルダにはoaaoverride.yamlが含まれており、これをカスタマイズして、OAAおよびOARMの一部のサービスのreplicaCountを設定できます。

これを有効にするには、installOAA.propertiesでcommon.deployment.overridefileプロパティを設定する必要があります。

helmcharts このフォルダには、すべてのOAAおよびOARMサービスのhelmチャートとvalue.yamlがあります。
libs このフォルダには、次のファイルが含まれています:
  • OAAAuthnPlugin.jar: このプラグインは、OAMとOAAの統合に使用されます。
    • OAMが4月22日のバンドル・パッチ(12.2.1.4.220404)より前の場合。プラグインはOAMにインポートする必要があります。
    • OAMに4月22日のバンドル・パッチ(12.2.1.4.220404)以降がある場合、OAMにはデフォルトでプラグインが含まれています。
    詳細は、OAM用のOAAプラグインのインストールに関する項を参照してください
  • messagingprovider-interface-install-oaa-<release-version>.jar: このファイルは、OAAのSMSおよび電子メール・ファクタのカスタマイズに使用できます。詳細は、「電子メールおよびSMSメッセージング・プロバイダのカスタマイズ」を参照してください
logs このフォルダはNFSボリューム<NFS_LOG_PATH>にマップされ、OAAおよびOARMインストールのログとステータスが格納されます。
oaa_cli このフォルダには、OARMのジオロケーション・データのインストールでカスタマイズや使用が可能なファイルがあります。詳細は、「ジオロケーション・データのロード」を参照してください
scripts/creds このフォルダはNFSボリューム<NFS_CREDS_PATH>にマップされ、インストール中に使用される次のファイルが含まれます:
  • trust.p12
  • cert.p12
  • k8sconfig
  • helmconfig
scripts/settings このフォルダはNFSボリューム<NFS_CONFIG_PATH>にマップされ、インストールに必要なinstallOAA.propertiesおよびoaaoverride.yaml構成ファイルが格納されます。
service/store/oaa/ このフォルダは、管理コンテナとOAAおよびOARMデプロイメント間で共有されるNFSボリューム<NFS_VAULT_PATH>にマップされます。これにはファイル・ベースのボールトが格納されます(OCIベースのボールトを使用していない場合)。

3.1.2 管理コンテナの事前設定された環境変数

管理コンテナ・ポッドは、事前定義された環境変数のセットで構成されます。

表3-2 事前設定された環境変数

環境変数 説明
HELM_CONFIG これは/u01/oracle/scripts/creds/helmconfigに設定されます。
KUBECONFIG これは/u01/oracle/scripts/creds/k8sconfigに設定されます。
SCRIPT_PATH これは/u01/oracle/scriptsに設定されます。これにはインストール・スクリプトが含まれます。
CONFIG_DIR これは、構成を外部に格納するために使用されるNFSボリューム<NFS_CONFIG_PATH>です。

コンテナ内のパス/u01/oracle/scripts/settingsにマウントされます。

CREDS_DIR これは、helm構成、kube構成、ログイン秘密キーなどの資格証明を格納するために使用されるNFSボリューム<NFS_CREDS_PATH>です。

コンテナ内のパス/u01/oracle/scripts/credsにマウントされます。

LOGS_DIR これは、インストール・ログおよびステータスを格納するために使用されるNFSボリューム<NFS_LOGS_PATH>です。

コンテナ内のパス/u01/oracle/logsにマウントされます。

HELM_CHARTS_PATH これは、インストールに関連するすべてのhelmチャートが存在するパスです。
LD_LIBRARY_PATH instantclientフォルダを設定します。この変数は、コンテナ内に存在するinstantclientからsqlplusおよびDB関連のコマンドを実行するために必要です。
LIBS_DIR これは、パス/u01/oracle/libsにあります。

電子メール・プロバイダおよびSMSプロバイダのカスタマイズに必要なjarファイルと、OAM認証プラグインが含まれます。

また、ファイル・ベースのボールトのデプロイメントに必要なjarも含まれます。
JARPATH これには、ファイル・ベースのボールトを適切に実行するために必要なjarが含まれます。

3.1.3 管理コンテナにマウントされたボリューム

この項では、管理コンテナ・ポッドにマウントされたボリュームについて詳しく説明します。

表3-3 管理コンテナにマウントされたボリューム

マウント・フォルダ 説明 設定される権限
/u01/oracle/logs パスは構成できません。

これは、インストール・ログおよびステータスを格納するために使用されます

これは、前提条件として作成されたNFSボリューム<NFS_LOG_PATH>にマップされます。

読取り/書込み/実行

NFSボリューム<NFS_LOG_PATH>には、すべてに対する読取り/書込み/実行権限が必要です。

/u01/oracle/scripts/settings パスは構成できません。

これは、OAAおよびOARMをインストールするためのカスタマイズされた構成ファイルの格納に使用されます。

これは、前提条件として作成されたNFSボリューム<NFS_CONFIG_PATH>にマップされます。

読取り/書込み/実行

NFSボリューム<NFS_CONFIG_PATH>には、すべてに対する読取り/書込み/実行権限が必要です。

/u01/oracle/scripts/creds パスは構成できません。

これは、k8sconfig、helmconfig、trust.p12、cert.p2などの資格証明ファイルを格納するために使用されます

これは、前提条件として作成されたNFSボリューム<NFS_CREDS_PATH>にマップされます。

読取り/書込み/実行

NFSボリューム<NFS_CREDS_PATH>には、すべてに対する読取り/書込み/実行権限が必要です。

/u01/oracle/service/store/oaa パスは構成可能です。

これは、ファイルベースのボールトのボールト・アーティファクトを格納するために使用されます。

これは、前提条件として作成されたNFSボリューム<NFS_VAULT_PATH>にマップされます。

読取り/書込み/実行

NFSボリューム<NFS_VAULT_PATH>には、すべてに対する読取り/書込み/実行権限が必要です。

NFSボリューム要件の詳細は、「NFSボリュームの構成」を参照してください。

3.2 OAAおよびOARMのインストールに事前に必要な構成

インストール手順に進む前に、次の操作を実行したことを確認してください:

3.2.1 Kubernetesクラスタの構成

OAAとOARMは、クラウド・ネイティブ環境にデプロイするよう設計されています。OAAとOARMは、Helmチャートで管理されるKubernetesクラスタ上でマイクロサービスとして実行される複数のコンポーネントで構成されています。具体的には、各コンポーネント(マイクロサービス)は、クラスタ内のKubernetesノードにデプロイされるKubernetesポッドとして構成されます。

次の要件を満たすKubernetesクラスタをインストールする必要があります:

  • Kubernetesクラスタには3つ以上のノードが必要です。
  • これらのノードは、次の最小システム仕様要件を満たしている必要があります:
    システム 最小要件
    メモリー 64GB RAM
    ディスク 150GB
    CPU 8 CPU (仮想化サポート付き。たとえば、Intel VTなど)
  • HelmをKubernetesクラスタにインストールする必要があります。Helmは、必要なリソースを作成およびデプロイするために使用されます。
  • サポートされているコンテナ・エンジンをKubernetesクラスタにインストールして実行する必要があります。
  • Kubernetesクラスタおよびコンテナ・エンジンは、My Oracle SupportのドキュメントID 2723908.1で概説されている最小バージョン要件を満たす必要があります。
  • Kubernetesクラスタのノードは、ネットワーク・ファイル・システム(NFS)マウントなどの共有ボリュームにアクセスできる必要があります。このNFSマウントは、インストール中に管理コンテナによって使用され、(OCIベースのボールトを使用していない場合は)ファイル・ベースのボールトに対して、またジオロケーション・データのロードなどの他のインストール後のタスクに対して使用されます。

3.2.2 NFSボリュームの構成

Kubernetesクラスタ内のすべてのノードがNFSサーバー上の共有ボリュームにアクセスできる必要があります。OAA/OARMのインストール中、管理コンテナ・ポッドは構成情報、資格証明およびログをNFSボリュームに格納します。インストールが完了すると、ポッドは、ランタイム資格証明の格納およびアクセスのために、ファイル・ベースのボールト(OCIベースのボールトを使用しない場合)を含むボリュームにアクセスできる必要があります。

インストール前に、次のNFSボリュームを作成する必要があります。いずれの場合も、NFSエクスポート・パスにはすべてに対する読取り/書込み/実行権限が必要です。クラスタ内のすべてのノードでNFSボリュームにアクセスできることを確認します。

ボリューム 説明 パス
構成 installOAA.propertiesなどのOAA構成を格納するNFSボリューム。 <NFS_CONFIG_PATH>
資格証明 Kubernetes構成、Helm構成、SSHキー、PKCS12ファイルなどのOAA資格証明を格納するNFSボリューム。 <NFS_CREDS_PATH>
ログ OAAインストール・ログおよびステータスを格納するNFSボリューム。 <NFS_LOGS_PATH>
ファイル・ベースのボールト OAAランタイム資格証明を格納するNFSボリューム。 <NFS_VAULT_PATH>

ノート:

NFSサーバーのIPアドレスとPATHは、installOAA.properties内に設定されます。「OAAおよびOARMインストール用のプロパティ・ファイルの準備」を参照してください

3.2.3 Oracle Databaseのインストール

OAAおよびOARMでは、データベース・スキーマを使用して情報が格納されます。OCIまたはオンプレミスにOracle Databaseをインストールして構成する必要があります。データベースがパーティショニング機能/能力をサポートしている必要があります。

OAAおよびOARMでは、Oracle Database 12c (12.2.0.1+)、18cおよび19cがサポートされています。サポートされているデータベース・バージョンの詳細は、http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.htmlを参照してください。

OAA/OARMをインストールするKubernetesクラスタには、データベースへのネットワーク接続が必要です。

ノート:

ASM以外のデータベースを使用する場合は、データベースにパラメータDB_CREATE_FILE_DESTが設定されていることを確認する必要があります。たとえば:
SQL> connect SYS/<password> as SYSDBA;
Connected.
SQL> show parameter DB_CREATE_FILE_DEST;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_create_file_dest                  string      /u01/app/oracle/oradata
パラメータが設定されていない場合は、次を実行します:
SQL> ALTER SYSTEM SET DB_CREATE_FILE_DEST = '/u01/app/oracle/oradata' scope=both;
ここで、/u01/app/oracle/oradataは、データファイルが存在するパスです。

3.2.4 OAM OAuthのインストールおよび構成

OAAおよびOARMでは、OAuthを有効にしてOracle Access Management (OAM)インストールにアクセスする必要があります。OAA/OARMをインストールするKubernetesクラスタには、OAMインストールへのネットワーク接続が必要です。

OAAおよびOARMのユーザー・インタフェース(UI)コンポーネント(OAA管理コンソールおよびユーザー・プリファレンス・コンソール)は、Oracle Access Management (OAM) OAuthによって保護されます。必要なOAuthコンポーネント(アイデンティティ・ドメイン、リソース、クライアント)は、OAAのインストール中に構成できます。ただし、OAMで必要なOAuthコンポーネントがインストール時に構成されるようにするには、次の前提条件ステップを実行しておく必要があります:

ノート:

インストール中にUIコンポーネントが不要な場合や無効にする必要がある場合は、この項のOAuth構成をスキップできます。OAuth構成をスキップする場合は、installOAA.properties内にoauth.enabled=falseを関連プロパティとともに設定する必要があります。詳細は、「OAM OAuth構成」を参照してください。
  1. Oracle Access Managementのインストール詳細は、「Oracle Access Managementのインストール」を参照してください。
  2. WebGatesをOAMに登録します。詳細は、OAMエージェントの登録および管理に関する項を参照してください
  3. Oracle Access ManagementコンソールでOAuthを有効にします:
    1. OAMコンソール(https://<OAMAdminHost>:<OAMAdminPort>/oamconsole/)にログインします
    2. 「ようこそ」ページで、「構成」、「使用可能なサービス」の順にクリックします
    3. OAuthおよびOpenIDConnectサービスの横にある「サービスの有効化」をクリックします(または緑色のステータス・チェック・マークが表示されることを確認します)。
  4. <OHS_HOME>/user_projects/domains/base_domain/config/fmwconfig/components/OHS/<ohs_instance_name>にあるmod_wl_ohs.confファイルを開き、次を追加します:
    <Location /oauth2>
SetHandler weblogic-handler
WebLogicHost <OAM_Managed_Server_Host>
WebLogicPort <OAM_Managed_Server_Port>
</Location>

<Location /oam>
 SetHandler weblogic-handler
 WebLogicHost <OAM_Managed_Server_Host>
 WebLogicPort <OAM_Managed_Server_Port>
</Location>

<Location /.well-known/openid-configuration>
 SetHandler weblogic-handler
 WebLogicHost <OAM_Managed_Server_Host>
 WebLogicPort <OAM_Managed_Server_Port>
 PathTrim /.well-known
 PathPrepend /oauth2/rest
</Location>

<Location /.well-known/oidc-configuration>
SetHandler weblogic-handler
WebLogicHost <OAM_Managed_Server_Host>
WebLogicPort <OAM_Managed_Server_Port>
PathTrim /.well-known
PathPrepend /oauth2/rest
</Location>

<Location /CustomConsent>
SetHandler weblogic-handler
WebLogicHost <OAM_Managed_Server_Host>
WebLogicPort <OAM_Managed_Server_Port>
</Location>

    ノート:

    <OAM_Managed_Server_Host>および<OAM_Managed_Server_Port>は、OAM管理対象サーバーのホスト名とポートです。
  5. <OHS_HOME>/user_projects/domains/base_domain/config/fmwconfig/components/OHS/<ohs_instance_name>/にあるhttpd.confファイルを開き、次を追加します:

    ノート:

    <DomainName>でOAuthアイデンティティ・ドメインの値を指定します。<DomainName>は、後でinstallOAA.propertiesのパラメータoauth.domainnameで使用されます。 
    <IfModule mod_rewrite.c>
RewriteEngine on
RewriteRule ^/oauth2/rest/authorize? /oauth2/rest/authorize?domain=<DomainName> [PT,QSA,L]
RewriteRule ^/oauth2/rest/token? /oauth2/rest/token?domain=<DomainName> [PT,QSA,L]
RewriteRule ^/oauth2/rest/token/info? /oauth2/rest/token/info?domain=<DomainName> [PT,QSA,L]
RewriteRule ^/oauth2/rest/authz? /oauth2/rest/authz?domain=<DomainName> [PT,QSA,L]
RewriteRule ^/oauth2/rest/userinfo? /oauth2/rest/userinfo?domain=<DomainName> [PT,QSA,L]
RewriteRule ^/oauth2/rest/security? /oauth2/rest/security?domain=<DomainName> [PT,QSA,L]
RewriteRule ^/oauth2/rest/userlogout? /oauth2/rest/userlogout?domain=<DomainName> [PT,QSA,L]
</IfModule>

<IfModule mod_headers.c>
#Add Identity domain header always for OpenID requests
RequestHeader set X-OAUTH-IDENTITY-DOMAIN-NAME "<DomainName>"
</IfModule>
  6. 前述のステップで定義されたOHS WebGateについて、OAMコンソールで次を実行します:
    1. 次の各リソースを作成し、「保護レベル」を「除外」に設定します。
      • /oauth2/rest/**
      • /oam/**
      • /.well-known/openid-configuration
      • /iam/access/binding/api/v10/oap/**
      • /oam/services/rest/**
      • /iam/admin/config/api/v1/config/**
      • /oaa-admin/**
      • /admin-ui/**
      • /oaa/**
      • /policy/**
      • /oaa-policy/**
      • /oaa-email-factor/**
      • /oaa-sms-factor/**
      • /oaa-totp-factor/**
      • /oaa-yotp-factor/**
      • /fido/**
      • /oaa-kba/**
      • /oaa-push-factor/**
      • /risk-analyzer/**
      • /risk-cc/**
      • /consolehelp/**
      • /otpfp/**
    2. 次の各リソースを作成し、「保護レベル」を「保護」に設定し、「認証ポリシー」および「認可ポリシー」を保護されたリソース・ポリシーに設定します
      • /oauth2/rest/approval (これはPOST操作用です)
      • /oam/pages/consent.jsp (これはGET操作用です)

    詳細は、ポリシー・リソース定義の追加および管理に関する項を参照してください

  7. OAMでOHSをリバース・プロキシとして構成します。次の手順を実行します:
    1. OAMコンソール(https://<OAMAdminHost>:<OAMAdminPort>/oamconsole/)にログインします
    2. 「ようこそ」ページで、「構成」をクリックし、「設定」タイルで「表示」→「Access Manager」をクリックします。
    3. 「ロード・バランシング」で、「OHSホスト」と「OHSポート」を指定します。

3.2.5 OAMアイデンティティ・ストアでのユーザーおよびグループの設定

Oracle Advanced Authenticationでは、次のグループをLDAPで構成する必要があります:
  • OAA-Admin-Role。これは、OAA管理コンソールUIにアクセスする権限を持つユーザーを認証するために使用されます。
  • OAA-App-User。これには、OAAユーザー・プリファレンスUIにアクセスする権限を持つユーザーが含まれます。
OAAにアクセスする必要があるすべてのユーザーは、OAA-App-Userグループのメンバーであることが必要で、メンバーでない場合は、OAM OAuthを介してOAAユーザー・プリファレンスのUIにログインできません。同様に、管理者がOAA管理コンソールにアクセスするには、OAA-Admin-Roleグループのメンバーであることが必要です。

ノート:

ユーザーをOAA-Admin-RoleおよびOAA-App-Userグループの両方のメンバーにすることはできません。そのため、専用の管理者ユーザー名の使用をお薦めします。

ユーザーとグループの作成

ユーザーおよびグループを作成するには:
  1. LDIFファイルoaa_admin.ldifを作成します。このファイルの内容は次のとおりです:

    ノート:

    次の例は、OAMが有効になったディレクトリが対象です。 
    dn: cn=oaaadmin,cn=Users,dc=example,dc=com
changetype: add
objectClass: orclUserV2
objectClass: oblixorgperson
objectClass: person
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: oblixPersonPwdPolicy
objectClass: orclAppIDUser
objectClass: orclUser
objectClass: orclIDXPerson
objectClass: top
objectClass: OIMPersonPwdPolicy
givenName: oaaadmin
uid: oaaadmin
orclIsEnabled: ENABLED
sn: oaaadmin
userPassword: <Password>
mail: oamadmin@example.com
orclSAMAccountName: oaaadmin
cn: oaaadmin
obpasswordchangeflag: false
ds-pwp-password-policy-dn: cn=FAPolicy,cn=pwdPolicies,cn=Common,cn=Products,cn=OracleContext,dc=example,dc=com

dn:cn=OAA-Admin-Role,cn=Groups,dc=example,dc=com
changetype: add
objectClass: top
objectClass: groupofuniquenames
uniqueMember: cn=oaaadmin,cn=Users,dc=example,dc=com

dn:cn=OAA-App-User,cn=Groups,dc=example,dc=com
changetype: add
objectClass: top
objectClass: groupofuniquenames
  2. LDIFファイルをディレクトリにロードします。次の例では、Oracle Unified Directoryを使用していると想定しています:
    $ cd INSTANCE_DIR/OUD/bin
ldapmodify -h <OUD_HOSTNAME> -p 1389 -D "cn=Directory Manager" -w <password> -f oaa_admin.ldif

OAAユーザー・グループへの既存のユーザーの追加

OAAを使用するように既存のユーザーを構成する場合は、前に作成したOAA-App-Userグループにユーザーを追加する必要があります:
  1. LDAPインスタンスで次のコマンドを実行しますこれらのコマンドにより、既存のすべてのユーザーをOAA-App-Userグループに追加するLDIFファイルが作成されます:
    echo "dn:cn=OAA-App-User,cn=Groups,dc=example,dc=com" > update_group.ldif
    echo "changetype: modify" >> update_group.ldif
    echo "add: uniqueMember" >> update_group.ldif
    ldapsearch -h <OUD_HOSTNAME> -p 1389 "cn=Directory Manager" -w <password> -b cn=Users,dc=example,dc=com "cn=*" dn | grep -v oaaadmin | grep -v "dn: cn=Users,dc=example,dc=com" | grep cn| awk ' { print "uniqueMember: "$2 } ' >> update_group.ldif
  2. update_group.ldifを編集し、グループに追加しないユーザーを削除します。
  3. LDIFファイルをディレクトリにロードします:
    ldapmodify -h <OUD_HOSTNAME> -p 1389 -D "cn=Directory Manager" -w <password> -f update_group.ldif

3.2.6 コンテナ・イメージ・レジストリ(CIR)のインストール

管理コンテナのインストール中に、OAAおよびOARMコンテナ・イメージがコンテナ・イメージ・レジストリ(CIR)にプッシュされます。OAAとOARMがデプロイされるとき、デプロイメントでは同じコンテナ・イメージ・レジストリからイメージがプルされます。そのため、前提条件としてコンテナ・イメージ・レジストリをインストールする必要があります。コンテナ・イメージ・レジストリは、OAA/OARMをデプロイするKubernetesクラスタ内のすべてのノードからアクセスできる必要があります。

使用しているCIRによっては、OAAおよびOARMのインストール前に、CIRに次のリポジトリ・エントリを作成する必要があります。たとえば、Oracle Cloud Infrastructure (OCI)でOracle Container Registryを使用している場合は、事前にこれらのリポジトリ・エントリを作成する必要があります。作成しないと、インストールでイメージのプッシュに失敗します:
  • oaa-admin
  • oaa-factor-email
  • oaa-factor-fido
  • oaa-factor-kba
  • oaa-factor-push
  • oaa-factor-sms
  • oaa-factor-totp
  • oaa-factor-yotp
  • oaa-factor-custom
  • oaa-mgmt
  • oaa-policy
  • oaa-spui
  • oaa-svc
  • risk-cc
  • risk-engine

CIRがない場合は、https://hub.docker.com/_/registry/からDockerレジストリをダウンロードできます。

3.2.7 外部ホスト名解決のためのCoreDNSの構成

Kubernetesクラスタがインストールに必要なホスト名を解決できるように、クラスタでCoreDNSを構成する必要があります。

次のようにCoreDNSを構成する必要があります:
  • プロキシ・サーバー、Kubernetesノード、OAM OAuthサーバー、Oracle Databaseおよびコンテナ・イメージ・レジストリのhostname.domainとIPアドレスを追加します。または、
  • プロキシ・サーバー、Kubernetesノード、OAM OAuthサーバー、Oracle Databaseおよびコンテナ・イメージ・レジストリのhostname.domainとIPアドレスを解決できるドメイン・ネーム・サーバー(DNS)を追加します。
ノート: 次の手順はKubernetesに汎用的なものであり、すべてのKubernetesベンダーに適用できるわけではありません。CoreDNSの構成方法については、Kubernetesベンダー固有のドキュメントを参照してください。

CoreDNSへの個々のホスト名およびIPアドレスまたはDNSの追加

  1. 次のコマンドを実行して、coredns configmapを編集します:
    kubectl edit configmap/coredns -n kube-system
    これにより、viのような編集セッションに移動します。
  2. 個々のホスト名とIPアドレスを追加する場合は、定義するホストごとに1つずつエントリを含めたhostsセクションをファイルに追加します。たとえば:
    apiVersion: v1
data:
  Corefile: |
    .:53 {
        errors
        health {
           lameduck 5s
        }
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
           pods insecure
           fallthrough in-addr.arpa ip6.arpa
           ttl 30
        }
        prometheus :9153
        forward . /etc/resolv.conf {
           max_concurrent 1000
        }
        cache 30
        loop
        reload
        loadbalance
        hosts custom.hosts example.com { 
             1.1.1.1 oam.example.com 
             1.1.1.2 db.example.com 
             1.1.1.3 container-registry.example.com 
             1.1.1.4 masternode.example.com 
             1.1.1.5 worker1.example.com
             1.1.1.6 worker2.example.com
             fallthrough 
        }
      }
kind: ConfigMap
metadata:
  creationTimestamp: "2021-11-09T14:08:31Z"
  name: coredns
  namespace: kube-system
  resourceVersion: "25242052"
  uid: 21e623cf-e393-425a-81dc-68b1b06542b4
    または、ドメイン・ネーム・サーバー(DNS)を追加する場合は、DNSのセクションを追加します:
    apiVersion: v1
data:
  Corefile: |
    .:53 {
        errors
        health {
           lameduck 5s
        }
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
           pods insecure
           fallthrough in-addr.arpa ip6.arpa
           ttl 30
        }
        prometheus :9153
        forward . /etc/resolv.conf {
           max_concurrent 1000
        }
        cache 30
        loop
        reload
        loadbalance
      }
    example.com:53 {
      errors
      cache 30
      forward . <DNS_IPADDRESS>
      }
kind: ConfigMap
metadata:
  creationTimestamp: "2021-11-09T14:08:31Z"
  name: coredns
  namespace: kube-system
  resourceVersion: "25242052"
  uid: 21e623cf-e393-425a-81dc-68b1b06542b4
  3. ファイルを保存します(!wq)。
  4. CoreDNSを再起動します:
    1. 次のコマンドを実行して、corednsを再起動します:
      kubectl delete pod --namespace kube-system --selector k8s-app=kube-dns
    2. 次のコマンドを実行して、corednsポッドが問題なく再起動されることを確認します:
      kubectl get pods -n kube-system
      エラーが表示された場合は、次のコマンドを使用してログを表示してから、coredns configmapを再度編集して修正します:
      kubectl logs -n kube-system coredns--<ID>

DNS解決の検証

ほとんどのコンテナには、行った構成変更が正しいことを確認できる組込みネットワーク・ツールがありません。変更を検証する最も簡単な方法は、alpineなどのネットワーク・ツールがインストールされている軽量のコンテナを使用することです。
  1. 次のコマンドを実行して、alpineコンテナを実行します:
    kubectl run -i --tty --rm debug --image=docker.io/library/alpine:latest --restart=Never -- sh
    これにより、コンテナ内のBashシェル内に移動します。
  2. コンテナ内で、データベース、OAM OAuthサーバー、コンテナ・イメージ・レジストリなどに対してnslookupを実行できるようになります。次に例を示します:
    nslookup oam.example.com

3.2.8 インストール・ホストの要件

管理コンテナのインストールは、Kubernetesクラスタにデプロイするためのアクセス権を持つ任意のノードから実行できます。この項では、管理コンテナのインストールが実行されるノードに対する特定の要件をリストします。

インストール・ホストは、次の要件を満たしている必要があります:

  • Linux x86_64。
  • 2つ以上のCPUと16GBのRAM。
  • ルート・パーティション"/"内に40GB以上の空き領域。
  • ノードは、管理コンテナおよびOAA/OARMがインストールされるKubernetesクラスタにデプロイするためのアクセス権を持っている必要があります。kubectlバージョンの要件は、「Kubernetesクラスタの構成」のとおりです。
  • Podman 3.3.0以降。(podmanを選択しない場合は、Docker 19.03以上を使用できます)。
  • Helm 3.5以降。
  • Openssl。
  • インターネットへのアクセスにプロキシを必要とする環境の場合は、Oracle Container Registryに接続するために関連するプロキシを設定する必要があります。たとえば:
    export http_proxy=http://proxy.example.com:80
export https_proxy=http://proxy.example.com:80
export HTTPS_PROXY=http://proxy.example.com:80
export HTTP_PROXY=http://proxy.example.com:80
    また、no_proxyが設定され、そこにkubectl config viewのserverの下の出力で参照されるノードが含まれていることを確認する必要があります。たとえば、kubectl config viewで次のように表示されるとします:
    kubectl config view
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://masternode.example.com:6443
  name: kubernetes
contexts:
etc...
    この場合は、次のように設定します:
    export NO_PROXY=masternode.example.com:$NO_PROXY
export no_proxy=masternode.example.com:$no_proxy
  • 「コンテナ・イメージ・レジストリ(CIR)のインストール」に示されているように、ノードがコンテナ・イメージ・レジストリにアクセスできる必要があります。
  • インストールでサポート・イメージがプルされるためには、インストールを実行する管理者がOracle Container Registryのログイン資格証明を持っている必要があります。管理コンテナのインストール中に、これらの資格証明の入力を求められます。
  • インストール・ホストからOracle Container Registryにログインできることを確認します:
    podman login container-registry.oracle.com

    ノート:

    podmanを使用しておらず、Dockerを使用している場合は、docker login container-registry.oracle.comを実行します。

3.2.9 サーバー証明書および信頼証明書の生成

OAAおよびOARMは通信にSSLを使用します。インストール前に、サーバー証明書および信頼証明書キーストア(PKCS12)を生成する必要があります。

証明書の生成にサード・パーティ認証局を使用するかどうか、またはテスト目的で独自のCAおよび証明書を生成するかどうかに応じて、次の関連する項に従います。

証明書を生成するためのサード・パーティCAの使用

  1. 管理コンテナのインストールを実行するノードで、ディレクトリを作成し、そのフォルダに移動します。次に例を示します:
    mkdir <workdir>/oaa_ssl
export WORKDIR=<workdir>
cd $WORKDIR/oaa_ssl
  2. サーバー証明書の4096ビット秘密キー(oaa.key) を生成します:
    openssl genrsa -out oaa.key 4096
  3. 証明書署名リクエスト(oaa.csr)を作成します:
    openssl req -new -key oaa.key -out oaa.csr
    求められた場合は、証明書署名リクエスト(CSR)作成の詳細を入力します。たとえば:
    You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:US
State or Province Name (full name) []:California
Locality Name (eg, city) [Default City]:Redwood City
Organization Name (eg, company) [Default Company Ltd]:Example Company
Organizational Unit Name (eg, section) []:Security
Common Name (eg, your name or your server's hostname) []:oaa.example.com
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
  4. CSR (oaa.csr)をサード・パーティCAに送信します。
  5. CAから証明書を受信したら、ファイルの名前をoaa.pemに変更し、それを$WORKDIR/oaa_sslディレクトリにコピーします。

    ノート:

    証明書oaa.PEMはPEM形式である必要があります。PEM形式でない場合は、opensslを使用してPEMに変換します。たとえば、DER形式からPEMに変換するには:
    openssl x509 -inform der -in oaa.der -out oaa.pem
  6. 信頼ルートCA証明書(rootca.pem)と、oaa.pemに署名したチェーン内の他のCA証明書(rootca1.pem、rootca2.pemなど)を、$WORKDIR/oaa_sslディレクトリにコピーします。前述のとおり、CA証明書はPEM形式である必要があるため、必要に応じて変換します。
  7. CAのチェーンに複数の証明書がある場合は、すべてのCA証明書を含むbundle.pemを作成します:
    cat rootca.pem rootca1.pem rootca2.pem >>bundle.pem
  8. 次のように、信頼証明書PKCS12ファイル(trust.p12)をファイルから作成します:
    openssl pkcs12 -export -out trust.p12 -nokeys -in bundle.pem
    求められた場合は、エクスポート・パスワードを入力して確認します。

    ノート:

    CAに証明書チェーンがない場合は、bundle.pemをrootca.pemに置き換えます。
  9. 次のように、サーバー証明書PKCS12ファイル(cert.p12)を作成します:
    openssl pkcs12 -export -out cert.p12 -inkey oaa.key -in oaa.pem -chain -CAfile bundle.pem
    求められた場合は、エクスポート・パスワードを入力して確認します。

    ノート:

    CAに証明書チェーンがない場合は、bundle.pemをrootca.pemに置き換えます。

ノート:

cert.p12およびtrust.p12へのパスは、後でinstallOAA.propertiesのパラメータcommon.local.sslcertおよびcommon.local.trustcertで使用されます。

テスト目的で独自のCAおよび証明書を生成します

  1. 次のように、信頼証明書PKCS12ファイル(trust.p12)を作成します:
    1. 管理コンテナのインストールを実行するノードで、ディレクトリを作成し、そのフォルダに移動します。次に例を示します:
      mkdir <workdir>/oaa_ssl
export WORKDIR=<workdir>
cd $WORKDIR/oaa_ssl
    2. ルート認証局(CA)の4096ビットの秘密キーを生成します:
      openssl genrsa -out ca.key 4096
    3. 自己署名ルートCA証明書(ca.crt)を作成します:
      openssl req -new -x509 -days 3650 -key ca.key -out ca.crt
      求められた場合は、CA作成の詳細を入力します。たとえば:
      You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:US
State or Province Name (full name) []:California
Locality Name (eg, city) [Default City]:Redwood City
Organization Name (eg, company) [Default Company Ltd]:Example Company
Organizational Unit Name (eg, section) []:Security
Common Name (eg, your name or your server's hostname) []:OAA Certificate Authority
Email Address []:
    4. CA証明書のPKCS12ファイルを生成します:
      openssl pkcs12 -export -out trust.p12 -nokeys -in ca.crt
      求められた場合は、エクスポート・パスワードを入力して確認します。
  2. 次のように、サーバー証明書PKCS12ファイル(cert.p12)を作成します:
    1. サーバー証明書の4096ビット秘密キー(oaa.key) を生成します:
      openssl genrsa -out oaa.key 4096
    2. 証明書署名リクエスト(cert.csr)を作成します:
      openssl req -new -key oaa.key -out cert.csr
      求められた場合は、証明書署名リクエスト(CSR)作成の詳細を入力します。たとえば:
      You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:US
State or Province Name (full name) []:California
Locality Name (eg, city) [Default City]:Redwood City
Organization Name (eg, company) [Default Company Ltd]:Example Company
Organizational Unit Name (eg, section) []:Security
Common Name (eg, your name or your server's hostname) []:oaa.example.com
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
    3. 作成しておいたCAを使用して、CSRから証明書を生成します:
      openssl x509 -req -days 1826 -in cert.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out oaa.crt
    4. 秘密キーとサーバー証明書からPKCS12ファイル(cert.p12)を生成します:
      openssl pkcs12 -export -out cert.p12 -inkey oaa.key -in oaa.crt -chain -CAfile ca.crt
      求められた場合は、エクスポート・パスワードを入力して確認します。

ノート:

cert.p12およびtrust.p12へのパスは、後でinstallOAA.propertiesのパラメータcommon.local.sslcertおよびcommon.local.trustcertで使用されます。

3.2.10 Kubernetesネームスペースおよびシークレットの作成

OAAおよびOARMデプロイメントのKubernetesネームスペースおよびシークレットを作成します。

  1. OAAおよびOARMデプロイメント用のKubernetesネームスペースを作成します:
    kubectl create namespace <namespace>
    たとえば:
    kubectl create namespace oaans

    ノート:

    指定したネームスペースは、後でinstallOAA.propertiesのパラメータcommon.kube.namespace=oaansで使用されます。
  2. OAAネームスペースで、コンテナ・イメージ・レジストリ(CIR)のKubernetesシークレットを作成します。これは、管理コンテナ・ポッドがイメージをCIRにプッシュできるようにするため、またOAA/OARMデプロイメントがイメージをCIRからプルできるようにするために必要です。
    kubectl create secret docker-registry dockersecret --docker-server=<CONTAINER_REGISTRY> \
 --docker-username='<USER_NAME>' \
--docker-password='<PASSWORD>' \
--docker-email='<EMAIL_ADDRESS>' \
--namespace=<namespace>
    たとえば:
    kubectl create secret docker-registry dockersecret --docker-server=container-registry.example.com \
--docker-username="user@example.com" \
--docker-password=<PASSWORD> --docker-email=user@example.com \
--namespace=oaans

    ノート:

    シークレット名dockersecretは、後でinstallOAA.propertiesのパラメータinstall.global.imagePullSecrets\[0\].nameで使用されます。

次のステップ: OAAおよびOARMインストール用のプロパティ・ファイルの準備

3.3 インストール・ファイルのダウンロードと管理コンテナの準備

この項では、インストール・ファイルをダウンロードし、OAAおよびOARMの管理コンテナを準備するステップを説明します。

管理コンテナのインストールは、Kubernetesクラスタにデプロイするためのアクセス権を持つ任意のノードから実行できます。インストール中、管理コンテナ・ポッドはKubernetesクラスタ内のいずれかのノードにデプロイします。

  1. ドキュメントID 2723908.1を参照して、My Oracle Supportから最新のOAAインストール・イメージ<OAA_Image>.zipをダウンロードします。
  2. 管理コンテナのインストールを実行するノードで、$WORKDIR/oaaimagesディレクトリを作成し、<OAA_Image>.zipをそれにコピーします:
    mkdir -p $WORKDIR/oaaimages
cd $WORKDIR/oaaimages
cp <download_location>/<OAA_Image>.zip .
unzip <OAA_Image>.zip

    これにより、<tar_file_name>.tarファイルが作成されます。

  3. $WORKDIR/oaaimages/oaa-installディレクトリに移動し、インストール・テンプレート・ファイルをinstallOAA.propertiesにコピーします:
    cd $WORKDIR/oaaimages/oaa-install
cp installOAA.properties.template installOAA.properties
  4. 「OAAおよびOARMインストール用のプロパティ・ファイルの準備」に従って、このinstallOAA.propertiesを準備します

3.4 OAAおよびOARMインストール用のプロパティ・ファイルの準備

OAA、OAA-OARMおよびOARMのインストールは、installOAA.propertiesファイルでプロパティを設定してカスタマイズできます。installOAA.propertiesは、管理コンテナのインストール・スクリプトで使用され、管理コンテナ・ポッドのインストール中に<NFS_CONFIG_PATH>にコピーされます。installOAA.propertiesファイルは、後で、OAAまたはOARM(あるいはその両方)をデプロイするときにOAA.shスクリプトに引数として渡されます。「OAAおよびOARMのデプロイ」を参照してください。

次の各項では、installOAA.propertiesで許可されるカスタマイズについて説明します。

3.4.1 共通のデプロイメント構成

この項では、installOAA.propertiesで設定できる共通のデプロイメント構成プロパティについて詳しく説明します。

表3-4 共通のデプロイメント構成

プロパティ 必須/オプション インストール・タイプ 説明
common.dryrun オプション OAA、OAA-OARMおよびOARM 有効にしてtrueに設定すると、helmインストールでは生成された値のみが表示され、KubernetesクラスタでのOAA/OARMインストールは実際には実行されません。

これは、helmコマンドの--dry-run --debugオプションと同等です。

common.deployment.name 必須 OAA、OAA-OARMおよびOARM OAAインストールの名前。これは、helm installコマンドの実行時にはkubernetesクラスタおよびネームスペースごとに一意です。

指定する値は小文字にする必要があります。
common.deployment.overridefile オプション OAA、OAA-OARMおよびOARM チャート・パラメータのオーバーライドに関するオーバーライド・ファイル。helmチャートは、管理コンテナ内のhelmchartsディレクトリにあります。values.yamlに定義されているすべてのパラメータは、有効になっていれば、このファイルでオーバーライドできます。このファイルの形式は、必ずYAMLにする必要があります。管理コンテナ内の~/installsettingsディレクトリに、サンプルのoaaoverride.yamlファイルが存在します。
common.kube.context オプション OAA、OAA-OARMおよびOARM 使用するKubernetesコンテキストの名前。

コンテキストを指定しない場合、デフォルトのKubernetesコンテキストが使用されます。
common.kube.namespace オプション OAA、OAA-OARMおよびOARM OAAデプロイメントを作成するネームスペース。これは、「Kubernetesネームスペースおよびシークレットの作成」で作成したネームスペースである必要があります。パラメータが設定されていない場合は、デフォルト・ネームスペースにデプロイされます。
common.deployment.sslcert 必須 OAA、OAA-OARMおよびOARM OAAインストールで使用されるサーバー証明書のPKCS12ファイルファイル名(cert.p12など)は、「サーバー証明書および信頼証明書の生成」で生成したものと同じファイル名です。これはコンテナ内でマップされる内部パスであるため、PATHは変更しないでください。

ファイルはボールトにシードされ、すべてのOAAマイクロサービスによってダウンロードされます
common.deployment.trustcert 必須 OAA、OAA-OARMおよびOARM OAAインストールで使用される信頼証明書のPKCS12ファイル。ファイル名(trust.p12など)は、「サーバー証明書および信頼証明書の生成」で生成したものと同じファイル名です。これはコンテナ内でマップされる内部パスであるため、PATHは変更しないでください。

ファイルはボールトにシードされ、すべてのOAAマイクロサービスによってダウンロードされます
common.deployment.importtruststore 必須 OAA、OAA-OARMおよびOARM 有効になっている場合、信頼証明書がJREトラストストアにインポートされます。
common.deployment.keystorepassphrase 必須 OAA、OAA-OARMおよびOARM 証明書PKCS12ファイルのパスフレーズ。これは、「サーバー証明書および信頼証明書の生成」でキーストアを作成するときに使用したパスフレーズです。

ここに値を指定しない場合、インストール時に値の入力を求めるプロンプトが表示されます
common.deployment.truststorepassphrase 必須 OAA、OAA-OARMおよびOARM 信頼証明書のPKCS12ファイルのパスフレーズ。これは、「サーバー証明書および信頼証明書の生成」で信頼キーストアを作成するときに使用したパスフレーズです

ここに値を指定しない場合、インストール時に値の入力を求めるプロンプトが表示されます。
common.deployment.generate.secret 必須 OAA、OAA-OARMおよびOARM trueに設定すると、インストールによって3つの対称キーが生成され、パラメータcommon.deployment.sslcertが参照するcert.p12に追加されます。
次の暗号化キーが生成されます:
  • spui-enckey - このキーは、SPUIサービスによって暗号化に使用されます
  • aes256_db_key_alias - このキーは、ナレッジ・ベース認証(KBA).のユーザー質問/回答など、データベースのユーザー・ランタイム情報の暗号化に使用されます
  • aes256_config_key_alias - このキーは、システム関連の構成をすべて暗号化するためのものです
これらのキーを手動で作成する場合は、値をfalseに設定する必要があります。キーを作成するには、次のコマンドを実行します:
keytool -genseckey -alias $keynametouse -keyalg $KEYALGO -keystore $KEYSTORE -storepass $STOREPASS -storetype $STORETYPE -keysize $KEYSIZE
たとえば:
keytool -genseckey -alias spui-enckey -keyalg AES -keystore cert.p12 -storepass <password> -storetype PKCS12 -keysize 256
common.deployment.mode 必須 OAA、OAA-OARMおよびOARM 次の値をinstallOAA.propertiesに設定できます
  • Both - OAAおよびOARMがインストールされます
  • OAA - OAAのみがインストールされます
  • Risk - OARMのみがインストールされます
common.migration.configkey オプション OAA、OAA-OARMおよびOARM Base64でエンコードされた移行システムの構成キー。有効にすると、値がボールトに配置され、レガシー・データの移行に使用されます。これは、Oracle Adaptive Access Manager 11gR2PS3から移行する場合にのみ使用します。
common.migration.dbkey オプション OAA、OAA-OARMおよびOARM Base64でエンコードされた移行システムのデータベース・キー。有効にすると、値がボールトに配置され、データベース・データの移行に使用されます。これは、Oracle Adaptive Access Manager 11gR2PS3から移行する場合にのみ使用します。
common.oim.integration オプション OAAおよびOAA-OARM OIMと統合するには、プロパティをtrueに設定します。これにより、パスワードを忘れた場合の機能も有効になります。これは、Oracle Adaptive Access Manager 11gR2PS3から移行する場合にのみ使用します。
common.deployment.push.apnsjksfile オプション OAAおよびOAA-OARM Appleプッシュ通知サービスのプッシュ・ファクタを有効化する際に使用されるファイル。これを設定する必要があるのは、インストール前にJKSファイルの構成が済んでいる場合のみです。それ以外の場合は、インストール後に構成できます。JKSファイルを<NFS_VAULT_PATH>/ChallengeOMAPUSH/apns/ディレクトリにコピーする必要があります。値は/u01/oracle/service/store/oaa/ChallengeOMAPUSH/apns/APNSCertificate.jksに設定する必要があります。詳細は、「iOSでのOracle Mobile Authenticatorのプッシュ通知の構成」を参照してください。

3.4.2 データベース構成

この項では、installOAA.propertiesで設定できるデータベース構成プロパティについて詳しく説明します。

表3-5 データベース構成

プロパティ 必須/オプション 説明
database.createschema 必須

インストール時にスキーマの作成を可能にします。

これがfalseに設定されている場合、スキーマは作成されません。ただし、このフラグに関係なく、データベース検証が実行されます

database.host 必須 データベースのホスト名またはIPアドレスを指定します。
database.port 必須 データベース・ポートを指定します
database.sysuser 必須 データベースのsysdbaユーザーを指定します
database.syspassword 必須 sysパスワードを指定します。

ここに値を指定しない場合、インストール時に値の入力を求めるプロンプトが表示されます。
database.schema 必須 インストールに使用するデータベース・スキーマの名前を指定します。
database.tablespace 必須 インストールに使用する表領域名を指定します。
database.schemapassword 必須 スキーマ・パスワードを指定します。

ここに値を指定しない場合、インストール時に値の入力を求めるプロンプトが表示されます。
database.svc 必須 データベース・サービス名を指定します
database.name 必須 データベース名を指定します。データベース・サービス名と同じでもかまいません

RACデータベースを使用している場合、このパラメータは必要ありません。

ノート:

SSLを介してOracle Databaseへのセキュアな接続を使用する場合は、追加の構成ステップが必要です。これらのステップは、管理コンテナの起動後、OAAおよびOARMのデプロイの前に実行する必要があります:
  1. データベースのOracleウォレットを取得します:
    1. 標準のOracleデータベースの場合、Oracle Databaseウォレットの検索方法の詳細は、データベース固有のドキュメントを参照してください。
    2. Oracle Autonomous Database on Shared Exadata Infrastructure (ATP-S)データベースの場合、クライアント資格証明のダウンロードに関する項に従います。
  2. OAAデプロイメントで使用される<NFS_CONFIG_PATH>にdb_walletディレクトリを作成します。ウォレット・ファイルを<NFS_CONFIG_PATH>/db_walletディレクトリにコピーします。
  3. OAA管理ポッドのbashシェルに入ります: 
    kubectl exec -n <namespace> -ti <oaamgmt-pod> -- /bin/bash
    たとえば: 
    kubectl exec -n oaans -ti oaamgmt-oaa-mgmt-7dfccb7cb7-lj6sv9 -- /bin/bash
  4. コンテナ内でTNS_ADMIN環境変数を設定します:
    export TNS_ADMIN=<NFS_CONFIG_PATH>/db_wallet
    db_walletディレクトリには、コンテナ内からアクセスできるように、正しい読取りおよび書込みアクセス権限が必要です。
  5. 「OAAおよびOARMのデプロイ」に従ってOAAをデプロイします。

3.4.3 OAM OAuth構成

この項では、installOAA.propertiesで設定できるOAM OAuth構成プロパティについて詳しく説明します。

OAuth用にOAMを構成するための前提条件ステップを実行したことを確認してください。詳細は、「OAM OAuthのインストールおよび構成」を参照してください。

表3-6 OAM OAuth構成

プロパティ 必須/オプション 説明
oauth.enabled 必須

OAA管理ユーザー・インタフェース(UI)およびOAAユーザー・プリファレンスのUIを使用する場合は、OAuthが必要です。

UIへのアクセスが必要な場合は、これをtrueに設定して、OAAインストールでOAuthを有効にする必要があります。

UIにアクセスしない場合は、これをfalseに設定します。oauth.enabled=falseを設定した場合、次のプロパティもfalseに設定し、インストールが失敗しないようにする必要があります:
  • oauth.createdomain
  • oauth.createresource
  • oauth.createclient
oauth.enabled=falseの場合、Optional Configurationで次のパラメータをfalseに設定する必要もあります:
  • install.spui.enabled
  • install.oaa-admin-ui.enabled
  • install.fido.enabled
  • install.oaa-kba.enabled=false
oauth.createdomain オプション OAuthドメインを作成します。

OAuthドメインは、OAuthリソースおよびクライアントの作成に必要です。
oauth.createresource オプション OAuthリソースを作成します。

OAuthリソースは、OAuthクライアントの作成に必要です。
oauth.createclient オプション OAuthクライアントを作成します。

oauth.enabledがtrueに設定されている場合は、OAuthクライアントが必要です。

oauth.domainname

oauth.createdomainがtrueに設定されている場合は必須

 OAuthドメイン名を指定します。これは、「OAM OAuthのインストールおよび構成」に記載されている<DomainName>と同一にする必要があります。
oauth.identityprovider oauth.createdomainがtrueに設定されている場合は必須 OAM OAuthドメインのアイデンティティ・プロバイダを指定します。これは、OAMで使用されるユーザー・アイデンティティ・ストアの名前です。
oauth.clientname

oauth.createclientがtrueに設定されている場合は必須

 インストール時に作成されるOAuthクライアント名を指定します。
oauth.clientgrants oauth.createclientがtrueに設定されている場合は必須 OAuthクライアントのクライアント権限付与を指定します。OAuthクライアントにはCLIENT_CREDENTIALSが必要です。これは、OAuthステータスを確認するために検証ステージで使用されます。使用できるのは次の値です:

"PASSWORD"、"CLIENT_CREDENTIALS"、"JWT_BEARER"、"REFRESH_TOKEN"、"AUTHORIZATION_CODE"、"IMPLICIT"。
oauth.clienttype oauth.createclientがtrueに設定されている場合は必須 OAuthクライアント・タイプを指定します。OAM OAuthでは、次のクライアント・タイプがサポートされます:

PUBLIC_CLIENT、CONFIDENTIAL_CLIENT、MOBILE_CLIENT。

OAA管理コンソールおよびユーザー・プリファレンス・コンソールではOAuthが使用されるため、PUBLIC_CLIENTを使用する必要があります。
oauth.clientpassword oauth.enabled=trueの場合は必須 OAuthクライアントに使用するパスワードを指定します。クライアント・パスワードは正規表現^[a-zA-Z0-9.\-\/+=@_ ]*$に準拠する必要があり、最大長は500です。
oauth.resourcename oauth.enabled=trueの場合は必須 インストール時に作成されるOAuthリソース名を指定します。OAuth設定の検証にも使用されます。
oauth.resourcescope oauth.enabled=trueの場合は必須 インストール時に作成されるOAuthリソース・スコープを指定します。OAuth設定の検証にも使用されます。
oauth.redirecturl oauth.createclientがtrueに設定されている場合は必須 クライアント・リダイレクトURLを指定します。認証後のリダイレクトURLが必要です。これは、アクセス・トークンを生成してOAMのOAuthサービスの構成を検証するために使用されます。
oauth.applicationid oauth.createclientがtrueに設定されている場合は必須 OAuthによって保護されるOAAのアプリケーションID。値には、有効な任意の文字列を指定できます。OAAインストール後のOAMとOAA間のランタイム統合を設定する必要があります。「OAAとOAMとの統合」を参照してください。
oauth.adminurl oauth.enabled=trueの場合は必須 OAuth管理URLを指定します。これはOAM管理サーバーのURLです(例: http://oam.example.com:7001)。
oauth.basicauthzheader oauth.enabled=trueの場合は必須 OAM管理サーバーのBase64でエンコードされた認可ヘッダー。値は、echo -n weblogic:<password> | base64を実行して確認できます。
oauth.identityuri oauth.enabled=trueの場合は必須 アイデンティティ・サーバーのURLで、/.well-known/openid-configurationエンドポイントを使用したOIDCメタデータの取得に使用されます。これは、OAuthサービスのランタイム・サポートを提供するOAM管理対象サーバーのフロントエンドURLです。例: http://ohs.example.com:7777。

3.4.4 ボールト構成

この項では、installOAA.propertiesで設定できるボールト構成プロパティについて詳しく説明します。

OCIボールトを使用している場合は、ファイルベースのボールトに設定するプロパティは無視できます。

表3-7 ボールト構成

プロパティ 説明
vault.deploy.name

このデプロイメントのボールトに使用する名前。名前がボールトにすでに存在する場合は、再利用されます。

vault.create.deploy 値がtrueに設定された場合、ボールトの作成が実行されます。ただし、vault.deploy.nameに指定された名前のボールトがすでに存在する場合、ボールトの作成はスキップされます。
vault.provider ボールトがOCIかファイルベースかを指定します
次のいずれかの値を指定します。
  • fks
  • oci
vault.provider=ociを設定した場合、OCIベースのボールト構成には、次のプロパティが必須です。OCIボールトの作成の詳細は、 ボールトの管理に関する項を参照してください次のパラメータを設定するには、OCIボールトが存在している必要があります。
vault.oci.uasoperator OCIボールトに対する読取りおよび書込み権限を持つユーザーのBase64でエンコードされた秘密キーを指定します。
vault.oci.tenancyId テナンシIDのBase64でエンコードされたOCI IDを指定します。
vault.oci.userId OCIボールトに対する読取りおよび書込み権限を持つユーザーのBase64でエンコードされたOCIDを指定します。
vault.oci.fpId OCIボールトに対する読取りおよび書込み権限を持つユーザーのBase64でエンコードされたフィンガープリントを指定します。
vault.oci.compartmentId OCIにボールトが存在するコンパートメントのBase64でエンコードされたOCIDを指定します。
vault.oci.vaultId OCI上のボールトのBase64でエンコードされたOCIDを指定します。
vault.oci.keyId ボールトのシークレットの暗号化に使用されるOCIボールト内のマスター秘密キーのBase64でエンコードされたOCIDを指定します。
vault.provider=fksを設定した場合、ファイルベースのボールト構成には、次のプロパティが必須です
vault.fks.server <NFS_VAULT_PATH>にNFSサーバーのホスト名またはIPアドレスを指定します。

詳細は、「NFSボリュームの構成」を参照してください。

vault.fks.path ファイル・ベースのボールトを格納する<NFS_VAULT_PATH>を指定します。

詳細は、「NFSボリュームの構成」を参照してください。

vault.fks.key ファイル・ベースのボールトのBase64でエンコードされたパスワードを指定します。パスワードのBase64でエンコードされたバージョンを検索するには、echo -n weblogic:<password> | base64を使用します。
vault.fks.mountpath 管理コンテナのマウント・パスと、ボールトが存在するインストール済サービスのマウント・パス。このプロパティの値は、helmチャートから渡された値と同一にする必要があります。この値は変更しないでください: /u01/oracle/service/store/oaa。

3.4.5 Helmチャート構成

この項では、installOAA.propertiesで設定できるhelmチャート構成プロパティについて詳しく説明します。

これらのプロパティは、インストール時にhelmチャートへの入力として渡されます。

表3-8 Helmチャート構成

プロパティ 必須/オプション 説明
install.global.repo 必須

OAAコンテナ・イメージが存在するコンテナ・イメージ・レジストリを指定します。

詳細は、「コンテナ・イメージ・レジストリ(CIR)のインストール」を参照してください
install.global.testrepo オプション コンテナ・イメージをプルできる代替コンテナ・イメージ・レジストリを指定します。たとえば、OAAは、外部サイト(https://ghcr.io/oracle)からoraclelinux:8-slimおよびoraclelinux7-instantclientイメージをインストールします。Kubernetesクラスタがインターネットにアクセスできない場合は、イメージをプルしてコンテナ・レジストリに格納する必要があります。次に、install.global.testrepoをコンテナ・レジストリの場所に設定する必要があります。
install.riskdb.service.type 必須 データベースがOAAインストールの外部にあるため、このプロパティの値は常にExternalNameに設定する必要があります
install.global.imagePullSecrets\[0\].name 必須 保護されたコンテナ・イメージ・レジストリからコンテナ・イメージをプルするときに使用する必要があるKubernetesシークレット参照を指定します。

ノート:

これは、先に設定したKubernetesシークレット(dockersecretなど)に設定する必要があります。詳細は、「Kubernetesネームスペースおよびシークレットの作成」を参照してください。
install.global.image.tag 必須 グローバル・イメージ・タグをコンテナ・イメージ・レジストリのイメージ・タグに更新します。

ノート:

installOAA.properties.templateをinstallOAA.propertiesにコピーした場合、このタグはすでに設定されています。
install.global.oauth.logouturl オプション OAuthで保護されたリソースのログアウトURLを指定します。これは、OAM管理対象サーバーのフロントエンドURLです。例: http://ohs.example.com:7777/oam/server/logout。oauth.enabledがtrueに設定されている場合にのみ必要です。
install.global.uasapikey 必須 OAAマイクロサービスのRESTエンドポイントの保護に使用されるREST APIキーを指定します。
install.global.policyapikey 必須 OAAポリシー・マイクロサービスのRESTエンドポイントの保護に使用されるREST APIキーを指定します。
install.global.factorsapikey 必須 OAAファクタ・マイクロサービスのRESTエンドポイントの保護に使用されるREST APIキーを指定します。
install.global.riskapikey オプション OAAリスク・マイクロサービスのRESTエンドポイントの保護に使用されるREST APIキーを指定します。

OAA-OARMインストールまたはOARMのみのインストールを実行する場合、このパラメータは必須です。
OCIボールトの場合、helmのインストール時に読取り専用ユーザーに対して指定すると、次の構成をオーバーライドできます。次のプロパティに値を指定しない場合、値はボールト構成から選択されます。
install.global.vault.mapId オプション 既存のボールトの場合は、Base64 mapIdを指定できます。プロパティが設定されている場合は、ボールト内のデプロイ情報に対して検証されます。
install.global.vault.oci.uasoperator オプション ボールトに対する読取り専用権限を持つユーザーのBase64でエンコードされた秘密キーを指定します。
install.global.vault.oci.tenancyId オプション OCIからのBase64でエンコードされたテナンシIDを指定します
install.global.vault.oci.userId オプション OCIからのBase64でエンコードされたユーザーIDを指定します。
install.global.vault.oci.fpId オプション OCIからのユーザーのBase64でエンコードされたフィンガープリントIDを指定します。

3.4.6 オプションの構成

この項では、installOAA.propertiesで設定できるオプションの構成プロパティについて詳しく説明します。

プロパティ 必須/オプション 説明
install.global.ingress.enabled オプション このプロパティは、デプロイメントでイングレスを有効化するかどうかを指定するために使用します。値がtrueに設定されている場合、デプロイメントのKubernetesクラスタ内のイングレス・リソースが生成されます。純粋なNodePortベースのデプロイメントが必要な場合は、値をfalseに設定する必要があります。
install.global.ingress.runtime.host オプション ランタイム・ホストのイングレス定義に使用するホスト名を指定できます。プロパティの値がない場合、イングレス定義は'*'ホストを使用して作成されます。

ランタイム・ホストは、すべてのfactors、oaa、spuiおよびriskを含むランタイム・サービスへのアクセスに使用されます。
install.global.ingress.admin.host オプション 管理ホストのイングレス定義に使用するホスト名を指定できます。プロパティの値がない場合、イングレス定義は'*'ホストを使用して作成されます。

管理ホストは、admin、policyおよびrisk-ccサービスへのアクセスに使用されます。
install.global.dbhost

install.global.dbport

install.global.dscredentials

install.global.dbservicename

 オプション これらのプロパティはデータベースに関連しています。ここでプロパティを指定しない場合は、データベース構成で指定された値が使用されます。
install.global.oauth.oidcidentityuri

install.global.oauth.oidcaudience

install.global.oauth.oidcclientid

 オプション 次のプロパティはOAuthに関連しています。ここで指定されない場合は、OAuth構成で指定された値が使用されます。
install.global.serviceurl オプション ロード・バランサ/イングレスURLが存在する場合は、URLをここで構成します。すべてのUIサービスは、このロード・バランサ/イングレスの背後に位置します。イングレス・インストールがtrueに設定されている場合、イングレスのインストール後に適切なサービスURLがフェッチされて、サービスURLとして使用されます。install.global.serviceurlを指定すると、このプロパティのサービスURLの優先度が高くなり、元の値がオーバーライドされます。
install.oaa-admin-ui.serviceurl オプション oaa管理のサービスURL (install.global.serviceurlと異なる場合)。
install.spui.enabled=false

install.fido.enabled=false

install.oaa-admin-ui.enabled=false

install.oaa-kba.enabled=false

 オプション oauth.enabled=falseの場合、OAA管理コンソール(OAA-admin-ui)、ユーザー・プリファレンス・コンソール(spui)およびFIDO (FIDO)およびKBA (OAA-KBA)ファクタは使用できません。oauth.enabled=falseの場合、これらのプロパティをコメント解除する必要があります。

common.deployment.mode=Riskの場合、次のサービスはデプロイされません: fido、push、yotp、email、sms、totpおよびkba。

install.totp.enabled=false

install.push.enabled=false

install.sms.enabled=false

install.yotp.enabled=false

install.email.enabled=false

   認証ファクタ・サービスはデフォルトで有効になっています。無効にするには、行をコメント解除します。

common.deployment.mode=Riskの場合、次のサービスはデプロイされません: fido、push、yotp、email、sms、totpおよびkba。

install.service.type=NodePort

install.oaa-admin-ui.service.type=NodePort

install.oaa-policy.service.type=NodePort

install.spui.service.type=NodePort

install.totp.service.type=NodePort

install.fido.service.type=NodePort

install.push.service.type=NodePort

install.email.service.type=NodePort

install.sms.service.type=NodePort

install.yotp.service.type=NodePort

install.risk.service.type=NodePort

install.oaa-kba.service.type=NodePort

install.risk.riskcc.service.type=NodePort

 オプション サービスのデフォルト・サービス・タイプはNodePortです。

デプロイメント・モードがRiskの場合、次のサービスはデプロイされません: fido、push、yotp、email、sms、totpおよびkba。

install.global.ingress.enabled=trueの場合、これらのパラメータをすべてコメント・アウトする必要があります。

イングレスを使用したインストールの詳細は、「NGINXイングレスを使用したOAAおよびOARMのインストール」を参照してください

3.4.7 イングレス構成

この項では、installOAA.propertiesで設定できるイングレス構成プロパティについて詳しく説明します。

表3-9 イングレス構成

プロパティ 必須/オプション 説明
ingress.install 必須

OAAまたはOARMインストールでイングレス・コントローラをインストールする場合は、値をtrueに設定します。

イングレス・コントローラをインストールしない場合は、falseに設定します。

これがtrueに設定されている場合は、Optional Configurationでinstall.global.ingress.enabled=trueも設定する必要があります。

ingress.namespace inress.install=trueの場合は必須です イングレスのインストールに使用されるKubernetesネームスペース。このネームスペースは、インストール時にKubernetesに作成されます。たとえば、ingress-nginxです。
ingress.admissions.name=ingress-nginx-controller-admission inress.install=trueの場合はオプションです

アドミッション・コントローラの名前。

アドミッション・コントローラは個別にインストールできます。

イングレスのアドミッション名が存在しない場合は、NGINXイングレス・チャートでcontroller.admissionWebhooks.enabledがfalseに設定されます。

ingress.class.name=ingress-nginx-class inress.install=trueの場合は必須です インストールに使用する必要があるイングレス・クラス名。既存のクラス名にはできません。
ingress.service.type inress.install=trueの場合は必須です

ベア・メタルKubernetesクラスタを使用している場合は、値をNodePortに設定します。イングレス・コントローラは、動的に割り当てられたポート上にあるクラスタのいずれかのノードをリスニングします。

Kubernetesクラスタの管理対象サービス(Oracle Cloud Infrastructure (OCI)上のOracle Kubernetes Engine (OKE)など)を使用している場合は、値をLoadBalancerに設定します。これにより、管理対象サービスは、トラフィックをNGINXイングレスに送信するようロード・バランサを設定します。

ingress.install.releaseNameOverride=base inress.install=trueの場合はオプションです ingress.installで始まるあらゆるものは、イングレス・チャートの値を設定するために追加で指定できます。

イングレスを使用したインストールの詳細は、「NGINXイングレスを使用したOAAおよびOARMのインストール」を参照してください

3.4.8 管理コンテナ構成

この項では、installOAA.propertiesで設定できる管理コンテナ構成プロパティについて詳しく説明します。

表3-10 管理構成

プロパティ 必須/オプション 説明
install.mount.config.path 必須

<NFS_CONFIG_PATH>の値を構成のNFSマウント・パスに設定します。

install.mount.config.server 必須 <NFS_CONFIG_PATH>のNFSサーバーのIPアドレス。
install.mount.creds.path 必須

<NFS_CREDS_PATH>の値を資格証明のNFSマウント・パスに設定します。

install.mount.creds.server 必須 <NFS_CREDS_PATH>のNFSサーバーのIPアドレス。
install.mount.logs.path 必須

<NFS_LOGS_PATH>の値をログのNFSマウント・パスに設定します。

install.mount.logs.server 必須 <NFS_LOGS_PATH>のNFSサーバーのIPアドレス。
install.mgmt.release.name オプション helm installコマンドの実行時に使用されるOAA管理コンテナ・インストールの名前。設定しない場合、インストール時に名前の入力を求めるプロンプトが表示されます。

指定する値は小文字にする必要があります。
install.kube.creds オプション この値は、kubeconfigが存在するローカルPATHに設定します。設定しない場合、管理コンテナはKubernetes資格証明に$KUBECONFIGまたは~/.kube/configを使用します。
common.local.sslcert 必須 この値は、サーバー証明書PKCS12ファイル(cert.p12)が存在するローカルPATHに設定します。
common.local.trustcert 必須 この値は、信頼証明書PKCS12ファイル(trust.p12)が存在するローカルPATHに設定します。

NFSマウントの詳細は、「NFSボリュームの構成」を参照してください

PKCS12ファイルの詳細は、「サーバー証明書および信頼証明書の生成」を参照してください

3.5 管理コンテナの実行

installManagementContainer.shスクリプトを実行して、管理コンテナを作成します。

  1. インストール・ファイルをダウンロードしたノードで、$WORKDIR/oaaimages/oaa-installディレクトリに移動します:
    cd $WORKDIR/oaaimages/oaa-install
  2. 引数を指定してinstallManagementContainer.shスクリプトを実行します。たとえば:
    ./installManagementContainer.sh -t ./<oaa-image>.tar
    次の表に、installManagementContainer.shの引数の完全なリストを示します:
    コマンドライン引数 必須 説明
    -t いいえ OAAイメージtarファイルへのパス。
    使用方法:
    • 指定しない場合、コンテナ・イメージ・レジストリに対するpull、tagおよびpushは実行されません。
    • プル、タグおよびプッシュが必要な場合は、-t ./oaa-latest.tarのように、イメージ<oaa-image.tar>へのパスを指定する必要があります。
    • インストール・スクリプトは、このタスクを実行するためにまずpodmanの使用を試み、見つからない場合はDockerを使用します(使用可能な場合)。podmanもDockerも使用できない場合、スクリプトは終了します。
    -c いいえ OAA管理helmチャートへのパス。

    指定しない場合、スクリプトはパスとして./charts/oaa-mgmtを使用します。

    -d いいえ インストールのhelmテスト実行を実行します。
    -f いいえ installOAA.propertiesへのパス。

    指定しない場合、./installOAA.propertiesが使用されます。

    -v いいえ スクリプトを冗長モードで実行します。
    -p いいえ OAA管理コンテナの環境でhttp/httpsプロキシを設定します。

    デフォルトでは、プロキシは設定されません。指定した場合、スクリプトはその環境を使用して、使用するプロキシ構成を見つけます。
    -e いいえ OAA管理コンテナの/etc/hostsにエントリを追加します。

    デフォルトでは、エントリは追加されません。指定した場合、スクリプトは情報の入力を要求します。
    -n いいえ プロンプトを表示しません

    デフォルトでは、このスクリプトはOAA管理チャートをインストールするために必要な情報の入力を要求し、インストールの1つのステージから次のステージに進みます。

    このオプションを設定した場合、スクリプトでは欠落している情報の入力を要求したり、ステージとステージの間にプロンプトを表示したりしません。必要な情報が欠落している場合は、エラーで終了します。
    -u いいえ インストールではなく更新を実行します。

    デフォルトでは、このスクリプトは、以前にインストールされたhelmチャートを検索して、インストールを実行するかアップグレードを実行するかを決定します。

    インストールの進行中、様々な質問に回答して特定のタスクを実行するように求められます。次の表に、回答を求められる質問または実行を求められるタスクの一部について概説します:

    出力 アクション
    Use 'podman login' to login into your private registry if you have not done so previously.Login successful? [Y/N]:

    ノート:

    Dockerを使用している場合は、前述の出力にdocker loginと表示されます。
    		イメージを格納するプライベート・コンテナ・イメージ・レジストリ(CIR)でログインが必要な場合は、podman loginまたはdocker loginを使用してCIRにログインし、プロンプトが表示されたら資格証明を入力します:
    podman login <container-registry.example.com>
    または: 
    docker login <container-registry.example.com>
    Would you like to specify a kube context (otherwise 'kubernetes-admin@kubernetes' will be used)? [Y/N]: クラスタに複数のkubeコンテキストがある場合は、使用するコンテキストを選択できます。「Y」を選択した場合は、使用するコンテキストを入力する必要があります。選択されているデフォルト・コンテキストを使用する場合、またはkube構成にコンテキストが1つしかない場合は、「N」を選択します。

    ノート:

    インストール中に表示されるプロンプトのほとんどは字義どおりなので、前述の表にすべてのプロンプトの完全なリストは含まれていません。
    管理コンテナのインストールが完了すると、次のような出力が表示されます:
    NAME: oaamgmt
LAST DEPLOYED: <DATE>
STATUS: deployed
REVISION: 1
TEST SUITE: None
Waiting 15 secs for OAA mgmt deployment to start...
Executing 'kubectl get pods oaamgmt-oaa-mgmt-7dfccb7cb7-lj6sv -n oaans'...
NAME                                READY   STATUS              RESTARTS   AGE
oaamgmt-oaa-mgmt-7dfccb7cb7-lj6sv   0/1     ContainerCreating   0          15s
Waiting 15 secs for OAA mgmt deployment to run...
Executing 'kubectl get pods oaamgmt-oaa-mgmt-7dfccb7cb7-lj6sv -n oaans'...
NAME                                READY   STATUS              RESTARTS   AGE
oaamgmt-oaa-mgmt-7dfccb7cb7-lj6sv   0/1     ContainerCreating   0          30s
Waiting 15 secs for OAA mgmt deployment to run...
Executing 'kubectl get pods oaamgmt-oaa-mgmt-7dfccb7cb7-lj6sv -n oaans'...
NAME                                READY   STATUS              RESTARTS   AGE
oaamgmt-oaa-mgmt-7dfccb7cb7-lj6sv   0/1     ContainerCreating   0          46s
Waiting 15 secs for OAA mgmt deployment to run...
Copying OAA properties file to oaans/oaamgmt-oaa-mgmt-7dfccb7cb7-lj6sv:/u01/oracle/scripts/settings
Generating kube config for OAA mgmt pod 'oaans/oaamgmt-oaa-mgmt'.
Using service account 'oaans/oaamgmt-oaa-mgmt'.
Using token name 'oaamgmt-oaa-mgmt-token-5m88n'.
Using cluster URL 'https://<URL>'.
Cluster "oaa-cluster" set.
User "oaa-service-account" set.
Context "kubernetes-admin@kubernetes" created.
Switched to context "kubernetes-admin@kubernetes".
Copying OAA kube config files to oaans/oaamgmt-oaa-mgmt-7dfccb7cb7-lj6sv:/u01/oracle/scripts/creds...
Using helm config '/home/opc/.config/helm/repositories.yaml'.
Copying helm config to oaans/oaamgmt-oaa-mgmt-7dfccb7cb7-lj6sv:/u01/oracle/scripts/creds/helmconfig
Copying certificates to oaans/oaamgmt-oaa-mgmt-7dfccb7cb7-lj6sv:/u01/oracle/scripts/creds
Use command 'kubectl exec -n oaans -ti oaamgmt-oaa-mgmt-7dfccb7cb7-lj6sv -- /bin/bash' to get a shell to the OAA mgmt pod.
From pod shell, use command 'kubectl get pods' to verify communication with the cluster.
Continue OAA installation from the OAA mgmt pod.
OAA management installation complete.
  3. 出力に従ってOAA管理ポッドに接続します。次に例を示します:
    kubectl exec -n oaans -ti oaamgmt-oaa-mgmt-7dfccb7cb7-lj6sv9 -- /bin/bash
    これにより、OAA管理ポッド内のBashシェル内に移動します:
    [oracle@oaamgmt-oaa-mgmt-7dfccb7cb7-lj6sv /]$

次のステップ: OAAおよびOARMのデプロイ

3.6 OAAおよびOARMのデプロイ

OAAおよびOARMをデプロイする前に、必ず「管理コンテナの実行」の手順を完了しておきます。

OAA、OAA-OARMまたはOARMのデプロイ

  1. OAA管理ポッドのBashシェルに入ります(まだ入っていない場合):
    kubectl exec -n <namespace> -ti <oaamgmt-pod> -- /bin/bash
    たとえば:
    kubectl exec -n oaans -ti oaamgmt-oaa-mgmt-7dfccb7cb7-lj6sv9 -- /bin/bash
  2. OAA管理ポッドのBashシェル内で、OAA.shスクリプトを実行して、OAA、OAA-OARMまたはOARMをデプロイします:
    cd ~
./OAA.sh -f installOAA.properties

    ノート:

    これにより、<NFS_CONFIG_PATH>のinstallOAA.propertiesが使用されます。

次のステップ: インストールが成功すると、「デプロイメントの詳細の出力」のような出力が表示されます。

3.7 デプロイメントの詳細の出力

デプロイメントが完了すると、次の情報がコンソールに出力されます

ノート:

OAA/OARMに付属のイングレス・コントローラをインストールする場合、ホストおよびポートはコントローラがインストールされるワーカー・ノードに設定されます。独自のイングレス・コントローラを使用している場合、基本設定であると想定すると、ホストおよびポートはinstallOAA.propertiesのプロパティinstall.global.serviceurlの値に設定されます。

イングレスが無効になっている場合は、ワーカー・ノードのホストおよびNodePortが出力されます。

############################OAA Deployment Details: START###################################
OAAService=https://oaainstall-host/oaa/runtime
AdminUrl=https://oaainstall-host/oaa-admin
PolicyUrl=https://oaainstall-host/oaa-policy
SpuiUrl=https://oaainstall-host/oaa/rui
Email=https://oaainstall-host/oaa-email-factor
Push=https://oaainstall-host/oaa-push-factor
Fido=https://oaainstall-host/fido
SMS=https://oaainstall-host/oaa-sms-factor
TOTP=https://oaainstall-host/oaa-totp-factor
YOTP=https://oaainstall-host/oaa-yotp-factor
KBA=https://oaainstall-host/oaa-kba
RELEASENAME=oaainstall
# Key below is Base64 encoded API key
oaaapikey=YXBpa2V5dG9iZXNldGR1cmluZ2luc3RhbGxhdGlvbgo=
# Key below is Base64 encoded Policy API key
oaapolicyapikey=cG9sYXBpa2V5dG9iZXNldGR1cmluZ2luc3RhbGxhdGlvbgo=
# Key below is Base64 encoded Factor API key
oaafactorapikey=ZmFjdG9yYXBpa2V5dG9iZXNldGR1cmluZ2luc3RhbGxhdGlvbgo=
############################Deployment Details: END###################################
OAA-OARMおよびOARMインストールの場合、Riskのデプロイメント詳細もコンソールに出力されます:
############################Risk Deployment Details: START###################################
AdminUrl=https://oaainstall-host/oaa-admin
PolicyUrl=https://oaainstall-host/oaa-policy
RISK=https://oaainstall-host/risk-analyzer
RISKCC=https://oaainstall-host/risk-cc
RELEASENAME=riskinstall
# Key below is Base64 encoded Policy API key
oaapolicyapikey=cG9sYXBpa2V5dG9iZXNldGR1cmluZ2luc3RhbGxhdGlvbgo=
# Key below is Base64 encoded Factor API key
riskfactorapikey=cmlza2ZhY3RvcmFwaWtleXRvYmVzZXRkdXJpbmdpbnN0YWxsYXRpb24K
############################Deployment Details: END###################################
デプロイメント情報を再出力する必要がある場合:
  1. OAA管理ポッドのBashシェルに入ります(まだ入っていない場合):
    kubectl exec -n <namespace> -ti <oaamgmt-pod> -- /bin/bash
    たとえば:
    kubectl exec -n oaans -ti oaamgmt-oaa-mgmt-7d7597c694-vn4ds -- /bin/bash
  2. printOAADetails.shを実行して、デプロイメントの詳細を出力します:
    cd ~/scripts
./printOAADetails.sh -f settings/installOAA.properties

    ノート:

    これにより、<NFS_CONFIG_PATH>のinstallOAA.propertiesが使用されます。

出力されたデプロイメントの情報に基づいて、コンソールには次のようにアクセスできます:

コンソール 詳細出力参照* URL ユーザー名 パスワード
OAA/OARM管理 AdminUrl https://<hostname.domain>:<port>/oaa-admin oaadmin OAM OAuthアイデンティティ・ストアに設定されている<password>。
OAAユーザー・プリファレンス SpuiUrl https://<hostname.domain>:<port>/oaa/rui OAM OAuthアイデンティティ・ストアからのユーザー名。 OAM OAuthアイデンティティ・ストアに設定されている<password>。

*このドキュメント全体を通して、「詳細出力参照」列の値は使用するURLを示すために使用されます。たとえば、「ブラウザを起動して<AdminURL>にアクセスする」は、示された対応するURL https://<hostname.domain>:<port>/oaa-adminにアクセスすることを示します。

出力されたデプロイメントの情報に基づいて、REST APIエンドポイント情報は次のようになります:

REST API 詳細出力参照** URL ユーザー名** パスワード**
OAA/OARM管理 PolicyUrl https://<hostname.domain>:<port>/oaa-policy <RELEASENAME>-oaa-policy <Base64Decoded(oaapolicyapikey)>
OAAランタイム OAAService https://<hostname.domain>:<port>/oaa/runtime <RELEASENAME>-oaa <Base64Decoded(oaaapikey)>
リスク RISK https://<hostname.domain>:<port>/risk-analyzer <RELEASENAME>-risk <Base64Decoded(riskfactorapikey)>
リスク・カスタマ・ケア RISKCC https://<hostname.domain>:<port>/risk-cc <RELEASENAME>-risk-cc <Base64Decoded(riskfactorapikey)>
KBA KBA https://<hostname.domain>:<port>/oaa-kba <RELEASENAME>_OAA_KBA <Base64Decoded{ oaafactorsapikey}>

**このドキュメント全体を通して、REST APIの例が示されている場合、「詳細出力参照」列の値は使用するURLを示すために使用され、「ユーザー名」列と「パスワード」列の値は使用するユーザー名とパスワードを表します。

たとえば: 
curl --location -g --request POST '<OAAService>/preferences/v1' \
--header 'Content-Type: application/json' \
--header 'Authorization: Basic <Base64Encoded(<username>:<password>)>' 
etc...
<OAAService>は、対応するURL https://<hostname.domain>:<port>/oaa/runtimeにアクセスすることを示し、<username>は<RELEASENAME>-oaaを示し、<password>は<Base64Decoded(oaaapikey)>を示します。
前述の詳細を使用してREST APIにアクセスする方法の詳細は、次を参照してください:

3.8 インストール後のステップ

トピック

3.8.1 すべてのインストールのインストール後のステップ

すべてのインストール・タイプ(OAAのみ、OAA-OARMおよびOARMのみ)について、インストール後のステップに従います。

次のステップを実行して、ポリシー・スナップショットをインポートします:

  1. ドキュメントID 2723908.1を参照して、My Oracle Supportから最新のスナップショット・ポリシー・ファイルを取得します。

    ノート:

    最新のスナップショット・ファイルを入手できない場合は、管理コンテナ内の/u01/oracle/scripts/oarm-12.2.1.4.1-base-snapshot.zipファイルを使用します。
  2. 最新のスナップショット・ファイルを<NFS_CONFIG_PATH>にコピーします。
  3. <NFS_CONFIG_PATH>/installOAA.propertiesを編集し、次のパラメータをCommon Deployment構成の一番下に追加します:
    common.deployment.import.snapshot=true
common.deployment.import.snapshot.file=/u01/oracle/scripts/settings/<latest_snapshot>.zip

    ノート:

    最新のスナップショット・ファイル・セットを使用していない場合: common.deployment.import.snapshot.file=/u01/oracle/scripts/settings/oarm-12.2.1.4.1-base-snapshot.zip
  4. OAA管理ポッドのBashシェルに入ります(まだ入っていない場合):
    kubectl exec -n <namespace> -ti <oaamgmt-pod> -- /bin/bash
    たとえば:
    kubectl exec -n oaans -ti oaamgmt-oaa-mgmt-7dfccb7cb7-lj6sv9 -- /bin/bash
  5. Bashシェル内で次のコマンドを実行して、ポリシー・スナップショットをインポートします:
    cd ~/scripts
./importPolicySnapshot.sh -f settings/installOAA.properties

    ノート:

    これにより、<NFS_CONFIG_PATH>のinstallOAA.propertiesが使用されます。

    スナップショットがインポートされ、成功すると、メッセージSuccessfully applied snapshot: 10001(または類似のメッセージ)が表示されます。

    Bashシェルを終了します。

  6. <NFS_CONFIG_PATH>/installOAA.propertiesを編集し、Common Deployment構成の一番下にある次のパラメータを変更します:
    common.deployment.import.snapshot=false

    ノート:

    これは、将来のアップグレード中にポリシーが上書きおよび消去されないようにするための重要なステップです。

3.8.2 OAA-OARMおよびOARMインストールのインストール後のステップ

これらのインストール後のステップは、OAA-OARMおよびOARMのみのインストールで実行してください。

oaa.browser.cookie.domainおよびoaa.risk.integration.postauth.cpの設定

ノート:

以降のステップは、OAA-OARMのインストールにのみ適用されます。

デバイスCookieを収集するには、プロパティoaa.browser.cookie.domainをOAAホスト・ドメインに設定する必要があります。たとえば、https://oaa.example.comでOAAにアクセスできる場合は、値をoaa.example.comに設定します。

リスクのあるIP、地理的速度、地理的位置などのユースケースに対するリスク・ルールを呼び出すには、プロパティoaa.risk.integration.postauth.cpをpostauthに設定する必要があります。

  1. 次のようにプロパティを設定します:

    <PolicyUrl>/policy/config/property/v1 REST APIを使用してプロパティを設定します。たとえば: 

    curl --location -g --request PUT '<PolicyUrl>/policy/config/property/v1' \
--header 'Content-Type: application/json' \
--header 'Authorization: Basic <Base64Encoded(<username>:<password>)>' \
--data '[
    {
        "name": "oaa.browser.cookie.domain",
        "value": "<host.domain>"                
    },
    {
        "name": "oaa.risk.integration.postauth.cp",
        "value": "postauth"    
    }
]'

    ノート:

    この場合は、<PolicyUrl>から/oaa-policyを削除します。たとえば、https://<host>:<port>/oaa-policy/policy/config/property/v1ではなくhttps://<host>:<port>/policy/config/property/v1を使用します

    PolicyUrlの検索および認証の詳細は、「OAA管理API」を参照してください。

    構成プロパティRESTエンドポイントの詳細は、「構成プロパティRESTエンドポイント」を参照してください。

3.8.3 NodePort用のインストール後のステップ

どのインストール・タイプでも、イングレスではなくnodeportを使用している場合は、関連するリダイレクトURLでOAuthクライアントを更新する必要があります。次のステップを実行します。

  1. 「デプロイメントの詳細の出力」の説明に従って、spui、oaa-admin-uiおよびfidoポッドのURLを検索します。次に例を示します:
    AdminUrl=https://worker1.example.com:32701/oaa-admin
SpuiUrl=https://worker1.example.com:32721/oaa/rui
Fido=https://worker1.example.com:30414/fido

    ノート:

    OARMのみのインストールの場合、検索する必要があるのはoaa-admin-uiポッドのURLのみです。
  2. コマンドを使用して、OAM管理者ユーザーとそのパスワードをエンコードします:
    echo -n <username>:<password> | base64
    たとえば: 
    echo -n weblogic:<password> | base64
    この値は、次の例の<ENCODED_OAMADMIN>に使用する必要があります。
  3. OAAおよびOAA-OARMインストールの場合は、次のようにREST APIを使用してOAuthクライアントを更新します:
    curl --location --request PUT 'http://<OAuth_Host>:<OAuth_Port>/oam/services/rest/ssa/api/v1/oauthpolicyadmin/client?name=OAAClient' \
--header 'Content-Type: application/json' \
--header 'Authorization: Basic <ENCODED_OAMADMIN>' \
--data '{
    "id": "OAAClient",
    "clientType": "PUBLIC_CLIENT",
    "idDomain": "OAADomain",
    "name": "OAAClient",
    "redirectURIs": [
        {
            "url": "https://worker1.example.com:32701/oaa/rui",
            "isHttps": true
        },
        {
            "url": "https://worker1.example.com:32701/oaa/rui/oidc/redirect",
            "isHttps": true
        },
        {
            "url": "https://worker1.example.com:32721/oaa-admin",
            "isHttps": true
        },
        {
            "url": "https://worker1.example.com:32721/oaa-admin/oidc/redirect",
            "isHttps": true
        },
        {
            "url": "https://worker1.example.com:30414/fido",
            "isHttps": true
        },
        {
            "url": "https://worker1.example.com:30414/fido/oidc/redirect",
            "isHttps": true
        }
    ]
}'

    ノート: REST APIの詳細は、『Oracle Access ManagerでのOauth REST API』を参照してください

    OARMのみのインストールの場合は、次のようにしてOAuthクライアントを更新します:
    curl --location --request PUT 'http://<OAuth_Host>:<OAuth_Port>/oam/services/rest/ssa/api/v1/oauthpolicyadmin/client?name=OAAClient' \
--header 'Content-Type: application/json' \
--header 'Authorization: Basic <ENCODED_OAMADMIN>' \
--data '{
    "id": "OAAClient",
    "clientType": "PUBLIC_CLIENT",
    "idDomain": "OAADomain",
    "name": "OAAClient",
    "redirectURIs": [
      {
            "url": "https://worker1.example.com:32721/oaa-admin",
            "isHttps": true
        },
        {
            "url": "https://worker1.example.com:32721/oaa-admin/oidc/redirect",
            "isHttps": true
        }
    ]
}'

3.9 OAAおよびOARMのインストールのトラブルシューティング

この項では、OAAおよびOARMのインストールに関するトラブルシューティングのヒントを示します。

OAA管理コンテナのインストール中のPodmanの問題

  • イメージまたはファイル形式のエラーのために、Podmanがtarファイル内のOAAイメージをロードできません。たとえば:
    Storing signatures
Getting image source signatures
Copying blob 01092b6ac97d skipped: already exists
Copying blob dba9a6800748 skipped: already exists
Copying blob bae273a35c58 skipped: already exists
Copying blob 7f4b55b885b0 skipped: already exists
Copying blob 93e8a0807a49 skipped: already exists
Copying blob fa5885774604 skipped: already exists
Copying blob 3b8528487f10 skipped: already exists
Copying blob 3a1c2e3e35f4 [==========================>-----------] 213.8MiB / 298.1MiB
Copying blob 6d31843e131e [=================================>----] 210.5MiB / 236.5MiB
Copying blob f35b9630ef38 [===========>--------------------------] 213.8MiB / 672.2MiB
Copying blob ef894c2768e3 done
Copying blob 846fd069f886 [==========>---------------------------] 197.7MiB / 672.2MiB
Copying blob 257c48b76c82 done
Error: payload does not match any of the supported image formats (oci, oci-archive, dir, docker-archive)
    原因として、インストール・ホストのルート・パーティションの空き領域が不足している(Podmanは一時ファイルを/var/tmpに格納する)か、Podmanバージョンが3.3.0以降でないことが考えられます。このエラーが発生した場合は、問題に対処した後で、/var/tmp下のすべてのファイルを削除してから、インストールを再試行してください。
  • 権限の問題のために、Podmanがtarファイル内のOAAイメージをロードできません。たとえば:
    Using image release files ./releaseimages.txt and ./nonreleaseimages.txt...
tee: ./oaainstall-tmp/run.log: Permission denied
Using install settings from ./installOAA.properties.
tee: ./oaainstall-tmp/run.log: Permission denied
Checking kubectl client version...
WARNING: version difference between client (1.23) and server (1.21) exceeds
the supported minor version skew of +/-1
tee: ./oaainstall-tmp/run.log: Permission denied
kubectl version required major:1 minor:18, version detected major:1 minor:23
tee: ./oaainstall-tmp/run.log: Permission denied

    原因として、あるユーザーとしてzipファイルを抽出したが、権限のない別のユーザーとしてinstallManagementContainer.shを実行したことが考えられます。この場合は、$WORKDIR/oaaimages/oaa-install/oaainstall-tmpディレクトリを削除して、zipファイルを抽出したユーザーと同じユーザーでインストールを再試行してください。

  • Podmanは、前回のインストール試行でOAAイメージのロードに失敗した後、必要なすべてのイメージのプル/タグ/プッシュを実行しません。この場合は、$WORKDIR/oaaimages/oaa-install/oaainstall-tmpディレクトリを削除して再試行してください。

OAA管理チャートのインストールの失敗

OAA管理チャートのインストールが次のエラーで失敗した場合:
Executing 'helm install ...  oaamgmt charts/oaa-mgmt'.
Continue? [Y/N]:
y
Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: ValidationError(Deployment.spec.template.spec.containers[0]): unknown field "volumMounts" in io.k8s.api.core.v1.Container
OAA管理チャートのマニフェスト・ファイルが破損した可能性があります。installOAA.properties、cert.p12およびtrust.p12を安全な場所にコピーし、インストール・ディレクトリ$WORKDIR/oaaimages/oaa-installを削除してから、<OAA_Image>.zipを抽出してインストールを再開します。

インストール・スクリプトがOAA管理コンテナ・ポッドの起動を待ってタイムアウトしました

次のエラーが表示される場合があります。
NAME                                     READY   STATUS              RESTARTS   AGE
oaamgmt-oaa-mgmt-74c9ff789d-wq82h   0/1     ContainerCreating   0          2m3s
Waiting 15 secs for OAA mgmt deployment to run...
Executing 'kubectl get pods oaamgmt-oaa-mgmt-74c9ff789d-wq82h -n oaans'...
NAME                                     READY   STATUS              RESTARTS   AGE
oaamgmt-oaa-mgmt-74c9ff789d-wq82h   0/1     ContainerCreating   0          2m18s
Waiting 15 secs for OAA mgmt deployment to run...
...
OAA mgmt pod is not running after 450 secs, cannot proceed with install.
Critical error, exiting. Check ./oaainstall-tmp/run.log for additional information.
この場合は、次のコマンドを実行して追加情報を取得してください:
$ kubectl get pods -n oaans
$ kubectl describe pod oaamgmt-<pod> -n oaans
  • NFSのエラーの場合は、installOAA.propertiesのNFSボリューム情報が正しいことを確認します。この場合は、kubectl describeで次のように表示されます:
    Output: mount.nfs: mounting <ipaddress>:/scratch/oaa/scripts-creds failed, reason given by server: No such file or directory
  Warning  FailedMount  15s  kubelet, <ipaddress>  Unable to attach or mount volumes: unmounted volumes=[oaamgmt-oaa-mgmt-configpv oaamgmt-oaa-mgmt-credpv oaamgmt-oaa-mgmt-logpv], unattached volumes=[oaamgmt-oaa-mgmt-configpv oaamgmt-oaa-mgmt-credpv oaamgmt-oaa-mgmt-logpv oaamgmt-oaa-mgmt-vaultpv default-token-rsh62]: timed out waiting for the condition
  • イメージ・プル・エラーの場合は、イメージ・プル・シークレット(dockersecret)が正しく作成され、installOAA.propertiesのプロパティinstall.global.repo、install.global.image.tagおよびinstall.global.imagePullSecrets\[0\].nameが正しいことを確認します。この場合は、kubectl describe podで次のように表示されます:
    Warning  Failed     21s (x3 over 61s)  kubelet, <ipaddress>  Error: ErrImagePull
Normal   BackOff    7s (x3 over 60s)   kubelet, <ipaddress>  Back-off pulling image "container-registry.example.com/oracle/shared/oaa-mgmt:<tag>"
Warning  Failed     7s (x3 over 60s)   kubelet, <ipaddress>  Error: ImagePullBackOff
  • 明らかなエラーがなくタイムアウトする場合、クラスタでOAA管理イメージのダウンロードに時間がかかりすぎている可能性があります。この場合、管理ポッドは最終的に起動されますが、インストールは中止されます。これが発生した場合は、helm delete oaamgmt -n oaansを使用してOAA管理helmリリースを削除し、インストール・スクリプトを再実行します。

OAA.shの実行中の一般的な失敗

インストール中のどこかのステージでOAA.shデプロイメントが失敗した場合、通常は問題を修正してOAA.shを再実行できます。インストールでは、データベース、OAuthおよびボールトに対して多数のチェックが実行されます。データベース・スキーマ、OAuth構成またはボールトがすでに存在するために、これらのチェックでOAA.shの再実行に失敗する場合は、installOAA.propertiesで次のプロパティを設定してから、OAA.shを再試行してください:
  • データベース・スキーマがすでに存在する場合:
    • database.createschema=false
  • OAuth構成がすでに存在する場合:
    • oauth.createdomain=false
    • oauth.createresource=false
    • oauth.createclient=false
  • ボールト構成が存在する場合:
    • vault.create.deploy=false

OAA.shの実行中にOAuthの作成に失敗する

インストール時に、OAuthドメイン、クライアントおよびリソース・サーバーが作成されます。失敗した場合は、OAuthのパラメータが正しいかどうかを確認します「OAM OAuthのインストールおよび構成」を参照してください

OAA.shの実行中にOAuthの作成に失敗する

これは、httpd.confおよびmod_wl_ohs.confファイルが更新されない場合に発生します。値を更新するには、「OAM OAuthのインストールおよび構成」を参照してください

コンテナ作成中ステータスのポッドが原因でOAA.shのインストールに失敗する

ログを確認するには、次のコマンドを実行します。たとえば:
kubectl logs oaainstall-email-6fd7c9b9dd-lr5lm
エラーに関する必要な詳細がログに記録されていない場合は、describe podコマンドを実行します。たとえば:
kubectl describe pod oaainstall-email-6fd7c9b9dd-lr5lm

OAA.shの実行中にポッドの起動に失敗し、CrashLoopBackOffが表示される

エラーが表示されたポッドに対してkubectl logs <pod>コマンドを実行します。エラーの原因の1つとして、次のことが考えられます:

そのエントリのmod_wl_ohs.confのPathTrimおよびPathPrependが更新されなかったため、ポッドはhttp://www.example.oracle.com:7791/.well-known/openid-configurationに接続できませんでした。「OAM OAuthのインストールおよび構成」を参照してください

OAA.shのインストールがタイムアウトしたのにポッドが実行中と表示される

OAAインストールがタイムアウトしたのに、OAAポッドにエラーが表示されず、最終的に実行中状態になった場合、クラスタでOAAイメージのダウンロードに時間がかかりすぎていた可能性があります。この場合、OAAポッドは最終的に起動されますが、インストールは完了しません。これが発生した場合は、インストールをクリーン・アップし、インストール・スクリプトを再実行します。

kubectlで"Unable to connect to the server: net/http: TLS handshake timeout"と報告される

考えられる原因は次のとおりです:
  • プロキシは環境で定義されていますが、no_proxy環境変数にクラスタ・ノードが含まれていません。この問題を解決するには、クラスタ・ノードのIPまたはホスト名をno_proxy環境変数に追加する必要があります。
  • kube構成ファイル~/.kube/configまたは/etc/kubernetes/admin.confが無効です。

クリーンアップ中にOAuthからOAAドメインを削除できない

ドメイン内のすべてのクライアントおよびリソースをリストし、1つずつ削除してから、ドメインを削除します:
  1. コマンドを使用して、OAM管理者ユーザーとそのパスワードをエンコードします:
    echo -n <username>:<password> | base64
    たとえば: 
    echo -n weblogic:<password> | base64
    この値は、次の例の<ENCODED_OAMADMIN>に使用する必要があります。
  2. 次を実行します:
    $ curl --location --request DELETE 'http://<OAuth_Host>:<OAuth_port>/oam/services/rest/ssa/api/v1/oauthpolicyadmin/oauthidentitydomain?name=OAADomain' \
--header 'Authorization: Basic <ENCODED_OAMADMIN>'
OAuth Identity Domain is not empty. Kindly remove (resource/client) entities from identity domain
$ curl --location --request GET 'http://<OAuth_Host>:<OAuth_port>/oam/services/rest/ssa/api/v1/oauthpolicyadmin/client?identityDomainName=OAADomain' --header 'Content-Type: application/json' --header 'Authorization: Basic <ENCODED_OAMADMIN>'
$ curl --location --request GET 'http://<OAuth_Host>:<OAuth_port>/oam/services/rest/ssa/api/v1/oauthpolicyadmin/application?identityDomainName=OAADomain' --header 'Content-Type: application/json' --header 'Authorization: Basic <ENCODED_OAMADMIN>'

3.10 インストールのクリーン・アップ

OAAまたはOAA-OARMインストールを完全にクリーン・アップするには、次のステップを実行します。

  1. インストール・ホストから管理コンテナに接続し、ファイル・ベースのボールトおよびログをそれぞれのNFSマウントから削除します:
    kubectl exec -n <namespace> -ti oaamgmt-oaa-mgmt-7d7597c694-tzzdz -- /bin/bash
$ rm -rf /u01/oracle/logs/*
$ rm -rf /u01/oracle/service/store/oaa/.*
$ exit
  2. 次を実行して、インストールされているhelmチャートを検索します:
    helm ls -n <namespace>
    たとえば:
    helm ls -n oaans
    出力は次のようになります:
    NAME            NAMESPACE       REVISION        UPDATED   STATUS          CHART                 APP VERSION
oaainstall      oaans           1               <date>    deployed        oaa-1.0.0-<tag>       0.1.0
oaamgmt         oaans           1               <date>    deployed        oaa-mgmt-1.0.0-<tag>  0.1.0
    OAAチャートを削除します:
    helm delete oaainstall -n oaans
helm delete oaamgmt -n oaans
  3. coherence-operatorを削除するには、次のステップを実行します:
    helm delete coherence-operator -n coherence
    kubectl get sts
    kubectl get coherence.coherence.oracle.com
    kubectl delete mutatingwebhookconfigurations coherence-operator-mutating-webhook-configuration
  4. コンテナの外部で、次を実行します:
    kubectl get pods -n oaans
    kubectl get pods -n coherence
    ポッドが残っている場合は、次を実行します:
    kubectl delete <pod_name> -n <namespace>
  5. OAuthクライアントおよびリソースを削除します:
    1. コマンドを使用して、OAM管理者ユーザーとそのパスワードをエンコードします:
      echo -n <username>:<password> | base64
      たとえば: 
      echo -n weblogic:<password> | base64
      この値は、次の例の<ENCODED_OAMADMIN>に使用する必要があります。
    2. OAuthクライアントを更新します。たとえば:
      curl --location --request DELETE 'http://<OAuth_Host>:<OAuth_port>/oam/services/rest/ssa/api/v1/oauthpolicyadmin/client?name=OAAClient&identityDomainName=OAADomain' \
--header 'Authorization: Basic <ENCODED_OAMADMIN>'
    3. OAuthリソース・サーバーを削除します。たとえば:
      curl --location --request DELETE 'http://<OAuth_Host>:<OAuth_port>/oam/services/rest/ssa/api/v1/oauthpolicyadmin/application?name=OAAResource&identityDomainName=OAADomain' \
--header 'Authorization: Basic <ENCODED_OAMADMIN>'
    4. OAuthドメインを削除します。たとえば:
      curl --location --request DELETE 'http://<OAuth_Host>:<OAuth_port>/oam/services/rest/ssa/api/v1/oauthpolicyadmin/oauthidentitydomain?name=OAADomain' \
--header 'Authorization: Basic <ENCODED_OAMADMIN>'
  6. 次のようにデータベース・スキーマを削除します:
    sqlplus sys/<password> as SYSDBA

alter session set "_oracle_script"=TRUE; ** Required for PDB’s only **

drop user <OAA_RCU_PREFIX>_OAA cascade;
delete from SCHEMA_VERSION_REGISTRY where comp_name='Oracle Advanced Authentication' and OWNER=UPPER('<OAA_RCU_PREFIX>_OAA');

commit;

set pages 0
set feedback off
spool /tmp/drop_directories.sql
select 'drop directory '||directory_name||';' from all_directories where directory_name like 'EXPORT%'
/
spool off
@/tmp/drop_directories
  7. OAAイメージのプル/タグ/プッシュを繰り返すためには、ディレクトリ$WORKDIR/oaaimages/OAA-install/oaainstall-tmpを削除してから、installManagementContainer.shスクリプトを再実行します。