Upstream/harbor
1
0
Fork 0
mirror of https://github.com/goharbor/harbor.git synced 2024-09-29 05:47:31 +02:00
Code Issues Projects Releases Wiki Activity

RBAC use cases

Browse Source
This commit is contained in:
Henry Zhang 2016-10-26 23:32:58 +08:00
parent 9f043586f1
commit 7203e42490
8 changed files with 363 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

74
tests/testcases/Group3-RBAC/3-01-DB-user-manage-project-members.md Normal file
View File

@ -0,0 +1,74 @@
Test 3-01 - Manage Project Members (DB Mode)
=======
# Purpose:
To verify that a non system admin user can add members of various roles to a project when users are managed locally by Harbor (DB mode).
# References:
User guide
# Environment:
* This test requires that a Harbor instance is running and available.
* Harbor is set to authenticate against a local database. ( auth_mode is set to **db_auth** .) The user data is stored in a local database.
* A linux host with Docker CLI installed (Docker client).
* At least three non-admin users are in Harbor.
# Test Steps:
**NOTE:**
* In below test, user A, B and C are non system admin users. User A, B, C and project X should be replaced by longer and meaningful names.
* MUST use two kinds of browsers at the same time to ensure independent sessions. For example, use Chrome and Firefox, or Chrome and Safari.
* DO NOT use the same browser to log in two users at the same time in different windows(tabs).
1. Log in to UI as user A (non-admin).
2. Create a new project X with publicity is off (default).
3. Verify that user A cannot change his/her own role of project X.
4. On a Docker client host, use `docker login <harbor_host>` to log in as user A.
5. Push an image to project X.
6. On the Docker client host, log out user A and log in as user B.
7. Use `docker pull` to pull the image from project X. (should fail)
8. Use `docker push` to push an image to project X. (should fail)
9. Keeps user A's UI session logging on, in a different browser log in as user B.
10. User B views "My Projects", should not see project X.
11. In user A's UI, add user B to project X as a guest.
12. In user B's UI, check project X is in "My projects" and view members and images of project X.
13. Verify that user B cannot change role of other members in project X.
14. Verify that user B cannot add a new member to project X.
15. On a Docker client host, user B again pulls the image from project X.
16. user B pushes a new image to project X. (should fail)
17. In user A's UI, update user B to developer role of project X.
18. In user B's UI, check project X is in "My projects" and view members and images of project X.
19. Verify that user B cannot change role of other members in project X.
20. Verify that user B cannot add a new member to project X.
21. On a Docker client host, user B pushes a new image to project X.
22. In user A's UI, update user B to project admin role of project X.
23. In user B's UI, check project X is in "My projects" and view members and images of project X.
24. Verify that user B can add a new member user C to project X.
25. Verify that user B can change role of user C in project X.
26. On a Docker client host, user B pushes a new image to project X.
27. In user A's UI, remove user B from project X.
28. On a Docker client host, user B pulls an image of project X. (should fail)
29. On a Docker client host, log out user B and log in as user C.
30. User C pulls an image of project X.
# Expected Outcome:
* Step 3, user B cannot change his/her own role, and cannot remove himself/herself from project X.
* Step 7, user B should fail to pull image from project X.
* Step 8, user B should fail to push image to project X.
* Step 9, make sure to keep A's session while using another browser to log in as user B.
* Step 10, user B should not see project X.
* Step 12-14, as described.
* Step 15, user B can pull the image of project X,
* Step 16, user B cannot push images to project X.
* Step 18-20, as described.
* Step 21, user B pushes an image successfully.
* Step 23-25, as described.
* Step 28, user B's pulling should fail
* Step 30, user C's pulling should succeed.
# Possible Problems:
None

49
tests/testcases/Group3-RBAC/3-02-DB-user-manage-project-publicity.md Normal file
View File

@ -0,0 +1,49 @@
Test 3-02 - Manage Project Publicity (DB Mode)
=======
# Purpose:
To verify that a non system admin user can change project publicity of a project when users are managed locally by Harbor (DB mode).
# References:
User guide
# Environment:
* This test requires that a Harbor instance is running and available.
* Harbor is set to authenticate against a local database. ( auth_mode is set to **db_auth** .) The user data is stored in a local database.
* A linux host with Docker CLI installed (Docker client).
* At least three non-admin users are in Harbor.
# Test Steps:
**NOTE:**
* In below test, user A, B are non system admin users. User A, B and project X should be replaced by longer and meaningful names.
* MUST use two kinds of browsers at the same time to ensure independent sessions. For example, use Chrome and Firefox, or Chrome and Safari.
* DO NOT use the same browser to log in two users at the same time in different windows(tabs).
1. Log in to UI as user A (non-admin).
2. Create a new project X with publicity is on.
3. On a Docker client host, use `docker login <harbor_host>` to log in as user A.
4. Push an image to project X.
5. On the Docker client host, log out user A and log in as user B.
6. User B pulls an image from project X.
7. Keeps user A's UI session logging on, in a different browser log in as user B.
8. User B views "My Projects", should not see project X.
9. User B views "Public Projects", should see project X.
10. In user A's UI, change publicity of project X to off.
11. In user B's UI, user B checks "My Projects" and "Public Projects", should not see project X in both places.
12. On the Docker client host, user B pulls an image from project X. (should fail)
13. In user A's UI, change publicity of project X to on again.
14. User B views "My Projects", should not see project X.
15. User B views "Public Projects", should see project X.
# Expected Outcome:
* Step 6, user B's pulling image from project X should succeed.
* Step 7, make sure to keep A's session while using another browser to log in user B.
* Step 8-11, as described.
* Step 12, user B's pulling should fail.
* Step 13-15, as described.
# Possible Problems:
None

