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 to enable or disable auto-creation of ad-application in central resources.
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. Set enable_bring_your_own_ad_app=true in custom values file for terraform apply in central resources.
2. Post success of terraform apply for central resources, add application id of custom ad application to aad-client-id key in central resources keyvault.
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.
@@ -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.
@@ -130,7 +131,7 @@ To enable byoad, turn on the feature flag by following the below steps. If you d
| Variable | Value |
|----------|-------|
| TF_VAR_enable_bring_your_own_ad_app | true |
| TF_VAR_aad_client_id | {{application client id of manually created ad application}} |
__Setup and Configure the ADO Library `Infrastructure Pipeline Secrets - demo`__
...
...
@@ -172,10 +173,6 @@ az pipelines create \
-ojson
```
If you've enabled BYOAD, then following steps need to be done -
1. Post success of terraform apply for central resources, add application id of custom ad application to aad-client-id key in central resources keyvault.
2.`infrastructure-data-partition`
> For the first run of the pipeline approvals will need to be made for the 2 secure files and the Service Connection.
# 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)