How to Give Metricfixer Safe Cloud Infrastructure Access

Use this guide when Metricfixer needs access to cloud infrastructure, deployment systems, logs, containers, serverless functions, managed databases, storage, DNS/CDN, Kubernetes, or cloud security settings to diagnose a technical issue and apply approved fixes safely.

When to use this guide

This guide applies when the support task involves cloud-hosted applications, deployment infrastructure, cloud logs, managed services, containers, serverless functions, cloud databases, storage, networking, DNS, CDN, secrets, or identity and access management.

Typical cases include:

• AWS, Google Cloud, Microsoft Azure, Cloudflare, DigitalOcean, Render, Fly.io, Railway, Heroku, or another cloud platform;
• cloud application deployment, CI/CD, GitHub Actions deployment, rollback, staging setup, or production release troubleshooting;
• containers, Docker registries, ECS, EKS, GKE, AKS, Kubernetes namespaces, Cloud Run, App Runner, App Service, Functions, Lambda, Workers, or serverless jobs;
• cloud logs, metrics, traces, application errors, failed builds, failed deploys, queue workers, schedulers, cron jobs, health checks, or alerting;
• managed databases, cache services, object storage, file storage, queues, pub/sub, email services, webhooks, and related cloud integrations;
• DNS, CDN, SSL/TLS, WAF, firewall rules, load balancers, API gateways, reverse proxies, or edge rules;
• secret managers, environment variables, service accounts, IAM roles, workload identity, deployment keys, or cloud API authentication.

Preferred workflow

Metricfixer normally uses the following workflow for cloud infrastructure tasks:

1. Confirm the cloud provider, affected environment, affected service, region, resource name, deployment method, and visible error in the ticket.
2. Start with architecture notes, screenshots, redacted logs, build output, deployment output, infrastructure-as-code files, and read-only access when possible.
3. Use staging, preview, development, or a temporary test environment before making production changes.
4. Grant read-only diagnostic access first. Grant implementation access only after the required change is known.
5. Use resource-scoped roles, project-scoped roles, subscription/resource-group roles, namespace-scoped Kubernetes RBAC, zone-scoped Cloudflare access, or selected-service permissions instead of broad account access.
6. Prefer GitHub Actions OIDC, workload identity federation, deployment roles, or cloud-native temporary credentials instead of long-lived cloud access keys.
7. Keep production secrets in the client cloud account or secret manager. Do not copy production secrets into Codex, email, ordinary chat, or the Git repository.
8. Make production changes only after written approval in the ticket, unless emergency mode was explicitly agreed.
9. Revoke temporary access, rotate temporary tokens, and remove unused deployment roles after completion.

Before you provide access

Please add the following information to the ticket before inviting Metricfixer or creating cloud roles:

• cloud provider and environment: AWS account, GCP project, Azure subscription/resource group, Cloudflare account/zone, Kubernetes cluster, or hosting provider;
• environment type: development, preview, staging, production, disaster recovery, or shared infrastructure;
• affected resources: application, service, container, function, database, bucket, queue, load balancer, DNS zone, CDN, worker, secret, repository, or pipeline;
• region, project ID, subscription ID, account ID, resource group, namespace, domain, zone ID, service name, or deployment name where available;
• current deployment method: GitHub Actions, GitLab CI, Bitbucket Pipelines, Terraform, Pulumi, CloudFormation, CDK, manual deploy, provider dashboard, CLI, or custom script;
• repository URL and branch used for staging and production deployment, if code is involved;
• error message, failed workflow run, build logs, application logs, provider event logs, monitoring alert, or screenshot;
• whether infrastructure is managed manually or through infrastructure as code;
• whether the task may affect production traffic, database writes, customer data, payment processing, tracking, email delivery, or business-critical jobs;
• confirmation that backups, snapshots, restore points, database backups, or rollback releases exist where the task involves production resources;
• the person authorized to approve production changes.

Choose the minimum safe access level

1. No direct cloud access

Use this for the initial review when Metricfixer can work from screenshots, redacted logs, failed build output, deployment configuration, infrastructure-as-code files, cloud console exports, monitoring screenshots, or a screen share controlled by your team.

2. Read-only diagnostics