40
tests/testcases/Group3-RBAC/3-03-DB-user-search-project-members.md Normal file
View File

@ -0,0 +1,40 @@
Test 3-03 - Search Project Members (DB Mode)
=======
# Purpose:
To verify that a non system admin user can search members of a project when users are managed locally by Harbor (DB mode).
# References:
User guide
# Environment:
* This test requires that a Harbor instance is running and available.
* Harbor is set to authenticate against a local database. ( auth_mode is set to **db_auth** .) The user data is stored in a local database.
* A linux host with Docker CLI installed (Docker client).
* At least five(5) non-admin users are in Harbor.
# Test Steps:
**NOTE:**
* In below test, user A, B are non system admin users. User A, B and project X should be replaced by longer and meaningful names.
* MUST use two kinds of browsers at the same time to ensure independent sessions. For example, use Chrome and Firefox, or Chrome and Safari.
* DO NOT use the same browser to log in two users at the same time in different windows(tabs).
1. Log in to UI as user A (non-admin).
2. Create a new project X.
3. Add user B as a project admin role of project X.
4. Add 3 more members to project X with various roles, such as developer, guest.
5. Keeps user A's UI session logging on, in a different browser log in as user B.
6. In user B's UI, search members of project X using different criteria (keywords).
7. In user A's UI, change user B's role to developer of project X.
8. In user B's UI, search members of project X using different criteria.
9. In user A's UI, change user B's role to guest of project X.
10. In user B's UI, search members of project X using different criteria.
# Expected Outcome:
* Step 6,8,10, user B should see results based on search keywords.
# Possible Problems:
None

31
tests/testcases/Group3-RBAC/3-04-LDAP-user-manage-project-members.md Normal file
View File

@ -0,0 +1,31 @@
Test 3-04 - Manage Project Members (LDAP Mode)
=======
# Purpose:
To verify that a non system admin user can add members of various roles to a project in LDAP mode.
# References:
User guide
# Environment:
* This test requires that a Harbor instance is running and available.
* Harbor is set to authenticate against an LDAP or AD server. ( auth_mode is set to **ldap_auth** .) The user data is stored in an LDAP or AD server.
* A linux host with Docker CLI installed (Docker client).
* At least three non-admin users are in Harbor.
# Test Steps:
**NOTE:**
* In below test, user A, B and C are non system admin users. User A, B, C and project X should be replaced by longer and meaningful names.
* MUST use two kinds of browsers at the same time to ensure independent sessions. For example, use Chrome and Firefox, or Chrome and Safari.
* DO NOT use the same browser to log in two users at the same time in different windows(tabs).
Same as Test 3-01.
# Expected Outcome:
Same as Test 3-01.
# Possible Problems:
None

31
tests/testcases/Group3-RBAC/3-05-LDAP-user-manage-project-publicity.md Normal file
View File

@ -0,0 +1,31 @@
Test 3-05 - Manage Project Publicity (LDAP Mode)
=======
# Purpose:
To verify that a non system admin user can change project publicity of a project in LDAP mode.
# References:
User guide
# Environment:
* This test requires that a Harbor instance is running and available.
* Harbor is set to authenticate against an LDAP or AD server. ( auth_mode is set to **ldap_auth** .) The user data is stored in an LDAP or AD server.
* A linux host with Docker CLI installed (Docker client).
* At least three non-admin users are in Harbor.
# Test Steps:
**NOTE:**
* In below test, user A, B are non system admin users. User A, B and project X should be replaced by longer and meaningful names.
* MUST use two kinds of browsers at the same time to ensure independent sessions. For example, use Chrome and Firefox, or Chrome and Safari.
* DO NOT use the same browser to log in two users at the same time in different windows(tabs).
Same as Test 3-02.
# Expected Outcome:
Same as Test 3-02
# Possible Problems:
None

26
tests/testcases/Group3-RBAC/3-06-LDAP-user-search-project-members.md Normal file
View File

