Skip to content

Manage Cloud Identities

The metadata harvesting (model import) is performed by server (see MANAGE > Servers) that may use allowing secret / password parameters to be based on an external (MetaKarta managed) cloud identity (on Amazon Web Services, Google Cloud, or Microsoft Azure) where the secret / password parameter can be:

  • A secret identifier which is a URL to a cloud identity secret vault's actual secret (allowing for external storage of such secret / password in a cloud secret vault).

  • Empty (no longer mandatory) and the authentication is based on the cloud identity on select bridges (such as Microsoft Azure Data Lake Storage, Microsoft Azure Blob Storage, and more to come).

Public clouds provide identity management and access control infrastructure that enable their customers to define one security principle that can access multiple services using secret-protected or temporary credentials.

For example, Azure allows you to define an identity for an application that can access your storage and database services. MetaKarta can get temporary credentials, like access tokens, that can be used to access Azure services.

Public clouds support key vaults that help you to safeguard secrets used by cloud apps and services. Each secret has a unique URL.

Cloud bridges support the following authentication methods:

The bridge decides what authentication method to use based on the presence of values of authentication parameters and logs the decision.

Configure a Cloud Identity

Public clouds provide identity management and access control infrastructure that enable their customers to define one security principal that can access multiple services using secret-protected or temporary credentials.

Steps

  1. Sign in as a user with at least the Application Administrator capability global role assignment.

  2. Go to MANAGE > Cloud Identities in the banner.

  3. Click + Add to create a new identity with the proper credentials for connecting to the specific secrets vault.

  4. From here you should specify:

  5. NAME of the identity for reference

  6. DEFINITION of the identity

  7. TYPE:

  8. Microsoft Azure

  9. Amazon Web Services

  10. Google Cloud

The product supports Microsoft Azure, Amazon Web Services and Google Cloud. Any or all of them may be defined for use.

  • Specific ID's and Secrets required for the particular cloud identity technology.

  • Specify Cloud Identity the appropriate URL/Code in the Import Setup tab for the model and import.

  • Use the TEST function at the bottom of the page to test your connection credentials.

Secret credentials authentication

All cloud bridges have parameters that allow you to authenticate with the cloud using a cloud security principal ID and its secret (long HEX Secret / Password). For example, AWS cloud bridges have the Access Key ID and Secret Access Key parameters. These parameters allow you to authenticate with the cloud programmatically.

This authentication method is appropriate when you

  • use a small number of cloud bridges

  • are starting out with cloud bridges

  • would like to use different security principals for different bridges

This is simply a standard metadata harvesting (model import) using the bridge parameters and not using a cloud identity defined here. Because you specified the correct secret directly in the bridge parameter, the bridge will ignore any CLOUD IDENTITY specified.

Temporary credentials authentication

You may specify secret credentials for AWS, Azure, and GCP clouds and this product is careful with the secret credentials and does not share them with bridges. This product uses these secret credentials to authenticate with the cloud, get temporary credentials from it, and provide them to bridges.

This authentication method is appropriate when you would like to

  • specify credentials once and use them in many bridges automatically

  • avoid exposing secret credentials to bridges

  • have multiple layers of security

There are scenarios when you use multiple independent environments in the same cloud and would like to register their secret credentials for the cloud.

You may specify multiple secret credentials for a cloud and select one of them per bridge (Import Setup).

Another option for handling multiple independent environments in the same cloud is to register one secret credential for the cloud and specify the secret credential for another environment in its bridges directly.

Steps

  1. If not already done, configure a cloud identity.

  2. Go to MANAGE > Configuration and create a new model or setup an existing one which will use a secret associated with the cloud identity.

  3. Specify Cloud Identity the appropriate URL/Code in the Import Setup tab for the model and import.

Example

Sign in as Administrator and go to MANAGE > Cloud Identities in the banner.

Click + Add. Enter "Sales Azure East US" in the NAME field.

Enter the proper credentials:

  • DIRECTORY (TENANT) ID from Azure

  • APPLICATION (CLIENT) ID from Azure

  • APPLICATION (CLIENT) SECRET from Azure

