-[Keda Upgrade to 2.x](https://community.opengroup.org/osdu/platform/deployment-and-operations/infra-azure-provisioning/-/issues/128) - Follow this Documentation to do it: [Keda Upgrade](docs/keda-upgrade.md)
-[Add multi-partition support in Indexer Queue](https://community.opengroup.org/osdu/platform/system/indexer-queue/-/issues/6)
-[Notification Service to use Service Bus](https://community.opengroup.org/osdu/platform/system/notification/-/issues/25)
-[Notification loss, if migration not done](https://community.opengroup.org/osdu/platform/system/notification/-/blob/master/provider/notification-azure/docs/MIGRATION.md)
__Deprecation Notes__
- The Notification service has started functioning on Service Bus as the underlying PubSub. Starting v0.12.0, Event Grid will be deprecated. In v0.11.0, the service will have two deployments - one using Event Grid and one uses Service Bus.
For more information on Azure identity and authorization, see the official Microsoft documentation [here](https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent).
## Elastic Search Setup
Infrastructure requires a bring your own Elastic Search Instance of a version of 7.x (ie: 7.11.1) with a valid https endpoint and the access information must now be stored in the Common KeyVault. The recommended method of Elastic Search is to use the [Elastic Cloud Managed Service from the Marketplace](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/elastic.ec-azure?tab=Overview).
We've added a feature flag (aad_client_id) to enable or disable auto-creation of ad-application in central resources.
# Updating existing infra to have custom AD Application
Doing this will make current auth and refresh codes invalid. They'll need to be generated again.
1. Users with manual deployment, if already not set, set aad_client_id = {{application client id of the custom ad application created}} in custom values file for terraform apply in central resources.
2. Users with automated pipeline -
1. . Go to Pipelines Library in ADO
2. Go to `Infrastructure Pipeline Variables - demo` variable group
3. Add or update the below variable if already not set
| Variable | Value |
|----------|-------|
| TF_VAR_aad_client_id | {{application client id of manually created ad application}} |
3. Users with automated pipeline should now run chart chart-osdu-istio and chart-osdu-istio-auth pipeline.
4. Users with manual deployment need to re-install osdu-istio helm chart with new app-id.
5. Delete all pods in the portal AKS. This will trigger a restart of all pods. Complete steps 5,6 and 7 in quick procession.
6. While all pods are getting restarted, move to configuration in portal AKS. Select secrets tab and choose osdu/osdu-azure namespace.
7. Delete active-directory from the results. This will trigger its recreation.
8. Delete all pods again to make sure that new pods are using new active directory secrets.
9. Run this script with required values substituted - [subscriberCreationRegisterService](./Trouble%20Shooting%20Guides/tsg-scripts/subscriberCreationRegisterService.ps1)
@@ -34,10 +34,6 @@ This is likely an issue with the `Application.ReadWrite.OwnedBy` permissions tha
The common_prepare.sh script is a helper script that helps to perform the activities necessary to provision OSDU on Azure. These activities can all be performed manually if desired. Service Principals are created using the command `az ad sp create-for-rbac` which requires Owner permissions on a subscription to perform.
## Why does the Service Principal used by Terraform to create an OSDU Environment Stamp require Azure AD Graph API access levels of `Application.ReadWrite.OwnedBy`?
Terraform is used to provision an OSDU Environment Stamp a Service Principal is the identity used by Terraform to perform this action. An OSDU Environment Stamp requires an AD Application used for Identity Management which is currently created by the Terraform Scripts. In order for a Service Principal to be able to create Applications in AD, the permission of `Application.ReadWrite.OwnedBy` is required for the Azure AD Graph API.
## Why does the Service Principal used internally within an OSDU Environment Stamp require MS Graph API access levels of `Directory.ReadAll`?
The OSDU Entitlement Service integrates with Azure AD. The defined API spec for the service includes a Create method for which input criteria includes an email address. This email address is looked up in Azure AD to confirm it exists and retrieve the Object Id of the user to be used as the source of identity which requires the permission of `Directory.ReadAll` for the MS Graph API.
...
...
@@ -59,7 +55,7 @@ This key pair can be used to ssh into an AKS node if needed.
* osdu-mvp-xxx-terraform – A principal identity that can be used by Terraform for creating OSDU Resources
* osdu-mvp-xxx-principal – A principal identity that is fed to an OSDU Deployment to be used as the Root Level Identity for that OSDU Environment
* osdu-mvp-xxx-noaccess – A negative testing principal identity.
* osdu-mvp-xxx-application – An AD Application for future use. (Not currently used yet.)
* osdu-mvp-xxx-application – An AD Application.
## What AAD Items are created by the central resource template?
* osdu-mvp-crxxx-xxxx-app – An AD application that defines the OSDU Environment created.
# Do not run following commands if you wish to use ad application created/managed by terraform and
# you've used common_prepare.sh for initial setup. Also, it requires setting of AZURE_VAULT, ADO_PROJECT and UNIQUE env variables.
# These commands pull aad client id from common keyvault for the ad application created by common_prepare.sh. This aad client id is then used in terraform env.
# if you have created common infra manually without common_prepare.sh, then manually set aad_client_id = "your ad application client id" in custom.tfvars and do not run these commands.
TF_VAR_application_clientid=$(az keyvault secret show --id https://$AZURE_VAULT.vault.azure.net/secrets/${ADO_PROJECT}-${UNIQUE}-application-clientid--query value -otsv)
@@ -18,6 +18,10 @@ Login to Azure CLI using the OSDU Environment Service Principal.
```bash
# This logs your local Azure CLI in using the configured service principal.
ARM_CLIENT_ID="<arm client id>"
ARM_CLIENT_SECRET="<arm client secret>"
ARM_TENANT_ID="<tenant id>"
az login --service-principal-u$ARM_CLIENT_ID-p$ARM_CLIENT_SECRET--tenant$ARM_TENANT_ID
```
...
...
@@ -26,6 +30,7 @@ __Upload Storage Blob Test Data__
This [file](../tools/test_data/Legal_COO.json) needs to be loaded into the Data Partition Storage Account in the container `legal-service-azure-configuration`.
```bash
UNIQUE="<your_osdu_unique>"
GROUP=$(az group list --query"[?contains(name, 'cr${UNIQUE}')].name"-otsv)
ENV_VAULT=$(az keyvault list --resource-group$GROUP--query[].name -otsv)
PARTITION_NAME=opendes
...
...
@@ -65,6 +70,7 @@ These files need to be uploaded into the proper Cosmos Collections with the requ
```bash
# Retrieve Values from Common Key Vault
COMMON_VAULT="<common keyvault created in common prepare phase>"
export NO_DATA_ACCESS_TESTER=$(az keyvault secret show --id https://$COMMON_VAULT.vault.azure.net/secrets/osdu-mvp-${UNIQUE}-noaccess-clientid--query value -otsv)