mirror of
https://github.com/Infisical/infisical.git
synced 2025-03-25 14:05:03 +00:00
fix images in docs
This commit is contained in:
@ -9,14 +9,14 @@ Infisical **Additional Privileges** functionality enables specific permissions w
|
||||
|
||||
To provision specific privileges through Web UI:
|
||||
1. Click on the `Edit` button next to the set of roles for user or identities.
|
||||

|
||||

|
||||
|
||||
2. Click `Add Additional Privileges` in the corresponding section of the permission management modal.
|
||||

|
||||

|
||||
|
||||
3. Fill out the necessary parameters in the privilege entry that appears. It is possible to specify the `Environment` and `Secret Path` to which you want to enable access.
|
||||
It is also possible to define the range of permissions (`View`, `Create`, `Modify`, `Delete`) as well as how long the access should last (e.g., permanent or timed).
|
||||

|
||||

|
||||
|
||||
4. Click the `Save` button to enable the additional privilege.
|
||||

|
||||

|
@ -17,7 +17,7 @@ By default, every user and machine identity in a organization is either an **adm
|
||||
|
||||
Overall, organization-level access controls are significantly of administrative nature. Access to projects, secrets and other sensitive data is specified on the project level.
|
||||
|
||||

|
||||

|
||||
|
||||
## Project-level access controls
|
||||
|
||||
@ -28,7 +28,7 @@ As such:
|
||||
- **Developers**: This role restricts identities from performing project control actions, updating Approval Workflow policies, managing roles/members, and more.
|
||||
- **Viewer**: The most limiting bulit-in role on the project level – it forbids user and machine identities to perform any action and rather shows them in the read-only mode.
|
||||
|
||||

|
||||

|
||||
|
||||
## Creating custom roles
|
||||
|
||||
@ -41,4 +41,4 @@ By creating custom roles, you are able to adjust permissions to the needs of you
|
||||
It is worth noting that users are able to assume multiple built-in and custom roles. A user will gain access to all actions within the roles assigned to them, not just the actions those roles share in common.
|
||||
</Note>
|
||||
|
||||

|
||||

|
||||
|
@ -8,17 +8,17 @@ Certain environments and secrets are so sensitive that it is recommended to not
|
||||
|
||||
To provision temporary access through Web UI:
|
||||
1. Click on the `Edit` button next to the set of roles for user or identities.
|
||||

|
||||

|
||||
|
||||
2. Click `Permanent` next to the role or specific privilege that you want to make temporary.
|
||||
|
||||
3. Specify the duration of remporary access (e.g., `1m`, `2h`, `3d`).
|
||||

|
||||

|
||||
|
||||
4. Click `Grant`.
|
||||
|
||||
5. Click the corresponding `Save` button to enable remporary access.
|
||||

|
||||

|
||||
|
||||
<Note>
|
||||
Every user and machine identity should always have at least one permanent role attached to it.
|
||||
|
@ -9,7 +9,7 @@ An Infisical machine identity is an entity that represents a workload or applica
|
||||
|
||||
Each identity must authenticate with the API using a supported authentication method like [Universal Auth](/documentation/platform/identities/universal-auth) to get back a short-lived access token to be used in subsequent requests.
|
||||
|
||||

|
||||

|
||||
|
||||
Key Features:
|
||||
|
||||
|
Reference in New Issue
Block a user