Click TEST.

Typically, each Cloud Provider (Azure, Amazon, Google) has a number of services which bridges may need to access with the same credentials. For example, in this case Azure has: datalake storage service, analysis services, and the databricks service. When you click TEST the product tries these credentials for those three services which are supported. If all services are accessible, the result is "Connection successful". If some services are accessible but some are not the result is "Connection is partially successful"'. The system log contains the result for each service which has been tested.

Click CREATE.

Be sure to work with your experts in the specified cloud identity to obtain both the connection credentials required on this page and the actual URL or ID of the secret you will use for import.

Now, go to MANAGE > Configuration and the Import Setup tab.

Pick Sales Azure East US as the CLOUD IDENTITY.

Leave the Access key, SAS token, or MSI Tenant-ID/Client ID bridge parameter empty and continue with the import.

Cloud machine identity authentication

When you run a cloud bridge on the cloud, you can configure its machine to use the necessary cloud identity and use it for the bridge authentication. A cloud bridge tries to use its machine's cloud identity when its bridge's security principle and temporary credentials parameters are empty.

This authentication method is appropriate when you want to delegate the authentication to the machine the bridge is running on.

In addition, to support the more robust cloud identity features, select import bridges will support more automatic cloud identity-based authentication. In this way, the Secret / Password parameter is no longer mandatory for those bridges and the authentication may be based on the cloud identity:

This is simply a standard metadata harvesting (model import) where you depend upon the identity provide by the machine running the bridge. Thus, you will leave the bridge parameter for the cloud secret empty, and you will specify NONE as the CLOUD IDENTITY. Then the bridge will simply connect assuming that the machine identity itself is sufficient.

Cloud vault authentication

Secrets Vaults are environments provided by various third-party vendors which are central repositories for basic usernames and Secret / Passwords, as well as tokens, SSH keys, and certificates to name a few. These are referred to as secrets.

This product supports the following for providing authentication information for various bridge:

  • Microsoft Azure

  • Amazon Web Services

  • Google Cloud

First you must define the credentials for connecting to the particular vault(s) you use and then you may refer to any secrets (e.g., Secret / Password, certification, etc.) required for importing from a particular source when defining the parameters for an imported model.

You can ask a cloud bridge to get the value of its cloud secret parameter from a cloud vault by specifying the vault's URL of the secret in the parameter.

Public clouds support key vaults that help you to safeguard secrets. Each secret has a unique URL. You can save a secret in a cloud vault and permit access to the secret to the security principal registered with this product. When this product has multiple security principals registered for the cloud of the vault, it will use the first one.

This authentication method works in conjunction with the secret credential method and is appropriate when you would like to

  • Use rotatable secrets like a cloud database Secret / Password

  • Avoid storing secrets in this repository

Steps

  1. If not already done, configure a cloud identity.

  2. Go to MANAGE > Configuration and create a new model or setup an existing one which will use a secret from the vault associated with the cloud identity.

  3. Specify Cloud Identity the appropriate URL/Code in the Import Setup tab for the model and import.

Each secret has a unique secret identifier which is a URL to a cloud identity secret vault secret (allowing for external storage of such Secret / Password in a cloud secret vault).

Example

Sign in as Administrator and go to MANAGE > Cloud Identities in the banner.

Click + Add. Enter "Sales Azure East US" in the NAME field.

A screenshot of a computer Description automatically generated

Enter the proper credentials:

  • DIRECTORY (TENANT) ID from Azure

  • APPLICATION (CLIENT) ID from Azure

  • APPLICATION (CLIENT) SECRET from Azure

A screenshot of a computer Description automatically generated with medium confidence

Click TEST.

A picture containing text, font, line, brand Description automatically generated

Click CREATE.

Be sure to work with your experts in the specified secrets vault to obtain both the connection credentials required on this page and the actual URL or ID of the secret you will use for import.

Now, go to MANAGE > Configuration and the Import Setup tab.

Pick Sales Azure East US as the CLOUD IDENTITY.

Specify the appropriate Secret Identifier URL in the Secret / Password field and continue with the import.

For example: