AzureContainerInstancesOperator supports dictionary-based identities and automatically converts them (adds _ensure_identity, modifies files, and tests).

[henry3260]

Description

Based on the merged PR Add managed identity assignment support (#58364), the AzureContainerInstancesOperator now accepts an identity parameter to set a Managed Identity on the created Container Group. The original PR passes the provided identity value through to the Azure ContainerGroup as-is, but the docstring example contains syntax/structure issues and the operator does not validate or convert simplified user input (e.g., plain dicts) into the Azure SDK ContainerGroupIdentity model.

Problem

• Users who prefer not to import Azure SDK models would like to provide a simple dict to specify user-assigned or system-assigned identities. The current implementation does not help convert or validate such dicts, which can result in errors surfaced later by the Azure SDK.
• The docstring example in the original PR is syntactically incorrect and may mislead users.
• Existing tests only verify passing an identity object (MagicMock) and do not cover the dict-input scenario.

Proposal

• Add a lightweight helper in the operator (e.g., _ensure_identity) that accepts:
  • None (unchanged),
  • an instance of azure.mgmt.containerinstance.models.ContainerGroupIdentity (existing behavior), or
  • a simple dict with keys such as "type" and "resource_ids", and automatically convert such dicts into a ContainerGroupIdentity instance.
• Update the operator docstring to include:
  • a correct SDK example creating ContainerGroupIdentity, and
  • a DAG example demonstrating using a dict identity (noting that the operator converts it).
• Add unit tests that cover dict input, verifying the operator converts the dict to a ContainerGroupIdentity and that the resulting ContainerGroup identity contains the expected user_assigned_identities mapping.

Advantages

• Improved developer experience: users can provide a straightforward dict without importing SDK models.
• Earlier, friendlier validation: format errors (missing "type", non-list resource_ids, etc.) are caught at the operator level instead of failing later in the Azure SDK call.
• Backwards compatible: still accepts ContainerGroupIdentity instances while adding convenience for dict inputs.

Use case/motivation

Allow DAG authors to specify managed identities using simple configuration (YAML/JSON/dict) without needing to import SDK classes in their DAG files, improving ergonomics and lowering the barrier for making secure ACI deployments.

Related issues

Original PR: #58364
Related issue referenced by the PR: #58362

Are you willing to submit a PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[boring-cyborg]

Thanks for opening your first issue here! Be sure to follow the issue template! If you are willing to raise PR to address this issue please do so, no need to wait for approval.

[henry3260]

@jroachgolf84 Can you assign me to this issue? Thanks!

[arjunanan6]

Hi @henry3260, this is a great suggestion. In my first implementation, I went along these lines, but then backracked when I saw how the rest of the operator is written. It's almost entirely dependent on the implementation in azure.mgmt.containerinstance.models, so I stripped everything out and let it follow the same design pattern.

You're right that the docstring example is incorrect, I only noticed now. However, can you clarify this part: "Users who prefer not to import Azure SDK models" - you don't have to import the model in itself, the assignment is simply done as:

identity = {
    "type": "UserAssigned",
    "resource_ids": [
        "/subscriptions/00000000-0000-0000-0000-00000000000/resourceGroups/my_rg/providers/Microsoft.ManagedIdentity/userAssignedIdentities/my_identity"
    ],
}

This is similar to how other properties such as diagnostics or dns_config are defined.

Anyway, I am curious to see how this one will turn out.

[henry3260]

Hi @arjunanan6, thanks for your feedback. I wanted to clarify my proposal based on your comments:

1. Regarding Dictionary Support: While you mentioned that users can directly pass a dictionary for identity (e.g., identity={"type": "UserAssigned", ...}), this doesn’t fully address the problem of input validation. From my understanding, the current implementation works with dictionaries because of Azure SDK’s leniency—it implicitly accepts correctly structured dictionaries. However, this approach lacks early validation at the operator level, which means errors due to improperly formatted dictionaries (e.g., missing type or invalid resource_ids) will only surface at runtime when calling the Azure SDK. My proposal aims to handle these dictionaries explicitly at the operator level, converting them into ContainerGroupIdentity and performing early validation. This ensures friendlier user feedback and avoids unexpected runtime failures.

2. Maintaining Consistency: I understand your concern with keeping the operator’s design consistent with the SDK. However, adding lightweight processing like _ensure_identity wouldn’t disrupt the current design but instead makes the operator more user-focused and resilient. It provides ergonomic improvements, allowing users to pass simpler configurations while still preserving the flexibility for those who wish to use ContainerGroupIdentity directly.

I hope this clarifies my approach. Let me know if further details are needed!