Use read-only access when Metricfixer needs to inspect resources, logs, metrics, deployments, events, IAM bindings, routing, DNS settings, or configuration but does not need to change anything. Read-only access should still be limited to the relevant account, project, subscription, resource group, service, namespace, or zone.

3. Staging implementation access

Use staging implementation access when Metricfixer needs to change configuration, deploy code, run migrations, update environment variables, adjust scaling, restart services, or test infrastructure changes outside production. This is the preferred level for most repairs.

4. Production deployment access

Use production deployment access only when the approved task requires a live release or production configuration change. Production access should be controlled through a deployment pipeline, GitHub Environment approval, temporary cloud role, or supervised maintenance window.

5. Temporary elevated access

Use temporary elevated access only for tasks that cannot be completed with narrower permissions, such as creating a deployment role, adjusting IAM for a specific service, setting up a missing resource, or repairing a blocked production release. Elevated access should have a short expiration time and should be revoked immediately after the task.

6. Emergency production access

Emergency production access is not the default workflow. Use it only when production is broken, written emergency approval is recorded in the ticket, backups or rollback steps are confirmed, and the exact change window is clear.

Recommended access by cloud provider

Cloud provider role names change over time. Use the narrowest equivalent role available in your account.

AWS

• Do not share the AWS root user. The root user should be protected and used only for tasks that truly require it.
• For diagnostics, use a temporary IAM Identity Center assignment, IAM role, or read-only role limited to the relevant account, region, service, and resources where possible.
• For implementation, create a role limited to the required services, such as logs, ECS, EKS, Lambda, S3, CloudFront, Route 53, RDS, Secrets Manager, CloudWatch, SQS, EventBridge, or IAM actions required for the agreed task.
• Avoid AdministratorAccess, IAMFullAccess, organization administrator permissions, account closure permissions, root access, billing access, and access to unrelated accounts.
• For GitHub Actions deployments, prefer an OIDC-trusted IAM role scoped to the exact GitHub organization, repository, branch, workflow, or environment instead of long-lived AWS access keys.
• If access keys are unavoidable, make them temporary, tightly scoped, and rotate or delete them after the ticket.

Google Cloud

• Grant access at the project, service account, bucket, Cloud Run service, GKE cluster, secret, log, or resource level where possible. Avoid organization-level and folder-level access unless the task requires it.
• For diagnostics, use Viewer, Logs Viewer, Monitoring Viewer, or other narrow read-only predefined roles for the relevant project or resource.
• For implementation, use the most limited predefined role or custom role needed for the specific service.
• Avoid broad basic roles such as Owner and Editor in production unless there is no narrower alternative and the ticket explicitly approves it.
• For deployments from GitHub Actions, prefer Workload Identity Federation or a short-lived identity flow instead of downloadable service account key JSON files.
• If a service account key is unavoidable, treat it as a password, store it only through an approved secure method, and delete or rotate it after the ticket.

Microsoft Azure

• Grant access at the resource group, app, container app, function app, storage account, key vault, subscription resource, or specific resource scope where possible.
• For diagnostics, use Reader or a narrow monitoring/logs role for the relevant resources.
• For implementation, use Contributor only at the narrowest practical scope and only when the task requires configuration or deployment changes.
• Avoid Owner, User Access Administrator, Global Administrator, Privileged Role Administrator, subscription-wide Contributor, billing roles, and directory-wide roles unless specifically required and approved.
• Use Privileged Identity Management, eligible assignments, time-bound roles, or approval-based elevation where available.
• For GitHub Actions deployments, prefer OpenID Connect or federated credentials instead of long-lived client secrets.

Cloudflare, DNS, CDN, WAF, and edge platforms

• Grant access only to the required account, zone, domain, Pages project, Worker, tunnel, DNS records, cache, WAF rules, or SSL/TLS settings.
• For review, use read-only or analytics/log access where available.
• For DNS tasks, grant DNS edit permissions only for the affected zone, or add the DNS records yourself using our instructions.
• For cache and CDN issues, cache purge or zone settings access may be enough. Full account administrator or super administrator access is usually not required.
• Do not grant billing, account ownership, super administrator, member management, payment, or unrelated-zone access unless explicitly required by the task.
• Use scoped API tokens instead of global API keys when automation is required.

Kubernetes and container platforms

