You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Phase supports third-party authentication systems for access control. You can delegate authentication and administration to external providers such as Google, AWS IAM, GitHub, Kubernetes, GitLab, or Microsoft Azure to best suit your setup. When choosing an authentication provider, consider whether the access to Phase will be programmatic (machine-access) via REST API, SDK, CLI, etc., or user access (human-access).
15
16
17
+
<DocActions />
18
+
16
19
## User Authentication
17
20
18
21
User authentication in Phase is designed for seamless and secure web access. Phase supports both OAuth 2.0 and OpenID Connect (OIDC) protocols for Single Sign-On (SSO), allowing organizations to leverage their existing identity providers like Google, GitHub, GitLab, and JumpCloud. We plan to extend support to SCIM (System for Cross-domain Identity Management), which will enable automatic synchronization of user directories with Phase, including automatic provisioning and deprovisioning of user accounts based on changes in your organization's primary identity system.
Copy file name to clipboardExpand all lines: public/access-control/authentication/oidc-sso.md
+3Lines changed: 3 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,4 +1,5 @@
1
1
import { Tag } from '@/components/Tag'
2
+
import { DocActions } from '@/components/DocActions'
2
3
3
4
export const description = 'Authenticating via various OIDC Single sign-on providers with Phase.'
4
5
@@ -8,6 +9,8 @@ export const description = 'Authenticating via various OIDC Single sign-on provi
8
9
9
10
OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0 that allows applications to verify user identities. It enables secure authentication through trusted identity providers while eliminating the need for separate credentials. Phase supports OIDC-based SSO integration with major providers like Google, allowing seamless and secure access to your applications. Currently, OIDC authentication can be set up only for a Self-hosted Phase deployment.
10
11
12
+
<DocActions />
13
+
11
14
<Note>
12
15
OIDC SSO as an authentication method is only available for organizations with an `Enterprise` tier subscription. See [Pricing](https://phase.dev/pricing).
Copy file name to clipboardExpand all lines: public/access-control/authentication/tokens.md
+3Lines changed: 3 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,4 +1,5 @@
1
1
import { Tag } from '@/components/Tag'
2
+
import { DocActions } from '@/components/DocActions'
2
3
3
4
export const description =
4
5
'Learn how to create and manage authentication tokens in Phase.'
@@ -9,6 +10,8 @@ export const description =
9
10
10
11
Phase provides secure authentication tokens for both human users and service accounts. These tokens enable programmatic access to Phase through our API, CLI, and SDKs while maintaining strict access controls and security standards. {{ className: 'lead' }}
11
12
13
+
<DocActions />
14
+
12
15
## Service Account Tokens
13
16
14
17
Service Account Tokens are used to authenticate your Service Account when making API requests. These tokens inherit the permissions and access levels of the service account they belong to.
import { DocActions } from '@/components/DocActions'
3
+
4
+
<Tagvariant="small">ACCESS CONTROL</Tag>
5
+
6
+
export const description =
7
+
'This guide explains how to use External Identities to authenticate with Phase and manage access with the Access Control system.'
8
+
9
+
10
+
# External Identities
11
+
12
+
External Identities allow you to use third-party platforms and services to serve as identity providers for clients seeking programmatic access to Phase. Instead of manually provisioning access tokens for each client on each machine or an instance on your infrastructure, you can use External Identities to establish a trusted relationship with a principal that will be used to validate the identity of the client and grant access to Phase. This enables dynamic authentication and authorization for clients such as the CLI, SDKs, Kubernetes Operator, or your own applications.
13
+
14
+
<DocActions />
15
+
16
+
Example use case: Imagine you have a fleet of EC2 instances in an autoscaling group (ASG) that runs an instance of your application. The Phase CLI is configured to inject secrets into your applications at runtime. Instead of manually provisioning access tokens for each client on each machine, you can use External Identities to establish a trusted relationship with an instance profile attached to the ASG.
17
+
18
+
The authentication flow will be as follows:
19
+
20
+
<Diagramcaption="External Identity authentication flow with AWS IAM">
21
+
{`
22
+
sequenceDiagram
23
+
participant Client as Client
24
+
participant Phase as Phase
25
+
participant AWS as AWS STS
26
+
27
+
Note over Client,AWS: 1. GetCallerIdentity()
28
+
Client->>AWS: Fetch GetCallerIdentity from STS
29
+
AWS-->>Client: Return AWS Sigv4 signed GetCallerIdentity
30
+
31
+
Note over Client,Phase: 2. Authenticate
32
+
Client->>Phase: POST Sigv4 signed GetCallerIdentity to /identities/external/v1/aws/iam/auth/
33
+
34
+
Note over Phase,AWS: 3. Validate signature
35
+
Phase->>AWS: Forward Sigv4 signed GetCallerIdentity
36
+
AWS-->>Phase: Return IAM user/role metadata
37
+
38
+
Note over Phase: 4. Check entity trust relationship - is client a trusted principal?
39
+
Phase->>Client: Return Access Token with a specified TTL
40
+
41
+
Note over Client,Phase: 5. Authenticate to API with Access Token
42
+
Client->>Phase: Make authenticated requests using the Access Token
43
+
`}
44
+
</Diagram>
45
+
46
+
Benefits:
47
+
- Automate the creation and provisioning of access tokens for every client on your infrastructure.
48
+
- Automatic token revocation after expiry
49
+
- Centralized management of trust relationships
50
+
51
+
## Prerequisites
52
+
- Server-side encryption (SSE) enabled for the Service Account you want to use the External Identity with.
53
+
- A third-party platform or service that supported by Phase
54
+
55
+
## Supported External Identity Providers
56
+
Phase currently supports the following external identity providers:
57
+
58
+
-[**AWS IAM**](#aws-iam): Bind an AWS IAM User to a phase Service Account
59
+
60
+
## Configure an External Identity
61
+
62
+
To set up an External Identity for use with a Phase Service Account, follow these steps. First, navigate to the **Access Control** page from the sidebar, and select **External Identities**. Then, choose a provider:
Then, enter the required information to configure the external identity. For all providers, you will need to provide basic information about the identity and how tokens are generated:
67
+
68
+
<Properties>
69
+
<Propertyname="Identity Name"type="string">
70
+
A name for the external identity.
71
+
</Property>
72
+
<Propertyname="Description"type="string">
73
+
Optionally, a description for the external identity.
74
+
</Property>
75
+
<Propertyname="Token name"type="string">
76
+
Optional name for tokens that will be generated for Service Accounts using this external identity. The default is the provider shortcode, e.g. `aws-iam`.
77
+
</Property>
78
+
<Propertyname="Token Default TTL"type="number">
79
+
The default TTL (in seconds) for tokens generated for Service Accounts using this external identity. Default is 3600 seconds (1 hour).
80
+
</Property>
81
+
<Propertyname="Token Max TTL"type="number">
82
+
The default TTL (in seconds) for tokens generated for Service Accounts using this external identity. Default is 86400 seconds (24 hours).
83
+
</Property>
84
+
</Properties>
85
+
86
+
Additionally, you will need to provide provider-specific information depending on the selected provider.
87
+
88
+
### AWS IAM
89
+
90
+
For AWS IAM, you will need to provide the following information:
91
+
92
+
<Properties>
93
+
<Propertyname="Trusted principal ARNs"type="comma-separated-string">
94
+
The ARN(s) of the AWS IAM User(s) to bind to the Phase Service Account. Separate multiple ARNs with commas.
95
+
</Property>
96
+
<Propertyname="Signature expiry"type="number">
97
+
The duration (in seconds) for which the signed requests from the AWS IAM User will be valid. Default is 60 seconds. Lower the better. This is to protect against replay attacks.
98
+
</Property>
99
+
<Propertyname="STS endpoint"type="string">
100
+
Optionally, specify a custom AWS STS endpoint. If not provided, the default AWS STS endpoint will be used (`https://sts.amazonaws.com`).
101
+
</Property>
102
+
</Properties>
103
+
104
+
105
+
106
+
107
+
## Manage External Identities
108
+
109
+
Once an External Identity is created, it will appear in the list on the **External Identities** page. From here, you can view details, edit configurations, or delete the identity.
To use an External Identity, the Service Account must have [Server-side KMS](/access-control/service-accounts#server-side-kms) enabled.
117
+
</Note>
118
+
119
+
Once you have configured an External Identity, you can bind it to a Phase Service Account. To do this, navigate to the **Service Accounts** page, select the desired Service Account and click **Mange** to open the account detail page. Scroll down to the **External Identities** section and click **Manage External Identities**:
From the dialog, select the External Identity you want to bind to this Service Account and enable it using the toggle switch. Click **Save** to apply the changes:
124
+
125
+
Copy file name to clipboardExpand all lines: public/access-control/network.md
+3Lines changed: 3 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,11 +1,14 @@
1
1
import { Tag } from '@/components/Tag'
2
+
import { DocActions } from '@/components/DocActions'
2
3
3
4
<Tagvariant="small">ACCESS CONTROL</Tag>
4
5
5
6
# Network
6
7
7
8
You can control access to resources in Phase from specific IPv4 or IPv6 sources by defining individual IPs or CIDR ranges in a Network Access Policy. You may attach such Network Access Policy to a User and/or Service Accounts individually or enforce it across your entire organization via a Global Policy. This allows you to put an additional layer of security on top of the existing access control mechanisms, by making sure that a client can only gain access to resources in Phase via mediums and/or assets such as the Phase Console, CLI, SDKs, Kubernetes Operator, REST API, etc. while being in the confines of your network.
8
9
10
+
<DocActions />
11
+
9
12
<Note>
10
13
The ability to create and manage network access policies is available for organizations with a `Pro` or an `Enterprise` tier subscription.
Copy file name to clipboardExpand all lines: public/access-control/roles.md
+13Lines changed: 13 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,11 +1,14 @@
1
1
import { Tag } from '@/components/Tag'
2
+
import { DocActions } from '@/components/DocActions'
2
3
3
4
<Tagvariant="small">ACCESS CONTROL</Tag>
4
5
5
6
# Roles
6
7
7
8
Roles in Phase define the level of access and permissions granted to users within an organization. They determine what actions a user can perform and what resources they can access. Phase offers both managed roles with predefined permissions and the ability to create custom roles for more specific access control needs.
8
9
10
+
<DocActions />
11
+
9
12
## Assigning Roles to Users
10
13
11
14
To assign a role to a user or change a user's role:
@@ -37,6 +40,7 @@ The organization owner. This role is automatically assigned when a user creates
37
40
|**Member Personal Access Tokens**| Full access | ✅ | ✅ | ✅ | ✅ |
0 commit comments