Azure OpenAI

Let's connect a python app in one virtual private network with an Azure OpenAI model configured with private endpoint in another virtual private network. You will use the Azure CLI to create these virtual networks and resources.

Each company’s network is private, isolated, and doesn't expose ports. To learn how end-to-end trust is established, please read: “How does Ockam work?”

Create an Orchestrator Project

1. Sign up for Ockam and pick a subscription plan through the guided workflow

2. Run the following commands to install Ockam Command and enroll with the Ockam Orchestrator. This step creates a Project in Ockam Orchestrator.

curl --proto '=https' --tlsv1.2 -sSfL https://install.command.ockam.io | bash
source "$HOME/.ockam/env"

ockam enroll

Run

This example requires Bash, Git, Curl, and the Azure CLI. Please set up these tools for your operating system. In particular you need to login to your Azure with az login.

Then run the following commands:

# Clone the Ockam repo from Github.
git clone --depth 1 https://github.com/build-trust/ockam && cd ockam

# Navigate to this example’s directory.
cd examples/command/portals/ai/azure_openai

# Run the example, use Ctrl-C to exit at any point.
./run.sh

If everything runs as expected, you'll see the answer to the question: "What is Ockham's Razor?".

Walkthrough

The run.sh script script, that you ran above, and its accompanying files are full of comments and meant to be read. The example setup is only a few simple steps, so please take some time to read and explore.

Administrator

• The run.sh script calls the run function which invokes the enroll command to create an new identity, sign into Ockam Orchestrator, set up a new Ockam project, make you the administrator of this project, and get a project membership credential.

• The run function then generates two new enrollment tickets. The tickets are valid for 60 minutes. Each ticket can be redeemed only once and assigns attributes to its redeemer. The first ticket is meant for the Ockam node that will run in AI Corp.’s network. The second ticket is meant for the Ockam node that will run in Health Corp.’s network.

• In a typical production setup an administrator or provisioning pipeline generates enrollment tickets and gives them to nodes that are being provisioned. In our example, the run function is acting on your behalf as the administrator of the Ockam project.

• The run function passes the enrollment tickets as variables of the run scripts provisioning AI Corp.'s network and Health Corp.'s network.

AI Corp

First, the ai_corp/run.sh script creates a network to host the application exposing the Azure OpenAI Service Endpoint

• Network Infrastructure:

  • We create an Azure Resource Group to contain all resources.

  • We create a Virtual Network (VNet) with a subnet to host the services.

• Azure OpenAI Service Configuration:

  • We deploy an Azure OpenAI Service instance.

  • We set up a private endpoint for secure access:

    • Create a private endpoint connection.

    • Establish a private DNS zone.

    • Link the DNS zone to the virtual network.

    • Configure DNS records for private endpoint resolution.

    • Disable public network access and Update network ACLs to deny public access.

• OpenAI Model Deployment:

  • We deploy the specified model (gpt-4o-mini) on the OpenAI service.

  • We retrieve the API key for authentication.

  • We create an environment file (.env.azure) containing:

    • The Azure OpenAI endpoint URL.

    • The API key for authentication.

• Virtual Machine Deployment:

  • We process the Ockam setup script (run_ockam.sh) by replacing variables:

    • Replaces SERVICE_NAME and TICKET placeholders.

  • We create a Red Hat Enterprise Linux VM:

    • Place it in the configured VNet/subnet.

    • Generate SSH keys for access.

    • Inject the processed Ockam setup script as custom data.

    • The default Network Security Group (NSG) is configured with basic rules: inbound SSH access (port 22), internal virtual network communication, Azure Load Balancer access, and a final deny rule for all other inbound traffic. For outbound, it allows virtual network and internet traffic, with a final deny rule for all other outbound traffic.

Ensure your Azure Subscription has access to deploy the "gpt-4o-mini" model (version: 2024-07-18). You may need to request quota/access for this model through the Azure Portal if not already enabled for your subscription.

Health Corp

First, the health_corp/run.sh script creates a network to host the client.py application which will connect to the Azure OpenAI model:

• Network Infrastructure Setup:

  • We create an Azure Resource Group to contain all resources.

  • We create a Virtual Network (VNet) with a subnet to host the services.

• VM Deployment and Ockam Setup:

  • We process the run_ockam.sh script by replacing:

    • ${SERVICE_NAME} with the configured service name.

    • ${TICKET} with the provided enrollment ticket.

  • We create a Red Hat Enterprise Linux 8 VM where the Ockam inlet node will run:

    • Use latest RHEL 8 LVM Gen2 image.

    • Generate SSH keys automatically.

    • Inject the processed Ockam setup script as custom data.

• Client Application Deployment:

  • We wait for VM to be accessible.

  • We copy required files to the VM:

    • Transfers client.py to the VM.

    • Copies .env.azure configuration file containing OpenAI credentials.

  • We set up the Python environment:

    • Install Python 3.9 and pip.

    • Install the OpenAI SDK.

  • We execute the client application.

• Client Application Operation:

  • The client.py application:

    • Connects to the Azure OpenAI service using credentials from .env.azure.

    • Sends queries to the model.

    • Receives and displays responses on the console.

Recap

We connected a Python application in one virtual network with an application serving an Azure OpenAI model in another virtual network over an end-to-end encrypted portal.

Sensitive business data coming from the Azure OpenAI model is only accessible to AI Corp. and Health Corp. All data is encrypted with strong forward secrecy as it moves through the Internet. The communication channel is mutually authenticated and authorized. Keys and credentials are automatically rotated. Access to connect with the model API can be easily revoked.

Health Corp. does not get unfettered access to AI Corp.'s network. It gets access only to run API queries to the Azure OpenAI service. AI Corp. does not get unfettered access to Health Corp.'s network. It gets access only to respond to queries over a TCP connection. AI Corp. cannot initiate connections.

All access controls are secure-by-default. Only project members, with valid credentials, can connect with each other. NATs are traversed using a relay and outgoing TCP connections. AI Corp. or Health Corp. don't expose any listening endpoints on the Internet. Their Azure virtual networks are completely closed and protected from any attacks from the Internet through Network Security Groups (NSGs) that only allow essential communications.

Cleanup

To delete all Azure resources:

./run.sh cleanup