azure-app-registration
Skill4 starsChanged 4 months agoISCView on GitHub
Provision an Entra ID app registration + service principal for the current GitHub repo, assign AI Foundry / OpenAI / Storage / AI Search RBAC roles, and project the resulting Azure credentials into the dev-env's `liliput-azure-sp` Kubernetes Secret. Use this when a Liliput-managed app needs to access Azure AI Foundry, Azure OpenAI, or related data-plane services from inside its dev container.
- Sends data out
In this repository51 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .github/copilot-instructions.mdCopilot instructions
- adrSkill
- api-extractorSkill
- architecture-mapperSkill
- aspireSkill
- audit-logSkill
- azure-deploymentSkill
- bug-fixSkill
- build-checkSkill
- cloud-native-assessmentSkill
- cloud-native-plannerSkill
- codebase-scannerSkill
- commit-protocolSkill
- contract-generationSkill
- data-model-extractorSkill
- ddd-modelingSkill
- dependency-inventorySkill
- deploy-diagnosticsSkill
- dev-implementerSkill
- e2e-generationSkill
- error-handlingSkill
- extension-plannerSkill
- find-skillsSkill
- frd-generatorSkill
- gherkin-generationSkill
- human-gateSkill
- implementationSkill
- modernization-assessmentSkill
- modernization-plannerSkill
- performance-assessmentSkill
- playwright-cliSkill
- pm-issue-authorSkill
- prd-generatorSkill
- release-managerSkill
- research-best-practicesSkill
- resumeSkill
- rewrite-assessmentSkill
- rewrite-plannerSkill
- security-assessmentSkill
- security-plannerSkill
- skill-creatorSkill
- skill-discoverySkill
- spec-refinementSkill
- spec-validatorSkill
- state-managementSkill
- tech-stack-resolutionSkill
- test-discoverySkill
- test-generationSkill
- test-runnerSkill
- ui-ux-designSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 2 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 16
Do NOT invoke this skill when:
- Distinctive: line 99
Secret value is only known at mint time: If a valid secret exists in the central record, it is reused.
- Very specific: line 100
Rotation does not auto-restart pods: When rotated: true, suggest kubectl rollout restart deploy/<name> -n <ns> to consumers.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Azure App Registration (per repo)
When to use
Invoke this skill when:
- The user asks for "Azure access", "AI Foundry credentials", "Azure OpenAI from this app", "service principal", or similar in the current workstream.
- A Liliput-managed app you are building needs to call Azure AI Foundry, Azure OpenAI, Storage, or AI Search at runtime from its container.
- You see code that reads
AZURE_CLIENT_ID/AZURE_CLIENT_SECRET/AZURE_TENANT_IDand they are missing in the dev-env.
Do NOT invoke this skill when:
- The user only needs Liliput itself (the orchestrator) to talk to Azure — Liliput already runs as a managed identity.
- The current task does not need Azure data-plane access. Don't pre-provision credentials "just in case".
What it does
For the repo currently being worked on (e.g. acme/widgets):
- Finds (or creates) an Entra ID app registration named
liliput-{env}-{owner}-{repo}, double-keyed by Liliput-owned tags so it cannot collide with manually-created apps. - Ensures the app has a service principal in your tenant.
- Mints a fresh client secret if the current one expires within 7 days (default 30-day lifetime). Otherwise reuses the existing secret value (kept in
liliput/azure-sp-{owner}-{repo}as the source of truth). - Assigns the SP a default role bundle on the resource scope given by
LILIPUT_AI_FOUNDRY_SCOPE:Cognitive Services OpenAI UserAzure AI Developer(AI Foundry user)Azure AI Inference Deployment Operator(AI Foundry contributor)Storage Blob Data ContributorSearch Index Data Contributor
- Writes a Kubernetes Secret named
liliput-azure-spinto the dev-env namespace with these keys:AZURE_TENANT_ID,AZURE_CLIENT_ID,AZURE_CLIENT_SECRET, plusAZURE_AI_FOUNDRY_ENDPOINT/AZURE_OPENAI_ENDPOINT/AZURE_AI_PROJECT_ENDPOINTif configured for this Liliput instance.
The dev-pod consumes the secret via envFrom: secretRef: name: liliput-azure-sp. The Deployment manifest you generate must reference it.
How to call
Loopback-only HTTP endpoint inside the orchestrator pod. From a bash step:
curl -sS -X POST \
-H "Content-Type: application/json" \
-H "X-Liliput-Internal: $LILIPUT_INTERNAL_TOKEN" \
http://127.0.0.1:5002/api/azure/app-registration/ensure \
-d '{
"repo": "acme/widgets",
"namespace": "dev-acme-widgets-main"
}'Response JSON: appId, appObjectId, servicePrincipalId, tenantId, secretName, rotated, expiresAt, rolesAssigned. The clientSecret value is never returned over HTTP — it lands in the Kubernetes Secret only.
Wiring the secret into the deployment
spec:
template:
spec:
containers:
- name: app
envFrom:
- secretRef:
name: liliput-azure-spIn the app code, DefaultAzureCredential picks up the three env vars automatically:
import { DefaultAzureCredential } from '@azure/identity';
const credential = new DefaultAzureCredential();Optional parameters
{
"repo": "acme/widgets",
"namespace": "dev-acme-widgets-main",
"roleAliases": ["cognitive-services-openai-user", "ai-foundry-user"],
"scope": "/subscriptions/<sub>/resourceGroups/<rg>",
"extraSecretData": { "AZURE_AI_PROJECT_NAME": "my-project" },
"forceRotate": false
}Failure modes
LILIPUT_AI_FOUNDRY_SCOPEunset → tool refuses with clear error. Ask the user to set it (ARM resource ID).- Conflicting app exists without Liliput tags → tool refuses to mutate. User must rename/delete the conflicting app or change
LILIPUT_ENV. - Graph permission denied → Liliput's MI is missing
Application.ReadWrite.OwnedBy. Seedocs/azure-permissions.md. - ARM permission denied → Liliput's MI lacks
User Access Administratorat the configured scope. Same doc. - Endpoint returns 503 →
LILIPUT_INTERNAL_TOKENnot set. Ask user to set it via the deploy workflow.
Important constraints
- One app reg per repo (not per branch). Branches share the SP.
- Secret value is only known at mint time. If a valid secret exists in the central record, it is reused; the tool does NOT rotate just because a namespace is new.
- Rotation does not auto-restart pods. When
rotated: true, suggestkubectl rollout restart deploy/<name> -n <ns>to consumers. - Never log the response body verbatim — treat the endpoint as credential-issuing even though it does not return the secret today.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

