20 Installing and Configuring Oracle Identity Role Intelligence
Oracle Identity Role Intelligence (OIRI) authenticates using users and groups defined in Oracle Identity Governance. Therefore, you have to install and configure Oracle Identity Governance first.
See Configuring Oracle Identity Governance Using WDT. Unlike the traditional Oracle Identity and Access Management products, Oracle Identity Role Intelligence is deployed as a series of microservices.
In this release, Oracle uses a standalone container image to install and configure OIRI. The container image is started manually in the Kubernetes cluster.
This chapter includes the following topics:
- About Oracle Identity Role Intelligence
OIRI is used by system administrators to perform role mining operations. - Variables Used in this Chapter
The later sections of this chapter provide instructions to create a number of files. These sample files contain variables which you need to substitute with values applicable to your deployment. - Characteristics of the OIRI Installation
This section lists the key characteristics of the OIRI installation that you are about to create. Review these characteristics to understand the purpose and context of the procedures that are used to configure OIRI. - Kubernetes Services
If you are using NodePort Services, the Kubernetes services 'oiri-nodeport' and 'oiri-ui-nodeport' are created as part of the OIRI installation. If you are using Ingress, an Ingress service will be created. - Before You Begin
Before you begin the installation, you have to ensure that all the required tasks listed in this topic are complete. - Setting Up a Product Specific Work Directory
Before you begin the installation, you should have downloaded and staged the Oracle Identity Governance container image and the code repository. - Creating User Names and Groups in Oracle Identity Governance
Oracle Identity Role Intelligence authenticates using users and groups in Oracle Identity Governance. Before you start configuring OIRI, log in to the OIG Self Service Console using thehttps://prov.example.com/identityURL to create the required user names and groups. - Ensuring that OIG Compliance Mode is Enabled
For OIRI to function, ensure that the compliance functionality is enabled for OIG. - Creating Kubernetes Namespaces
The Kubernetes namespaces are used to store all the OIRI objects. - Creating Container Registry Secrets
If you are using a container registry and want to pull the Oracle container images on demand, you must create a secret which contains the login details of the container registry. - Creating a Kubernetes Secret for Docker Hub Images
This secret allows Kubernetes to pull an image fromhub.docker.comwhich contains third-party images such ashelm,kubectl, andlogstashcommands. These commands are used by the OUD cron job to test for pods that are stuck in the 'Terminating' state, and restart them if necessary. - Starting the Administration CLI
Before starting the Administration CLI, ensure that you have created the persistent volumes. - Granting the CLI Access to the Kubernetes Cluster
The OIRI CLI container has built-in commands to interact with the Kubernetes cluster. You must provide the Administration CLI with details on how to access the Kubernetes cluster. - Creating the Configuration Files
OIRI uses a number of property files to deploy OIRI. These property files are populated using the CLI commands. - Creating the OIRI Keystore
Create a keystore in OIRI using thekeytoolcommand. This command should be run from the ORI-CLI container. - Loading the OIG Certificates into OIRI
For OIRI to trust OIG, you should load the OIG certificate into OIRI. - Creating Wallets
OIRI stores database/OIG connection information in a wallet. You have to create the wallet by running the command from inside the OIRI-CLI pod. - Creating the Database Schemas
Create the OIRI database schemas in the database by running the commands from the OIRI-CLI container. - Verifying the Wallet
After creating the wallet, you should validate the wallet. If the validation fails, correct the wallet before you proceed. - Deploying OIRI Using Helm
After creating the namespaces, you can now deploy OIRI using the generated Helm chart. You should execute the command from the OIRI-CLI. - Verifying that OIRI is Running
After you deploy OIRI, you should verify that it is running successfully. - Creating the Kubernetes NodePort Services
By default, OIRI gets created with all the components configured asClusterIPservices. The configuration indicates that the Oracle Identity Role Intelligence components are visible only within the Kubernetes cluster. - Updating the OHS Configuration
If you have not already done so, you should now add the OIRI entries to the Oracle HTTP configuration. - Performing an Initial Data Load Using the Data Ingester
After OIRI is up and running, you may want to perform an initial data load from the OIG database.
Parent topic: Configuring the Enterprise Deployment
About Oracle Identity Role Intelligence
OIRI is used by system administrators to perform role mining operations.
- Oracle Identity Role Intelligence Management Container (OIRI-CLI)
- Oracle Identity Role Intelligence (OIRI) Microservice
- Oracle Identity Role Intelligence User Interface (OIRI-UI) Microservice
- Oracle Identity Role Intelligence Data Ingester (OIRI-DING) Microservice
OIRI uses a dedicated database because it can process large amount of data in a way that is different from the OAM/OIG data stores. It uses a data warehouse model rather than OnLine Transaction Processing (OLTP).
Variables Used in this Chapter
The later sections of this chapter provide instructions to create a number of files. These sample files contain variables which you need to substitute with values applicable to your deployment.
Variables are formatted as <VARIABLE_NAME>. The following table provides the values you should set for each of these variables.
Table 20-1 The Variables to be Changed
| Variable | Sample Value | Description |
|---|---|---|
|
<REGISTRY_ADDRESS> |
|
The location of the registry. |
|
<REGISTRY_SECRET_NAME> |
|
The name of the Kubernetes secret containing the container registry credentials. Required only if you are pulling images directly from a container registry. See Creating Container Registry Secrets. |
|
<REG_USER> |
|
The name of the user you use to log in to the registry. |
|
<REG_PWD> |
<password> |
The registry user password. |
|
<OIRI_CLI_REPOSITORY> |
|
The name of the OIRI CLI software repository. If you have downloaded and staged a container image,
this value will be: If you use the Oracle container registry, the value
will be
If you use a container registry, the value will be
the name of the registry with the product name:
|
|
<OIRICLI_VER> |
|
The version of the image you want to use. |
|
<OIRI_REPOSITORY> |
|
The name of the OIRI software repository. If you have downloaded and staged a container image,
this value will be: If you use the Oracle container registry, the value
will be
If you use a container registry, the value will be
the name of the registry with the product name:
|
|
<OIRI_VER> |
|
The version of the OIRI image you want to use. |
|
<OIRI_DING_REPOSITORY> |
|
The name of the OIRI DING software repository. If you have downloaded and staged a container image,
this value will be: If you use the Oracle container registry, the value
will be
If you use a container registry, the value will be
the name of the registry with the product name:
|
|
<OIRIDING_VER> |
|
The version of the image you want to use. |
|
<OIRI_UI_REPOSITORY> |
|
The name of the OIRI UI software repository. If you have downloaded and staged a container image,
this value will be: If you use the Oracle container registry, the value
will be
If you use a container registry, the value will be
the name of the registry with the product name:
|
|
<OIRIUI_VER> |
|
The version of the image you want to use. |
|
<PVSERVER> |
|
The name or IP address of the NFS server hosting the persistent volumes. |
|
<OIRINS> |
|
The name of the OIRI namespace you are using to hold the OIRI objects.. |
|
<DINGNS> |
|
The name of the OIRI DING namespace you are using to hold the DING objects. |
|
<WORKDIR> |
|
The working directory for OIRI. |
|
<OIRI_SHARE> |
|
The NFS mount location for the OIRI persistent volume. |
|
<OIRI_SHARE_SIZE> |
|
The size of the NFS share. |
|
<OIRI_DING_SHARE> |
|
The NFS mount location for the OIRI Ding persistent volume. |
|
<OIRI_DING_SHARE_SIZE> |
|
The size of the NFS share. |
|
<OIRI_WORK_SHARE> |
|
The NFS mount of the OIRI Work persistent volume. |
|
<OIRI_NFS_SHARE> |
|
The NFS share mount point for OIRI persistent volume. |
|
<OIG_DB_SCAN> |
|
Database host of the OIG database. Use the SCAN address if you use a RAC database. |
|
<OIG_DB_LISTENER> |
|
Listener port of the Oracle Identity Governance database. |
|
<OIG_DB_SERVICE> |
|
Name of the database service for the OIG database. |
|
<OIRI_DB_SCAN> |
|
Database host of the OIRI database. Use the SCAN address if using a RAC database. |
|
<OIRI_DB_SYS_PWD> |
<password> |
The OIRI database sys password. |
|
<OIRI_DB_LISTENER> |
|
Listener port of the OIRI database. |
|
<OIRI_DB_SERVICE> |
|
Name of the database service for the OIRI database. |
|
<OIRI_RCU_PREFIX> |
|
The database schema prefix you want to assign to the OIRI database schema objects. |
|
<OIRI_SCHEMA_PWD> |
|
The password you want to assign to the OIRI schemas. |
|
<OIG_RCU_PREFIX> |
|
The prefix you used when you created the OIG schemas. |
|
<OIG_SCHEMA_PWD> |
|
The password associated with the
|
|
<USE_INGRESS> |
|
If you want the installation to create an Ingress controller in the OIRI namespace, set this value to true. If you are using your own Ingress controller or NodePort, set this to value to false. |
|
<OIRI_INGRESS_HOST> |
|
Set this value to the OIRI load balancer virtual host name. If you use OIRI standalone, this value will be the name of an OIRI virtual host that you have defined specifically for OIRI. If you are deploy this host as part of an Integrated Oracle Identity and Access Management deployment (containers or otherwise), you can use the existing virtual host for your Oracle Identity Governance administration operations. |
|
<OIRI_REPLICAS> |
|
The number of OIRI servers to start. A minimum of two servers is required for HA. |
|
<OIRI_UI_REPLICAS> |
|
The number of OIRI UI servers to start. A minimum of two servers is required for HA. |
|
<OIRI_DING_REPLICAS> |
|
The number of DING servers to start. A minimum of two servers is required for HA. |
| <OIRI_KEYSTORE_PASSWORD> |
|
The password you used when you imported the OIG REST certificate. See Importing the OIG REST Certificate into OIRI. |
|
<OIRI_SERVICE_USER> |
|
The user name of the service you have created. See Creating the OIRI Service User. |
|
<OIRI_SERVICE_PWD> |
|
The password assigned to the <OIRI_SERVICE_USER> account. |
|
<OIRI_K8> |
|
The Kubernetes service port of the OIRI NodePort service. |
|
<OIRI_UI_K8> |
|
The Kubernetes service port of the OIRI-UI NodePort Service. |
|
<CERT_FILE> |
|
The name of the certificate file. |
|
<K8_URL> |
|
The URL of the Kubernetes API. You can obtain the URL by using the following command on the admin host:
|
|
<CERTIFICATE_FILE > |
|
The location of the |
|
<OIGNS> |
|
The namespace used by OIG. |
|
<OIG_DOMAIN_NAME> |
|
The name of the OIG domain. |
|
<OIG_LBR_HOST> |
|
The load balancer entry point for OIM. |
|
<OIG_LBR_PORT> |
|
The load balancer port for OIM. |
|
<OIG_URL> |
http://igdinternal.example.com:7777 http://governancedomain-cluster-oim-clusteroigns.svc.cluster.local:14000 |
This is the URL of the OIG installation. OIRI does not need to exit the organization. So it is fine to use the internal call back URL. If your OIG installation is inside the same Kubernetes cluster as your OIG deployment, you can use the internal service name which looks as follows:
|
|
<ELK_HOST> |
|
The host and port of the centralized Elasticsearch deployment. This host can be inside the Kubernetes cluster or external to it. This host is used only when Elasticsearch is used. |
|
<ELK_VER> |
|
The version of Elasticsearch you want to use. |
Characteristics of the OIRI Installation
This section lists the key characteristics of the OIRI installation that you are about to create. Review these characteristics to understand the purpose and context of the procedures that are used to configure OIRI.
Table 20-2 Key Characteristics of the OIRI Installation
| Characteristics of OIRI | More Information |
|---|---|
|
Each microservice is deployed into a pod in the Kubernetes cluster. |
|
|
Places the OIRI components in a dedicated Kubernetes namespace. |
|
|
Places the DING components in a dedicated namespace, although these could be combined with the OIRI namespace if desired. |
|
|
Uses the Kubernetes services to interact with microservices. |
|
|
Uses the Kubernetes persistent volumes to hold configuration information. |
See unresolvable-reference.html#GUID-CF07EE44-34D9-4F36-97BE-6B3FBB4FCEA8. |
|
Each Kubernetes pod is built from a pre-built Oracle container image. |
See Identifying and Obtaining Software Distributions for an Enterprise Deployment. |
|
Requires Oracle Identity Governance to be installed and configured. |
|
| Installation can be standalone or integrated. |
See unresolvable-reference.html#GUID-62F73C7C-55E9-4E1E-9D2A-AE35749DC11D. |
Kubernetes Services
If you are using NodePort Services, the Kubernetes services
'oiri-nodeport' and 'oiri-ui-nodeport' are created as
part of the OIRI installation. If you are using Ingress, an Ingress service will be
created.
Table 20-3 Kubernetes NodePort Services
| Service Name | Type | Service Port | Mapped Port |
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
Table 20-4 Ingress Service
| Service Name | Host Name |
|---|---|
|
|
|
Before You Begin
Before you begin the installation, you have to ensure that all the required tasks listed in this topic are complete.
- The required Oracle container images staged on each of the Kubernetes worker
nodes, or hosted in a container registry to which you have access.
The following Oracle container images have to be staged:
- OIRI-CLI
- OIRI
- OIRI-UI
- OIRI-DING
- Configured Oracle HTTP Server as described in Installing and Configuring Oracle HTTP Server.
- Configured Oracle Unified Directory as describer in Installing and Configuring Oracle Unified Directory.
- Configured Oracle Identity Governance as described in Configuring Oracle Identity Governance Using WDT.
- Added the missing OAM policies for OIRI as described in Adding the Missing Policies to OAM.
Setting Up a Product Specific Work Directory
This section describes copying the downloaded sample deployment scripts to a temporary working directory on the configuration host for OIRI.
- Create a temporary working directory as the install user. The install
user should have
kubectlaccess to the Kubernetes cluster.mkdir -p /<WORKDIR>For example:mkdir -p /workdir/OIRI - Change directory to this
location:
cd /workdir/OIRI
Creating User Names and Groups in Oracle Identity Governance
Oracle Identity Role Intelligence authenticates using users and groups in
Oracle Identity Governance. Before you start configuring OIRI, log in to the OIG
Self Service Console using the
https://prov.example.com/identity URL to create the
required user names and groups.
- OIRI Service Account
- OIRI User Account
- OIRI Group
Ensuring that OIG Compliance Mode is Enabled
For OIRI to function, ensure that the compliance functionality is enabled for OIG.
- Log in to the OIG Sysadmin Console using the
http://igdadmin.example.com/sysadminURL. - Click Configuration Properties.
- Search for the system property with the keyword:
OIG.IsIdentityAuditorEnabled. - Edit the property and ensure that it is set to true. If not, amend the value to true and click Save.
Creating Kubernetes Namespaces
The Kubernetes namespaces are used to store all the OIRI objects.
Use the following commands to create separate namespaces for OIRI and DING.
kubectl create namespace <OIRINS>kubectl create namespace <DINGNS>For example:
kubectl create namespace oirinskubectl create namespace dingnsCreating Container Registry Secrets
If you are using a container registry and want to pull the Oracle container images on demand, you must create a secret which contains the login details of the container registry.
This step is not required if you have staged the container images locally.
kubectl create secret -n <OIRINS> docker-registry <REGISTRY_SECRET_NAME> --docker-server=<REGISTRY_ADDRESS> --docker-username=<REG_USER> --docker-password=<REG_PWD>kubectl create secret -n oirins docker-registry regcred --docker-server=iad.ocir.io/mytenancy --docker-username=mytenancy/oracleidentitycloudservice/myemail@email.com --docker-password=<password>To create a container registry secret for OIRI DING, use the following command:
kubectl create secret -n <DINGNS> docker-registry <REGISTRY_SECRET_NAME> --docker-server=<REGISTRY_ADDRESS> --docker-username=<REG_USER> --docker-password=<REG_PWD>kubectl create secret -n dingns docker-registry regcred --docker-server=iad.ocir.io/mytenancy --docker-username=mytenancy/oracleidentitycloudservice/myemail@email.com --docker-password=<password>Creating a Kubernetes Secret for Docker Hub Images
This secret allows Kubernetes to pull an image from
hub.docker.com which contains third-party images such as helm, kubectl, and
logstash commands. These commands are used by the OUD cron job to test
for pods that are stuck in the 'Terminating' state, and restart them if
necessary.
You should have an account on hub.docker.com. If you
want to stage the images in your own repository, you can do so and modify the
helm override file as appropriate.
To create a Kubernetes secret for hub.docker.com, use the following
command:
$ kubectl create secret docker-registry dockercred --docker-server="https://index.docker.io/v1/" --docker-username="<DH_USER>" --docker-password="<DH_PWD>" --namespace=<OUDNS>$ kubectl create secret docker-registry dockercred --docker-server="https://index.docker.io/v1/" --docker-username="username" --docker-password="<mypassword>" --namespace=oudnsStarting the Administration CLI
Before starting the Administration CLI, ensure that you have created the persistent volumes.
See Creating File Systems and Mount Targets.
To start the Administration CLI:
Granting the CLI Access to the Kubernetes Cluster
The OIRI CLI container has built-in commands to interact with the Kubernetes cluster. You must provide the Administration CLI with details on how to access the Kubernetes cluster.
To provide access, perform the following steps on any node which has a working
kubectl command:
Creating a Kubernetes Service Secret
kubectl create -f <WORKDIR>/create_svc_secret.yamlkubectl create -f /workdir/OIRI/create_svc_secret.yaml<WORKDIR>/create_svc_secret.yaml has the following
content:apiVersion: v1
kind: Secret
type: kubernetes.io/service-account-token
metadata:
name: oiri-service-account
namespace: <OIRINS>
annotations:
kubernetes.io/service-account.name: "oiri-service-account" Parent topic: Granting the CLI Access to the Kubernetes Cluster
Creating a Kubernetes Service Account
workdir/oiri/create_svc.yaml file for the Kubernetes
service account in the OIRI namespace by using the following
command:kubectl apply -f <WORKDIR>/create_svc.yamlkubectl apply -f /workdir/OIRI/create_svc.yamlcreate_svc.yaml file has the following
content:apiVersion: v1
kind: ServiceAccount
metadata:
name: oiri-service-account
namespace: <OIRINS>
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: oiri-ns-role
namespace: <OIRINS>
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: ding-ns-role
namespace: <DINGNS>
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: oiri-clusterrolebinding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: system:persistent-volume-provisioner
subjects:
- namespace: <OIRINS>
kind: ServiceAccount
name: oiri-service-account
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: oiri-clusteradmin
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- namespace: <OIRINS>
kind: ServiceAccount
name: oiri-service-account
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: oiri-rolebinding
namespace: <OIRINS>
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: oiri-ns-role
subjects:
- namespace: <OIRINS>
kind: ServiceAccount
name: oiri-service-account
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: ding-rolebinding
namespace: <DINGNS>
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: ding-ns-role
subjects:
- namespace: <OIRINS>
kind: ServiceAccount
name: oiri-service-accountapiVersion: v1
kind: ServiceAccount
metadata:
name: oiri-service-account
namespace: oirins
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: oiri-ns-role
namespace: oirins
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: ding-ns-role
namespace: dingns
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: oiri-clusterrolebinding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: system:persistent-volume-provisioner
subjects:
- namespace: oirins
kind: ServiceAccount
name: oiri-service-account
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: oiri-clusteradmin
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- namespace: oirins
kind: ServiceAccount
name: oiri-service-account
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: oiri-rolebinding
namespace: oirins
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: oiri-ns-role
subjects:
- namespace: oirins
kind: ServiceAccount
name: oiri-service-account
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: ding-rolebinding
namespace: dingns
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: ding-ns-role
subjects:
- namespace: oirins
kind: ServiceAccount
name: oiri-service-accountParent topic: Granting the CLI Access to the Kubernetes Cluster
Generating the
ca.crt Certificate
Obtain the Kubernetes certificate using the following commands:
Set up the environment variables for the OIRI namespace, and a working directory.
OIRINS=<OIRINS>
WORKDIR=/workdir/OIRITOKENNAME=`kubectl -n $OIRINS get serviceaccount/oiri-service-account -o jsonpath='{.secrets[0].name}'`TOKENNAME=oiri-service-accountTOKEN=`kubectl -n $OIRINS get secret $TOKENNAME -o jsonpath='{.data.token}'| base64 --decode`kubectl -n $OIRINS get secret $TOKENNAME -o jsonpath='{.data.ca\.crt}'| base64 --decode > $WORKDIR/ca.crtParent topic: Granting the CLI Access to the Kubernetes Cluster
Creating a Kubernetes Configuration File for OIRI
Generate a Kubernetes configuration file to tell OIRI how to interact with
kubectl. To do this perform the following steps:
Set up environment variables for the OIRI namespace, and a working directory.
OIRINS=<OIRINS>
WORKDIR=/workdir/OIRITOKEN=`kubectl -n $OIRINS get secret $TOKENNAME -o jsonpath='{.data.token}'| base64 --decode`K8URL=`grep server: $KUBECONFIG | sed 's/server://;s/ //g'`kubectl config --kubeconfig=$WORKDIR/oiri_config set-cluster oiri-cluster --server=$K8URL --certificate-authority=$WORKDIR/ca.crt --embed-certs=truekubectl config --kubeconfig=$WORKDIR/oiri_config set-credentials oiri-service-account --token=$TOKENkubectl config --kubeconfig=$WORKDIR/oiri_config set-context oiri --user=oiri-service-account --cluster=oiri-clusterkubectl config --kubeconfig=$WORKDIR/oiri_config use-context oiriThese commands generate a file called oiri_config in the
<WORKDIR> location. This file contains the Kubernetes cluster
details.
Parent topic: Granting the CLI Access to the Kubernetes Cluster
Copying Files to the OIRI-CLI Container
Copy the ca.crt (see Generating the ca.crt Certificate) and oiri_config (see Creating a Kubernetes Configuration File for OIRI) files to the OIRI-CLI container, using the following
commands:
OIRINS=<OIRINS>
WORKDIR=/workdir/OIRIkubectl cp $WORKDIR/ca.crt $OIRINS/oiri-cli:/app/k8skubectl cp $WORKDIR/oiri_config $OIRINS/oiri-cli:/app/k8s/configoiri-cli, run the following
command:chmod 400 /app/k8s/configParent topic: Granting the CLI Access to the Kubernetes Cluster
Validating the
kubectl Command
Validate that the kubectl command works from inside
the Kubernetes container by using the following command from the OIRI-CLI container.
kubectl get pod -n $OIRINSkubectl get pod -n oirinsThe command should show you the running oiri-cli pod.
Parent topic: Granting the CLI Access to the Kubernetes Cluster
Creating the Configuration Files
OIRI uses a number of property files to deploy OIRI. These property files are populated using the CLI commands.
Run the following steps from inside the OIRI-CLI container.
Creating the Setup Configuration Files
/oiri-cli/scripts/setupConfFiles.sh -m prod \
--oigdbhost <OIG_DB_SCAN> \
--oigdbport <OIG_DB_LISTENER> \
--oigdbsname <OIG_DB_SERVICE> \
--oiridbhost <OIRI_DB_SCAN> \
--oiridbport <OIRI_DB_LISTENER> \
--oiridbsname <OIRI_DB_SERVICE> \
--sparkmode k8s \
--dingnamespace <DINGNS> \
----dingimage <OIRI_DING_REPOSITORY>:<OIRIDING_VER> \
--cookiesecureflag false \
--k8scertificatefilename <CERTIFICATE_FILE> \
--sparkk8smasterurl k8s://<K8_URL> \
--oigserverurl <OIG_URL>/oiri-cli/scripts/setupConfFiles.sh -m prod \
--oigdbhost db-scan.example.com \
--oigdbport 1521 \
--oigdbsname oig_s.example.com \
--oiridbhost db-scan.example.com \
--oiridbport 1521 \
--oiridbsname oiri_s.example.com \
--sparkmode k8s \
--dingnamespace dingns \
--dingimage oiri-ding:12.2.1.4.02106 \
--cookiesecureflag false \
--k8scertificatefilename ca.crt \
--sparkk8smasterurl k8s://https://10.0.0.10:6443 \
--http://governancedomain-cluster-oim-cluster.oigns.svc.cluster.local:14000INFO: OIG DB as source for ETL is true
INFO: Setting up /app/data/conf/config.yaml
INFO: Setting up /app/data/conf/data-ingestion-config.yaml
INFO: Setting up /app/data/conf/custom-attributes.yaml
INFO: Setting up /app/oiri/data/conf/application.yaml
INFO: Setting up /app/oiri/data/conf/authenticationConf.yaml
INFO: Setting up /app/data/conf/dbconfig.yamlls /app/data/confconfig.yaml custom-attributes.yaml data-ingestion-config.yaml dbconfig.yamlParent topic: Creating the Configuration Files
Creating the Helm Configuration File
OIRI is deployed using helm. To create a configuration file for
helm, run the following command inside the OIRI-CLI
container.
/oiri-cli/scripts/setupValuesYaml.sh \
--oiriapiimage <OIRI_REPOSITORY>:<OIRI_VER> \
--oirinamespace <OIRINS> \
--oirinfsserver <PVSERVER> \
--oirireplicas <OIRI_REPLICAS> \
--oiriuireplicas <OIRI_UI_REPLICAS> \
--sparkhistoryserverreplicas <OIRI_DING_REPLICAS> \
--oirinfsstoragepath <OIRI_NFS_SHARE> \
--oirinfsstoragecapacity <OIRI_SHARE_SIZE> \
--oiriuiimage <OIRI_UI_REPOSITORY>:<OIRIUI_VER> \
--dingimage <OIRI_DING_REPOSITORY>:<OIRIDING_VER> \
--dingnamespace <DINGNS> \
--dingnfsserver <PVSERVER> \
--dingnfsstoragepath <OIRI_DING_SHARE> \
--dingnfsstoragecapacity <OIRI_DING_SHARE_SIZE> \
--ingressenabled <USE_INGRESS> \
--ingresshostname <OIRI_INGRESS_HOST> \
--sslenabled false/oiri-cli/scripts/setupValuesYaml.sh \
--oiriapiimage oiri:12.2.1.4.02106 \
--oirinamespace oirins \
--oirinfsserver 1.1.1.1 \
--oirireplicas 2 \
--oiriuireplicas 2 \
--sparkhistoryserverreplicas 2 \
--oirinfsstoragepath /exports/iampvs/oiripv \
--oirinfsstoragecapacity 10Gi \
--oiriuiimage oiri-ui:12.2.1.4.02106 \
--dingimage oiri-ding:12.2.1.4.02106 \
--dingnamespace dingns \
--dingnfsserver 1.1.1.1 \
--dingnfsstoragepath /exports/iampvs/dingpv \
--dingnfsstoragecapacity 10Gi \
--ingressenabled false \
--ingresshostname igdadmin.example.com \
--sslenabled falseVerify that the /app/k8s/values.yaml file is created.
Parent topic: Creating the Configuration Files
Creating the OIRI Keystore
Create a keystore in OIRI using the keytool command. This
command should be run from the ORI-CLI container.
keytool -genkeypair -alias oiri -keypass <OIRI_KEYSTORE_PWD> -keyalg RSA \
-keystore /app/oiri/data/keystore/keystore.jks \
-storepass <OIRI_KEYSTORE_PWD> -storetype pkcs12 \
-dname \"CN=Unknown, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown\" \
-nopromptLoading the OIG Certificates into OIRI
For OIRI to trust OIG, you should load the OIG certificate into OIRI.
Complete the following steps to load the certificates:
Obtaining the OIG REST Certificate
To obtain the OIG rest certificate (this is different from the regular OIG certificate), you should run the commands from inside the OIG Administration Server container.
To obtain the OIG rest certificate:
Parent topic: Loading the OIG Certificates into OIRI
OIG Running Inside Kubernetes
You must run the commands inside Kubernetes.
Parent topic: Obtaining the OIG REST Certificate
Importing the OIG REST Certificate into OIRI
keytool -import \
-alias xell \
-file /app/k8s/xell.pem \
-keystore /app/oiri/data/keystore/keystore.jks\
-storepass <OIRI_KEYSTORE_PWD> -nopromptParent topic: Loading the OIG Certificates into OIRI
Obtaining the OIG SSL Certificate
In addition to the OIG REST certificate, you should also trust the OIG SSL Certificate. This certificate is assigned to the load balancer. The simplest way to obtain this certificate is to use the following command that has access to the OIG load balancer:
openssl s_client -connect <OIG_LBR_HOST>:<OIG_LBR_PORT> -showcerts </dev/null 2>/dev/null|openssl x509 -outform PEM > <OIG_LBR_HOST>.pemopenssl s_client -connect prov.example.com:443 -showcerts </dev/null 2>/dev/null|openssl x509 -outform PEM > prov.example.com.pemkubectl cp /workdir/OIRI/prov.example.com.pem oirins/oiri-cli:/app/k8s/prov.example.com.pemParent topic: Loading the OIG Certificates into OIRI
Importing the OIG SSL Certificate into OIRI
keytool -import \
-alias oigssl \
-file /app/k8s/<CERT_FILE> \
-keystore /app/oiri/data/keystore/keystore.jks\
-storepass <OIRI_KEYSTORE_PWD> -nopromptkeytool -import \
-alias oigssl \
-file /app/k8s/prov.example.com.pem \
-keystore /app/oiri/data/keystore/keystore.jks\
-storepass <password> -nopromptParent topic: Loading the OIG Certificates into OIRI
Creating Wallets
OIRI stores database/OIG connection information in a wallet. You have to create the wallet by running the command from inside the OIRI-CLI pod.
oiri-cli --config=/app/data/conf/config.yaml wallet create \
--oigsau <OIRI_SERVICE_USER> \
--oigsap <OIRI_SERVICE_PWD> \
--oirijka oiri \
--oirijkp <OIRI_KEYSTORE_PWD> \
--oiriksp <OIRI_KEYSTORE_PWD> \
--oiridbuprefix <OIRI_RCU_PREFIX> \
--oiridbp <OIRI_SCHEMA_PWD> \
--oigdbu <OIG_RCU_PREFIX>_OIM \
--oigdbp <OIG_SCHEMA_PWD>oiri-cli --config=/app/data/conf/config.yaml wallet create \
--oigsau oirisvc \
--oigsap myservicepwd \
--oirijka oiri \
--oirijkp mykeystorepwd \
--oiriksp mykeystorepwd \
--oiridbuprefix oiri \
--oiridbp myschemapwd \
--oigdbu IGD_OIM \
--oigdbp myoigschemapwdls /app/data/wallet /app/oiri/data/walletCreating the Database Schemas
Create the OIRI database schemas in the database by running the commands from the OIRI-CLI container.
oiri-cli --config=/app/data/conf/config.yaml schema create /app/data/conf/dbconfig.yaml --sysp <OIRI_DB_SYS_PWD>oiri-cli --config=/app/data/conf/config.yaml schema migrate /app/data/conf/dbconfig.yamlCreating the schema oiri_oiri CREATING OIRI SCHEMA ............ =================================================== DB USER oiri_oiri has been successfully created Migrating the OIRI schema Migrating OIRI SCHEMA ............ =================================================== log4j:WARN No appenders could be found for logger (org.flywaydb.core.internal.scanner.classpath.ClassPathScanner). log4j:WARN Please initialize the log4j system properly. log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. ========== Before Migrate ============= Script:V1__RoleMining.sql Installed On:null State:PENDING Version:1 Description:RoleMining ========== After Migrate ============= Script:V1__RoleMining.sql Installed On:2021-03-02 08:01:54.18592 State:SUCCESS Version:1 Description:RoleMining OIRI Schema has been successfully migrated
Verifying the Wallet
After creating the wallet, you should validate the wallet. If the validation fails, correct the wallet before you proceed.
./verifyWallet.shVerifying Wallets. Wallet locations and entries will be validated DING Wallet is Valid. OIRI Wallet is Valid. OIRI DB Connection is Valid. OIG DB Connection is Valid. KeyStore location and entries are Valid. OIG Server Connection is Valid. SUCCESS: Wallet locations and entries are valid.
oiri-cli --config=/app/data/conf/config.yaml wallet updateDeploying OIRI Using Helm
After creating the namespaces, you can now deploy OIRI using the generated Helm chart. You should execute the command from the OIRI-CLI.
helm install oiri /helm/oiri -f /app/k8s/values.yamlNAME: oiri
LAST DEPLOYED: Mon Jan 11 15:14:22 2021
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Please be patient while the chart installs. Pod may not be in running status.
To check the status of the pod, run following command.
Pods READY state must be 1/1 and status RUNNING
kubectl get pods --namespace oiri
kubectl get pods --namespace ding
Access OIRI Service by using following URL in your browser.
https://IP_ADDRESS:PORT/
Access OIRI UI by using following URL in your browser.
https://IP_ADDRESS:PORT/oiri/ui/v1/console
Admins can access DING History Server by port forwarding the ding-history pod through kubectl.
kubectl port-forward <pod_name> <desired_port>:18080 -n ding
Inside the DING-CLI, use following commands to start data ingestion
ding-cli --config=/app/data/conf/config.yaml data-ingestion start /app/data/conf/data-ingestion-config.yamlVerifying that OIRI is Running
After you deploy OIRI, you should verify that it is running successfully.
kubectl -n <OIRINS> get pods -o widekubectl -n <DINGNS> get pods -o wideYou should see list of pods with the status 'Running'. For example:
NAME READY STATUS RESTARTS AGE oiri-6cd5755fb-j7r4 1/1 Running 0 42h oiri-6cd5755fb-s42xx 1/1 Running 0 42h oiri-ui-d55cd6b69-62nm6 1/1 Running 0 42h oiri-ui-d55cd6b69-rxdwm 1/1 Running 0 42h
kubectl -n dingns get podsNAME READY STATUS RESTARTS AGE oiri-ding-7045127aee424d93-driver 0/1 Completed 0 41h spark-history-server-6cc6d9d8c7-2594r 1/1 Running 0 42h spark-history-server-6cc6d9d8c7-jdcqc 1/1 Running 0 42h
Creating the Kubernetes NodePort Services
By default, OIRI gets created with all the components configured as
ClusterIP services. The configuration indicates that the Oracle
Identity Role Intelligence components are visible only within the Kubernetes
cluster.
In an enterprise deployment, all interactions with the OIRI components take place through the Oracle HTTP Server which is located outside of the Kubernetes cluster. If you use OHS and Ingress controller, the Ingress services are created for you. If you are using a NodePort deployment, you should create the NodePort Services to access the deployment.
Creating an OIRI NodePort Service
Parent topic: Creating the Kubernetes NodePort Services
Creating an OIRI UI NodePort Service
Parent topic: Creating the Kubernetes NodePort Services
Updating the OHS Configuration
If you have not already done so, you should now add the OIRI entries to the Oracle HTTP configuration.
See Configuring Oracle HTTP Server for Oracle Identity Role Intelligence.
Performing an Initial Data Load Using the Data Ingester
After OIRI is up and running, you may want to perform an initial data load from the OIG database.
Complete the following steps for a data load:
Starting the DING CLI
kubectl command:
Parent topic: Performing an Initial Data Load Using the Data Ingester
Copying the Kubernetes Certificate to DING
To enable interaction between DING and Kubernetes, you should copy the Kubernetes certificate to the DING container.
To copy the certificate:
Parent topic: Performing an Initial Data Load Using the Data Ingester
Verifying the DING Configuration
ding-cli --config=/app/data/conf/config.yaml data-ingestion verify /app/data/conf/data-ingestion-config.yamlSUCCESS: Data Ingestion Config is valid
Parent topic: Performing an Initial Data Load Using the Data Ingester
Running the Data Ingestion
ding-cli --config=/app/data/conf/config.yaml data-ingestion start /app/data/conf/data-ingestion-config.yamlINFO: 21/07/28 18:02:43 INFO LoggingPodStatusWatcherImpl: Application status for spark-901c5ed4ba4e4233b4501b8e1279a9cf (phase: Succeeded)This entry indicates that the data load is successful.
Parent topic: Performing an Initial Data Load Using the Data Ingester
Setting the Next Data Load to Incremental
/ding-cli/scripts/updateDataIngestionConfig.sh \
--entityusersenabled true --entityuserssyncmode incremental \
--entityapplicationsenabled true --entityapplicationssyncmode incremental \
--entityentitlementsenabled true --entityentitlementssyncmode incremental \
--entityassignedentitlementsenabled true --entityassignedentitlementssyncmode incremental \
--entityrolesenabled true --entityrolessyncmode incremental \
--entityrolehierarchyenabled true --entityrolehierarchysyncmode incremental \
--entityroleusermembershipsenabled true --entityroleusermembershipssyncmode incremental \
--entityroleentitlementcompositionsenabled true --entityroleentitlementcompositionssyncmode incremental \
--entityaccountsenabled true --entityaccountssyncmodeParent topic: Performing an Initial Data Load Using the Data Ingester