Platform template execution: restrict parameters, actions, and credentials

Operational decision

A platform template creates an event-processing service and binds a deploy identity. Give the template a narrow repository-creation credential and a separate short-lived identity for the deployment registration step. The user supplies a repository name and target team; validate both against an allowlist and verified team membership on the server side. Reject a repository path containing parent traversal, an unapproved organization, or a requested identity outside the team's scope. Add a test action that tries to print its token and verify output redaction, log access, and token expiry. Review custom actions as privileged code, including network egress and access to runner files. A team allowed to create a development service should not inherit production secret access because both use the same underlying action. Record the effective policy decision and action versions with the request; if the template changes while a request waits in a queue, the worker must execute the reviewed version or reevaluate policy before side effects.

Event service template boundary
Caller: verified team member
Template version: immutable for queued request
Parameters: server-side validation
Repository scope: approved organization and name
Action credentials: separate, short-lived, least privilege
Logs: redacted and access-controlled
Decision: policy, action version, request ID

Cost and verification

Server-side authorization adds O(A) policy checks for A privileged actions and may call identity services; caching reduces latency but risks stale membership. Isolating credentials and retaining decision logs adds setup and storage cost. Measure denied cross-team requests, privileged action inventory, token exposure tests, and queued requests executed under changed policies. Security here depends on the executor's effective permissions, not the labels shown in the form.

Common Mistakes

• Do not trust client-side form validation as authorization.
• Do not give every action one organization-wide token.
• Do not execute a queued request under an unreviewed template revision.

Connected lessons

• DevOps: delivery, infrastructure, and reliable operations
• Self-service provisioning: make the request contract explicit
• Policy exceptions: make a temporary bypass expire and prove its scope
• Secret access: audit workload creation as an indirect read permission
• Release evidence: tie one deployed digest to one approval decision

Practice and check

• Project: prove a self-service platform request end to end
• DevOps platform self-service decisions