Cloud Onboarding — DevOps Guide
KredSLA connects to your cloud account in two discrete steps: discovery and alerting. Discovery is read-only and runs continuously; alerting deploys a small event-driven stack that captures SLA breach evidence in real time. This article explains what each step does, the minimum permissions required, and how the roles are mapped for each supported cloud provider.
How the two steps work
Step 1 — Discovery
KredSLA periodically scans your account to build an inventory of SLA-eligible resources (load balancers, databases, compute groups, etc.) and assess their observability configuration. All calls are read-only: no resources are created or modified.
Discovery runs every 30 minutes via a background Celery task. The scan also validates health check configuration and surfaces advisory warnings for any resources where the current setup could produce false-positive or false-negative SLA breach signals.
Step 2 — Alerting
KredSLA deploys a lightweight event-driven stack into your account. This stack:
- Listens for AWS Health events (provider-declared incidents)
- Fires CloudWatch alarms when SLA metrics breach their thresholds
- Captures timestamped evidence into a DynamoDB table for use in credit filing
- Sends notifications to an SNS topic when a breach is detected
The alerting stack is deployed once, in a single region you choose during onboarding. Discovery continues to run across all regions.
AWS
Step 1 — Discovery role
KredSLA assumes an IAM role in your account to perform discovery. You deploy the role using a CloudFormation stack launched directly from the KredSLA dashboard.
What the deployer needs — the IAM user or role that runs cloudformation create-stack must have these permissions (least-privilege policy available at test/aws/cfn-discovery-role-deploy-policy.json):
| Statement | Actions | Resource scope |
|---|---|---|
CloudFormationDeploy | cloudformation:{CreateStack,UpdateStack,DeleteStack,DescribeStacks,DescribeStackEvents,GetTemplateSummary,ValidateTemplate} | arn:aws:cloudformation:*:*:stack/kredsla-discovery-*/* |
IAMForDiscoveryRole | iam:{CreateRole,UpdateRole,DeleteRole,GetRole,PutRolePolicy,GetRolePolicy,DeleteRolePolicy,TagRole,UntagRole} | arn:aws:iam::*:role/kredsla-discovery |
What the discovery role itself gets — the CloudFormation stack creates the kredsla-discovery IAM role with an inline policy granting read-only access to the services KredSLA monitors:
| Service | Actions |
|---|---|
| EC2 | ec2:DescribeInstances, ec2:DescribeRegions |
| RDS | rds:DescribeDBInstances, rds:DescribeDBClusters |
| Elastic Load Balancing | elasticloadbalancing:DescribeLoadBalancers, elasticloadbalancing:DescribeTargetGroups |
| Auto Scaling | autoscaling:DescribeAutoScalingGroups |
| Lambda | lambda:ListFunctions |
| S3 | s3:ListBuckets |
| Cost Explorer | ce:GetCostAndUsage |
Trust relationship — the role's trust policy allows KredSLA's AWS account to assume it:
{
"Principal": { "AWS": "arn:aws:iam::<kredsla-account-id>:root" },
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": { "sts:ExternalId": "<your-org-external-id>" }
}
}
The external ID is generated per organisation at signup and shown in the onboarding wizard. It prevents confused-deputy attacks.
Step 2 — SLA alerting stack
The alerting stack is also deployed via CloudFormation from the KredSLA dashboard. The generated template is scoped to your account and region.
What the deployer needs (least-privilege policy at test/aws/cfn-alerting-deploy-policy.json):
| Statement | Actions | Resource scope |
|---|---|---|
CloudFormationDeploy | cloudformation:{CreateStack,UpdateStack,DeleteStack,DescribeStacks,DescribeStackEvents,GetTemplateSummary,ValidateTemplate} | arn:aws:cloudformation:*:*:stack/kredsla-alerting-*/* |
SNSForAlertTopic | sns:{CreateTopic,DeleteTopic,GetTopicAttributes,SetTopicAttributes,Subscribe,Unsubscribe,ListSubscriptionsByTopic,TagResource,UntagResource} | arn:aws:sns:*:*:kredsla-sla-alerts |
DynamoDBForEvidenceTable | dynamodb:{CreateTable,DeleteTable,DescribeTable,UpdateTable,UpdateTimeToLive,DescribeTimeToLive,TagResource,UntagResource} | arn:aws:dynamodb:*:*:table/kredsla-sla-evidence |
IAMForLambdaRoles | iam:{CreateRole,UpdateRole,DeleteRole,GetRole,PutRolePolicy,GetRolePolicy,DeleteRolePolicy,PassRole,TagRole,UntagRole} | arn:aws:iam::*:role/kredsla-* |
LambdaForBreachHandlers | lambda:{CreateFunction,UpdateFunctionCode,UpdateFunctionConfiguration,DeleteFunction,GetFunction,GetPolicy,AddPermission,RemovePermission,TagResource,UntagResource} | kredsla-health-metric, kredsla-evidence-capture, kredsla-support-case-filer |
EventBridgeForHealthRule | events:{PutRule,DeleteRule,DescribeRule,PutTargets,RemoveTargets,TagResource,UntagResource} | arn:aws:events:*:*:rule/kredsla-aws-health-events |
CloudWatchAlarmsForBreachDetection | cloudwatch:{PutMetricAlarm,PutCompositeAlarm,DeleteAlarms,DescribeAlarms,TagResource,UntagResource} | arn:aws:cloudwatch:*:*:alarm:kredsla-* |
Note on CAPABILITY_NAMED_IAM: the stack creates IAM roles. The deployer must acknowledge this in the CloudFormation console or pass --capabilities CAPABILITY_NAMED_IAM on the CLI. The Launch Stack button in the KredSLA dashboard includes this capability automatically.
Role naming: CFN-generated role names follow the pattern {StackName}-{LogicalId}-{Suffix}. With stack name kredsla-sla-alerting, roles become kredsla-sla-alerting-*, which is why the IAM resource ARN in the policy uses the broader kredsla-* prefix rather than kredsla-alerting-*.
Combined policy: if the same IAM user deploys both stacks, a merged policy is available at test/aws/cfn-kredsla-deploy-policy.json.
Azure
Azure does not require a separate discovery step with a separate deployer role. A single service principal covers both discovery and credit filing.
Credentials required
| Field | Description |
|---|---|
tenant_id | Azure Active Directory tenant ID |
client_id | Service principal application (client) ID |
client_secret | Service principal secret |
subscription_id | Subscription to monitor |
Minimum role assignments
| Purpose | Built-in role | Scope |
|---|---|---|
| Discovery (enumerate resources) | Reader | Subscription |
| SLA credit filing (create support tickets) | Support Request Contributor | Subscription |
Both roles can be assigned to the same service principal. To assign them:
# Reader for discovery
az role assignment create \
--assignee <client-id> \
--role "Reader" \
--scope /subscriptions/<subscription-id>
# Support Request Contributor for filing
az role assignment create \
--assignee <client-id> \
--role "Support Request Contributor" \
--scope /subscriptions/<subscription-id>
Discovery uses the Azure Resource Management API (azure-mgmt-resource) to list resources across the subscription. Credit filing uses the Azure Support Management API (azure-mgmt-support).
GCP
Credentials required
| Field | Description |
|---|---|
project_id | GCP project ID |
service_account_key_json | Full JSON key downloaded from the GCP Console |
Minimum role bindings
| Purpose | IAM role | Scope |
|---|---|---|
| Discovery (enumerate assets) | roles/cloudasset.viewer | Project |
| SLA credit filing (create support cases) | roles/cloudsupport.techSupportEditor | Project |
Both roles are bound to the same service account. To create the service account and assign roles:
SA_EMAIL="kredsla@<project-id>.iam.gserviceaccount.com"
# Create service account
gcloud iam service-accounts create kredsla \
--display-name="KredSLA" \
--project=<project-id>
# Asset viewer for discovery
gcloud projects add-iam-policy-binding <project-id> \
--member="serviceAccount:${SA_EMAIL}" \
--role="roles/cloudasset.viewer"
# Tech Support Editor for filing
gcloud projects add-iam-policy-binding <project-id> \
--member="serviceAccount:${SA_EMAIL}" \
--role="roles/cloudsupport.techSupportEditor"
# Generate and download key
gcloud iam service-accounts keys create kredsla-key.json \
--iam-account="${SA_EMAIL}"
Upload the contents of kredsla-key.json as the service_account_key_json credential in KredSLA.
Discovery uses the Cloud Asset Inventory API. Ensure it is enabled on the project:
gcloud services enable cloudasset.googleapis.com cloudsupport.googleapis.com
Troubleshooting: key creation blocked by org policy
Some orgs enforce the iam.disableServiceAccountKeyCreation constraint, which
causes the gcloud iam service-accounts keys create command above to fail
with FAILED_PRECONDITION: Key creation is not allowed on this service account. Check whether it's enforced and, if needed, disable it at the
project level (requires roles/orgpolicy.policyAdmin):
gcloud resource-manager org-policies describe \
iam.disableServiceAccountKeyCreation \
--project=<project-id> --effective
gcloud resource-manager org-policies disable-enforce \
iam.disableServiceAccountKeyCreation --project=<project-id>
OCI
Credentials required
| Field | Description |
|---|---|
tenancy | Tenancy OCID |
user | User OCID of the API key owner |
fingerprint | API key fingerprint |
key_content | PEM-encoded private key |
region | Home region identifier (e.g. us-ashburn-1) |
compartment_id | Compartment OCID to scan |
csi | (Optional) Customer Support Identifier — improves support case routing |
Minimum policy statements
OCI uses resource-level policies attached to groups. Add the following to an OCI policy in the target compartment:
# Discovery
Allow group KredSLAGroup to inspect all-resources in compartment <compartment-name>
Allow group KredSLAGroup to read all-resources in compartment <compartment-name>
# SLA credit filing (CIMS — Customer Incident Management System)
Allow group KredSLAGroup to manage incident in tenancy
The user whose API key is supplied must be a member of KredSLAGroup. To set up the API key:
- In the OCI Console, navigate to Identity → Users → <your user> → API Keys.
- Click Add API Key, upload or generate a key pair.
- Copy the configuration snippet shown — this provides
tenancy,user,fingerprint, andregion. - Store the private key content as
key_contentin KredSLA.
Discovery covers: compute instances, Autonomous Databases, Object Storage buckets, and Load Balancers, all within the specified compartment.
Summary
| Cloud | Discovery mechanism | Discovery credential | Alerting mechanism | Alerting credential |
|---|---|---|---|---|
| AWS | IAM role assumed via STS | Cross-account role (kredsla-discovery) | CloudFormation stack | Deployer IAM user/role |
| Azure | ARM Resource Management API | Service principal (Reader) | N/A — KredSLA files directly | Service principal (Support Request Contributor) |
| GCP | Cloud Asset Inventory API | Service account (cloudasset.viewer) | N/A — KredSLA files directly | Service account (cloudsupport.techSupportEditor) |
| OCI | OCI SDK — compute, database, storage, LB clients | API key user (inspect/read all-resources) | N/A — KredSLA files directly | API key user (manage incident) |
For AWS, the alerting stack is the only component that writes resources into your account. All other cloud integrations are read-and-file: KredSLA reads your resource state and files support cases on your behalf without deploying anything into your infrastructure.