Cloud and Git access
What Facets needs in your cloud and Git accounts and why, how to narrow it, the identity it acts as, and where your setup is stored.
Facets needs write access to each cloud account it builds in, because releases create and change resources there, and access to the Git repositories that hold your blueprints.
You link each account once, with a script you run in your cloud's own shell.
What Facets needs, and why
On AWS, Facets assumes an IAM role, so no access keys are stored. On GCP, Azure and Kubernetes, the script creates an identity and sends its key, secret or token to your control plane.
| Account | What the link creates | What that access covers |
|---|---|---|
| AWS | An IAM role in your account that trusts your control plane's AWS account (Facets' account, on Facets hosted) and requires an external ID | Full access to the services Facets builds with, including IAM, EC2, EKS, RDS, S3 and KMS |
| GCP | A service account with the Owner role on the project | Everything in the project |
| Azure | A service principal with a client secret, holding a custom role on the subscription | Resource groups, networking, AKS, storage, databases, Redis, web apps, managed identities and role assignments |
| Kubernetes | A service account bound to cluster-admin | Everything in the cluster |
| Git | The Facets GitHub App, the GitLab or Bitbucket app, or an access token | The repositories you give it. Facets creates and updates the repository behind each project |
- Why IAM and cluster-admin: releases create IAM roles for your services, and Facets deploys and manages what runs in each cluster.
- Why Owner on GCP: catalog modules create service accounts and grant them roles in the project, and Owner is the GCP basic role that can grant roles.
Narrowing access
The role, service principal or service account sits in your account, so you can change its permissions at any time. Facets doesn't put them back; a release that needs a permission you removed fails.
- From the start: create the role, service principal or service account yourself, with the permissions you choose, instead of running the script.
- Repositories: give Facets only the repositories it needs.
- People: limit the accounts each user group can use (Access control).
Starting read-only, or with part of your estate
For AWS, GCP and Azure, the script asks whether to give write or read-only access. Read-only is for discovering what you run and building a blueprint from it; releases can't change anything with it.
- AWS: AWS's ReadOnlyAccess policy, and optionally view access to your EKS clusters.
- GCP: the Viewer role and other viewer roles on the project, through a service account key.
- Azure: the Reader role on the subscription, through a service principal, and optionally read access to your AKS clusters.
- Kubernetes: no read-only link today.
For part of your estate, link only the accounts, projects and repositories you choose. Running resources come under Facets resource by resource (Importing existing infrastructure).
The identity Facets uses in your accounts
Facets acts as the identity the link created, so its changes all come from that one role, service principal or service account, easy to tell from a person's.
| Where | Facets acts as | Shows up in |
|---|---|---|
| AWS | The IAM role you linked, assumed from your control plane's AWS account | CloudTrail |
| GCP | The service account the script created | Cloud Audit Logs |
| Azure | The service principal the script created | The Azure activity log |
| Kubernetes | The service account the script created | The cluster's audit log, if it's turned on |
| Git | The linked account, which pushes the commits. Each commit carries the username of the Facets user who made the change | Your repository's history |
Each release's details in Facets show who triggered it, and audit logs mark what Praxis did.
No cloud credentials on your laptop
With the Praxis CLI, no cloud credentials are stored on your machine: praxis login saves your Facets access token, raptor runs locally with it, and cloud and cluster commands run on Facets' servers.
A few tasks do use credentials on your machine:
- Linking a cloud account: the script runs in a shell signed in to that cloud, such as AWS CloudShell.
- Downloading a kubeconfig, if your Kubernetes role allows it.
- Some Praxis skills use tools on your machine, such as a cloud CLI with your own login.
Your setup in your Git, and GitOps
Where your setup is kept:
- Blueprint: a private repository in your own Git account when the project is created in the web UI, or with the Praxis CLI and
--vcs-account. Without--vcs-account, the Praxis CLI uses Facets' facets-bot Git account. - Overrides, per-environment changes that leave the blueprint alone, are kept in the control plane. GitOps for Overrides also keeps them in a Git repository, synced both ways; it can't be turned off once it's on.
Supported Git providers
GitHub, GitLab and Bitbucket. Azure DevOps and Bitbucket Data Center aren't supported.
- GitHub: the Facets GitHub App, or an access token. GitHub Enterprise Server works with both, and GitHub Enterprise Cloud with the App.
- GitLab: GitLab.com through the GitLab app or an access token. Self-managed GitLab through an access token.
- Bitbucket: Bitbucket Cloud through the Bitbucket app or an API token.