|
1 | 1 | --- |
2 | | -title: "Access control (Coming Soon)" |
| 2 | +title: "Access control" |
3 | 3 | description: "How to restrict resources in a company environment" |
4 | 4 | group: administration |
5 | 5 | toc: true |
6 | 6 |
|
7 | 7 | --- |
| 8 | +According to CSDP [entity model]({{site.baseurl}}/docs/getting-started/entity-model/) you can in high level split them into 3 categories |
| 9 | +* entities that creating/updating/deleting them are fully controlled by the GitOps approach. |
| 10 | + * runtimes |
| 11 | + * git sources |
| 12 | + * pipelines (argo workflow/events resources workflowTemplate, sensor, eventsource etc...) |
| 13 | + * applications (argo cd/rollouts resources project, applicationSet, application, rollout) |
| 14 | +* Non GitOps controlled entities |
| 15 | + * Images |
| 16 | +* account configuration entities that are not controlled by the GitOps approach (will be supported in future releases). |
| 17 | + * account configuration collaborators |
| 18 | + * account configuration security |
| 19 | + * account configuration single sign-on |
| 20 | + * billing |
8 | 21 |
|
9 | | -For the time being only admin users of your account will be able to use Codefresh Argo Platform. |
| 22 | +## Full GitOps controlled entities |
| 23 | +CSDP is heavily based on the GitOps approach for storing the state of your account entities. |
10 | 24 |
|
11 | | -The full roles and permissions model will be released before going into GA. |
| 25 | +### Write permissions |
| 26 | +Due to this fact, this means that a user can go directly to the git repositories where the CSDP state is stored and update/create/delete files that will take direct effect on the state of the account. |
| 27 | + |
| 28 | +Every operation that a user will perform via CSDP clients (ui, cli) that is affecting a resource that is controlled by GitOps approach will be impersonated with the user git permissions. |
| 29 | + |
| 30 | +This means that a user will not be able to perform an operation from the CSDP clients if he was not able to do that him self directly via Git. |
| 31 | + |
| 32 | +In oreder to provide CSDP the ability to impersonate as the user, each user is required to provide his git credentials for every runtime. |
| 33 | + |
| 34 | +CSDP application proxy will securely store the git credentials and user them to perform operations against the git provider when needed and will also update CSDP platform with the read/write permissions to all existing defined repositories of the defined git sources in the runtime in order for the client to also make client side validation on operations |
| 35 | + |
| 36 | +In order to add your git personal token navigate to your [user settings](https://g.codefresh.io/2.0/user-settings) |
| 37 | + |
| 38 | +{% include |
| 39 | +image.html |
| 40 | +lightbox="true" |
| 41 | +file="/images/administration/access-control/pat.png" |
| 42 | +url="/images/administration/access-control/pat.png" |
| 43 | +alt="Add personal access token" |
| 44 | +caption="Add personal access token" |
| 45 | +max-width="100%" |
| 46 | +%} |
| 47 | + |
| 48 | +### Read view permissions |
| 49 | +CSDP stores the permissions that each user has to the underlying repositories of the git sources and will enforce read permissions via a simple logic of checking if the user has git permission to view the kubernetes manifest in the repository. |
| 50 | + |
| 51 | +This means that a user will not see a pipeline of he doesn't have ability to view the kubernets sensor manifest in his git provider. |
| 52 | + |
| 53 | +For entities that are dynamically created due to changes in resources that are controlled by GitOps approach, like workflows, the read permission will be derived from having permission to view the pipeline. |
| 54 | + |
| 55 | +Analytics information for the time being is not yet enforced according to pipeline read permissions but will be in the upcoming releases. |
| 56 | + |
| 57 | +Notification panel will also show notifications only on resources that the user has read permission on. |
| 58 | + |
| 59 | +### Write operations on dynamic created entities derived from GitOps controlled entities |
| 60 | +There are operations that users can perform on dynamic created entities like a workflow, like terminate and retry. |
| 61 | + |
| 62 | +These operations for the time being will be allowed for all users that has view permission to the workflow. |
| 63 | + |
| 64 | +## Non GitOps controlled entities |
| 65 | +For entities like images (for now only images) which is a resource that is being reported to CSDP on built artifacts and not stored in a GitOps approach for the time being users will be able to view all images. |
| 66 | + |
| 67 | +## Account configuration non GitOps based entities |
| 68 | +All account configuration entities are exposed under the account settings dedicated area in your account and are exposed only to account admins. |
| 69 | + |
| 70 | +CSDP provides a way to configure a user in the account as admin through the collaboration users screen. Marking a user as admin will provide him the ability to maintain all the above stated configurations. |
| 71 | + |
| 72 | +## Account runtime configuration |
| 73 | +The runtime configuration is also exposed in the account settings dedicated area and only exposed to admins but is fully controlled via the GitOps approach after installation. <br> |
| 74 | +This means that user with git write permission to the runtime installation repository can make changes to the runtime and create/delete/update git sources for that runtime. |
| 75 | +It was decided to still expose the runtime configuration under the account settings only to account admins because it makes sense but take into account that it can also be changed directly through git by non defined admin users in CSDP <br> |
| 76 | +CSDP admin users can see all runtimes and git sources for the time being even if they don't have read permission to the underlying git repository (a gap we will be looking to close) |
| 77 | + |
| 78 | +## Upcoming future of access control |
| 79 | +We are continuing to improve our access control model by adding another layer that will provide |
| 80 | +* ability to define permissions on write operations on entities that are not stored in a GitOps approach (like account configuration and workflow operations) |
| 81 | +* ability to define read permissions for entities that are not stored in GitOps approach at all |
| 82 | +* ability to define a more fine grained permission model for entities that are stored in a GitOps approach way but which is not sufficient |
| 83 | +* ability to define a more fine grained permission model for dynamic non GitOps controlled resources that were created from a GitOps controlled entity (like workflow) |
0 commit comments