Open Workload Governance

Workload Object

Mon, 01 Jan 0001 00:00:00 +0000

Version: 0.1 Draft · Status: Proposal

Complete Example

apiVersion: openworkloadgovernance.io/v1alpha1
kind: Workload

metadata:
 type: service
 name: shop-api
 description: Customer-facing webshop API

ownership:
 owners:
 - omada:team
 - servicenow:group
 approvers:
 - omada:role:customer-owner
 - omada:role:platform-owner

classification:
 criticality: high
 environment: prod
 dataClassification: confidential

identities:
 - ref: github://repo/shop-api
 tokens:
 - ref: github://token/shop-api-token
 - ref: entra://managed-identity/shop-api

resources:
 - ref: aws://account/shop-prod
 - ref: github://repo/shop-api
 - ref: kubernetes://namespace/shop
 - ref: kafka://topic/orders

provides:
 apis:
 - name: shop-api
 scopes:
 - customer.read
 - customer.write
 - order.read
 - order.create
 endpoints:
 - https://api.shop.example.com

requires:
 - type: api
 service: customer-api
 scopes:
 - customer.read
 - type: api
 service: payment-api
 scopes:
 - payment.create
 - type: kafka-topic
 resource: orders
 - type: aws-role
 resource: arn:aws:iam::123456789012:role/order-reader

accessIntents:
 - action: deploy
 source:
 ref: github://oidc/shop-api-prod
 target:
 ref: kubernetes://namespace/shop
 - action: update-service
 source:
 ref: github://oidc/shop-api-prod
 target:
 ref: workload://customer-api

governance:
 changeManagement:
 required: true
 provider:
 ref: servicenow://assignment-group/customer-platform
 approvals:
 requiredFor:
 - production-deployment
 - access-change
 approvers:
 - ref: omada://role/customer-owner
 controls:
 backupOwnerRequired: true
 recertificationRequired: true

references:
 - ref: servicenow://business-service/BS12345
 name: servicenow:service
 - ref: backstage://component/shop-api
 name: backstage:component
 - ref: github://repo/shop-api
 name: github:repo
 - ref: omada://team/shop-team
 name: omada:team
 - ref: servicenow://group/customer-platform
 name: servicenow:group
 - ref: omada://role/customer-owner
 name: omada:role:customer-owner
 - ref: omada://role/platform-owner
 name: omada:role:platform-owner

The supplied identities fragment mixed a mapping (github:repo) with a sequence entry. This site normalizes it into a list of ref objects: the repository carries nested token references, and the managed identity is a separate entry. This interpretation needs review before a schema is published.

Workloads

Mon, 01 Jan 0001 00:00:00 +0000

A Workload describes a governed service or other workload through its metadata, ownership, classification, identities, resources, capabilities, dependencies, and access intents. The example describes shop-api, a customer-facing webshop API with metadata.type: service. The permitted workload types have not yet been defined.

Questions A Workload Answers

What is this workload, and what type of workload is it?
Who owns it, and who can approve governance actions?
Which environment and data classification apply?
Which identities and resources are associated with it?
Which APIs and scopes does it provide?
Which services and resources does it require?
Which actions are intended between identities and targets?
Which change-management, approval, and control requirements apply?

Description Is Not Enforcement

Declaring ownership, required scopes, or an access intent does not provision an identity, grant access, or authorize a deployment. Participating systems need explicit validation and enforcement contracts. The draft describes desired governance relationships, not an implemented control plane.

Ownership And Governance

Mon, 01 Jan 0001 00:00:00 +0000

Version: 0.1 Draft · Status: Proposal

Owners And Approvers

ownership:
 owners:
 - omada:team
 - servicenow:group
 approvers:
 - omada:role:customer-owner
 - omada:role:platform-owner

These names map to entries in the Workload’s references list. The example assigns ownership to an Omada team and a ServiceNow group, and identifies customer-owner and platform-owner roles as approvers. Referencing a party does not define its membership or grant permissions.

Change Management

governance:
 changeManagement:
 required: true
 provider:
 ref: servicenow://assignment-group/customer-platform

The example requires change management and references the responsible provider. It does not define ticket creation, change states, or the conditions under which a deployment may proceed.

References

Mon, 01 Jan 0001 00:00:00 +0000

OWG does not prescribe an identity provider. The Workload example connects external systems using named references and direct ref values, rather than defining users, groups, or teams itself.

Named References

Ownership lists names whose external targets are declared in references:

ownership:
 owners:
 - omada:team
 - servicenow:group
references:
 - ref: omada://team/shop-team
 name: omada:team
 - ref: servicenow://group/customer-platform
 name: servicenow:group

omada:team is a local reference name in this example, not a universal subject type. Matching it to the reference entry identifies omada://team/shop-team as the external target. The example also names roles, a business service, a component, and a repository.

Reference Resolution

Mon, 01 Jan 0001 00:00:00 +0000

Version: 0.1 Draft · Status: Proposal

The Workload example defines reference data, not HTTP endpoints. This static website does not implement a lookup service. The earlier ownership and subject API examples are not a contract for the revised model.

Resolve A Named Owner

For shop-api, ownership.owners contains omada:team. Its corresponding entry is:

references:
 - ref: omada://team/shop-team
 name: omada:team

A consumer can match the local name to the entry and use an appropriate external integration to resolve the team. The same process maps servicenow:group and the named approver roles. Name uniqueness and missing-reference behavior still need a formal definition.