@ -0,0 +1,26 @@
Test 3-06 - Search Project Members (LDAP Mode)
=======
# Purpose:
To verify that a non system admin user can search members of a project in LDAP mode.
# References:
User guide
# Environment:
* This test requires that a Harbor instance is running and available.
* Harbor is set to authenticate against an LDAP or AD server. ( auth_mode is set to **ldap_auth** .) The user data is stored in an LDAP or AD server.
* A linux host with Docker CLI installed (Docker client).
* At least five(5) non-admin users are in Harbor.
# Test Steps:
Same as Test 3-03.
# Expected Outcome:
* Same as Test 3-03.
# Possible Problems:
None

78
tests/testcases/Group3-RBAC/3-11-DB-admin-user-manage-project-members.md Normal file
View File

@ -0,0 +1,78 @@
Test 3-11 - Admin Manages Project Members (DB Mode)
=======
# Purpose:
To verify that an admin user can add members of various roles to a project. Users are managed locally by Harbor (DB mode).
# References:
User guide
# Environment:
* This test requires that a Harbor instance is running and available.
* Harbor is set to authenticate against a local database. ( auth_mode is set to **db_auth** .) The user data is stored in a local database.
* A linux host with Docker CLI installed (Docker client).
* At least three non-admin users are in Harbor.
* At least one project that admin user is not a member of.
# Test Steps:
**NOTE:**
* In below test, user A, B and C are non system admin users. User A, B, C and project X should be replaced by longer and meaningful names.
* MUST use two kinds of browsers at the same time to ensure independent sessions. For example, use Chrome and Firefox, or Chrome and Safari.
* DO NOT use the same browser to log in two users at the same time in different windows(tabs).
1. Log in to UI as admin user.
2. Look for an existing project X that admin is not a member of.
3. Add user A to project X as project admin.
4. Add user B to project X as developer.
5. Add user C to project X as guest.
6. On a Docker client host, use `docker login <harbor_host>` to log in as admin.
7. Use `docker push` to push an image to project X.
8. Use `docker pull` to pull the image from project X.
9. On a Docker client host, log out admin and log in as user A.
10. Use `docker push` to push an image to project X.
11. Use `docker pull` to pull the image from project X.
12. On a Docker client host, log out user A and log in as user B.
13. Use `docker push` to push an image to project X.
14. Use `docker pull` to pull the image from project X.
15. On a Docker client host, log out user B and log in as user C.
16. Use `docker pull` to pull the image from project X.
17. Use `docker push` to push an image to project X. (should fail)
18. Keeps admin's UI session logging on, in a different browser log in as user C.
19. In user C's UI, verify his/her role is guest of project X.
20. In admin's UI, change user C's role to developer of project X.
21. In user C's UI, verify his/her role is developer of project X.
22. On a Docker client host, log in as user C.
23. Use `docker pull` to pull the image from project X.
24. Use `docker push` to push an image to project X.
25. In admin's UI, change user C's role to project admin of project X.
26. In user C's UI, verify his/her role is project admin of project X.
27. In admin's UI, remove user C's from project X.
28. Set project X's publicity to on.
29. On a Docker client host, log in as user C.
30. Use `docker pull` to pull the image from project X.
31. Use `docker push` to push an image to project X. (should fail)
32. In admin's UI, remove user C's from project X.
33. Set project X's publicity to off.
34. On a Docker client host, log in as user C.
35. Use `docker pull` to pull the image from project X. (should fail)
36. Use `docker push` to push an image to project X. (should fail)
# Expected Outcome:
* Step 7,8,10,11,16 should succeed.
* Step 17 should report errors.
* Step 19,21, as described.
* Step 23,24 should succeed.
* Step 26 as described.
* Step 30 should succeed.
* Step 31 should fail.
* Step 35-36 should fail.
# Possible Problems:
None

34
tests/testcases/Group3-RBAC/3-12-DB-admin-user-search-project-members.md Normal file
View File

@ -0,0 +1,34 @@
Test 3-12 - Admin Search Project Members (DB Mode)
=======
# Purpose:
To verify that an admin user can search members of a project when users are managed locally by Harbor (DB mode).
# References:
User guide
# Environment:
* This test requires that a Harbor instance is running and available.
* Harbor is set to authenticate against a local database. ( auth_mode is set to **db_auth** .) The user data is stored in a local database.
* A linux host with Docker CLI installed (Docker client).
* At least five(5) non-admin users are in Harbor.
* At least 5 members in a project that admin user is not a member of.
# Test Steps:
**NOTE:**
* In below test, user A, B are non system admin users. User A, B and project X should be replaced by longer and meaningful names.
* MUST use two kinds of browsers at the same time to ensure independent sessions. For example, use Chrome and Firefox, or Chrome and Safari.
* DO NOT use the same browser to log in two users at the same time in different windows(tabs).
1. Log in to UI as admin.
2. Look for an existing project X that admin is not a member of, project X should have at least 5 members.
3. Search members of project X using different criteria (keywords).
# Expected Outcome:
* Step 3, admin should see results based on search keywords.
# Possible Problems:
None