CI/CD credential design starts with a question: which job is allowed to change which environment, and what evidence permits that authority? A pipeline can pass its tests while still giving an untrusted build more access than it needs. For teams evaluating delivery automation in Canada, this guide offers a review method rather than a claim about a local project or a prescribed compliance standard.
Separate the build from deployment authority
A build usually needs source code, dependencies and somewhere to write an artifact. A production deployment needs a different permission set. Combining both in one broadly privileged job makes a build failure or compromised dependency harder to contain.
Create a simple inventory before changing credentials. For each job, record its trigger, runner, input trust, destination, required actions and environment. Include preview deployments, scheduled workflows and manual jobs. The important distinction is whether the job can receive untrusted code or configuration, not whether its name contains “production.”
An illustrative inventory might contain a pull-request build that reads source and uploads a test artifact, an approved release job that reads an immutable artifact and changes a staging service, and a separate production promotion job. This is a proposed example, not a report of XIVTech client work. Each boundary needs its own review; copying the same role to every job would defeat the separation.
Use short-lived identity where the platform supports it
OpenID Connect can let a workflow exchange its identity for short-lived cloud credentials. GitHub's OpenID Connect documentation describes this approach. It can reduce reliance on stored long-lived cloud credentials, but it does not decide which repository, branch, environment or workflow should be trusted.
Review identity conditions and cloud authorization separately. The identity policy decides who may request a session; the role policy decides what that session may do. A short-lived session with excessive permissions can still make a damaging change. Provider support, token claims and available condition keys vary, so verify the actual platform documentation instead of assuming a portable policy snippet will be safe everywhere.