• Prefer namespace-scoped Kubernetes RBAC instead of cluster-admin access.
• For diagnostics, provide access to view pods, deployments, services, ingress, events, logs, and relevant config in the affected namespace.
• For implementation, provide permission only to update the required workloads, config maps, secrets, jobs, ingress, or deployments in the affected namespace.
• Cluster-admin, kubeconfig with full cluster access, node access, admission controller changes, CRD administration, and secret access across all namespaces are high-risk and should not be shared by default.
• For container registries, grant access only to the required repository and image tags. Do not grant full registry owner access unless required.

Managed databases, storage, queues, and secrets

• Use the separate database access guide for database credentials, production dumps, migrations, and direct database writes.
• For object storage, grant access only to the required bucket, container, prefix, folder, or objects. Avoid full storage account or all-buckets access.
• For queues and pub/sub, grant access only to the relevant queues, topics, subscriptions, or dead-letter queues.
• For secret managers and key vaults, grant access only to the exact staging or production secret needed for the approved task. Do not export all secrets.
• Production secret access is not standard. If a production secret is needed, approve the reason in the ticket and rotate it after the task if it was exposed.

Secrets, keys, and environment variables

Cloud credentials and deployment secrets are sensitive. Please follow these rules:

• Do not send cloud access keys, service account JSON keys, client secrets, private keys, kubeconfigs, database passwords, SMTP passwords, payment secrets, or API tokens by ordinary email.
• Do not commit .env files, cloud keys, Terraform state files with secrets, kubeconfigs, SSH keys, or credentials to GitHub.
• Use cloud IAM roles, workload identity, secret managers, GitHub Environments, provider-native deployment integrations, or secure temporary credentials where possible.
• Keep production secrets inside your cloud account or secret manager. Metricfixer should not receive a full copy of production secrets unless the ticket explicitly requires it.
• If a secret was shared for the ticket, rotate it after completion or when the task no longer requires it.

Production approval rules

Cloud changes can affect live traffic, data storage, security, billing, and availability. For this reason, production changes require clear approval.

• Deploy production changes through a reviewed pull request and deployment pipeline whenever possible.
• Use GitHub Environments, deployment approvals, branch restrictions, or provider-native approval workflows for production releases.
• Confirm backup, snapshot, restore point, rollback release, or rollback command before risky production changes.
• Do not change IAM, firewall rules, database settings, secret values, DNS, load balancers, autoscaling, WAF rules, or production deploy configuration without written approval.
• Keep a short change log in the ticket: what changed, where it changed, who approved it, and how to roll it back.

What not to provide

• AWS root user, Google Cloud organization owner, Azure Global Administrator, Azure subscription Owner, Cloudflare Super Administrator, or equivalent full-control access;
• billing, finance, payout, payment method, invoice, procurement, tax, marketplace purchase, or subscription management permissions unless the task is specifically about billing;
• unrestricted IAM administration, user management, organization management, policy management, or permission delegation unless the approved task requires it;
• long-lived cloud access keys, service account JSON keys, client secrets, kubeconfigs, global API keys, SSH private keys, or recovery codes by email or chat;
• production database root credentials, full production dumps, all-buckets storage access, all-secrets access, or unrelated customer records;
• access to unrelated accounts, projects, subscriptions, resource groups, domains, stores, client environments, or business units;
• permanent access for a one-time ticket;
• personal employee accounts or shared team passwords.

If your security policy does not allow external cloud access

Metricfixer can work in client-executed mode when your company policy does not allow external access. In that case, provide redacted logs, screenshots, configuration exports, infrastructure-as-code files, and command output. Metricfixer will prepare a patch, pull request, command list, deployment checklist, or step-by-step instructions for your team to execute internally.

After the task is completed

1. Remove Metricfixer users, guest accounts, IAM users, IAM Identity Center assignments, service principals, service accounts, API tokens, Kubernetes bindings, Cloudflare members, and temporary roles that are no longer needed.
2. Disable or delete temporary access keys, service account keys, client secrets, kubeconfigs, deploy tokens, and scoped API tokens created for the ticket.
3. Reduce any remaining access to the minimum level required for ongoing support, if ongoing support was agreed.
4. Rotate secrets that were exposed outside the cloud secret manager or shared directly for the ticket.
5. Review cloud audit logs, deployment logs, and IAM changes if your security policy requires it.
6. Confirm in the ticket that access has been revoked, reduced, or rotated.