Automate `spec/features/security` like `import_export/model_configuration_spec.rb`
Description
spec/features/security
exists for testing user permissions, such as "admin" can access "GET /profile/keys", but "visitor" can not. However, this test is not fully covering all endpoints and roles. So that, underlying bugs such as gitlab-foss!9759 (merged) appear occasionally. Also, there is a concern of security for the rest of the endpoints which is not implemented in the folder.
On the other hands, spec/lib/gitlab/import_export/model_configuration_spec.rb
exists for helping developers to handle Import/Export feature when they add a new model.
For example, you'll get the following message, if you've added a new model.
New model(s) <trigger_schedule> have been added, related to Trigger, which is exported by
the Import/Export feature.
If you think this model should be included in the export, please add it to IMPORT_EXPORT_CONFIG.
Definitely add it to MODELS_JSON to signal that you've handled this error and to prevent it from showing up in the future.
MODELS_JSON: /builds/dosuken123/gitlab-ce/spec/lib/gitlab/import_export/all_models.yml
IMPORT_EXPORT_CONFIG: /builds/dosuken123/gitlab-ce/lib/gitlab/import_export/import_export.yml
I think spec/features/security
can be organized like import_export/model_configuration_spec.rb
. Spec detects automatically newly added endpoints and make developers handle the endpoint's user permissions.
Proposal
Step 1: If the developer adds new endpoints, the pipeline gets a warning, for example,
New endpoint(s) <projects/pipelines#stage> have been added, which is exposed to the whole world.
Please update the following files to explicit user permissions for the new endpoint.
- /builds/dosuken123/gitlab-ce/spec/features/security/endpoints_public_project.yml
- /builds/dosuken123/gitlab-ce/spec/features/security/endpoints_private_project.yml
- /builds/dosuken123/gitlab-ce/spec/features/security/endpoints_internal_project.yml
Later on, security tests will be executed according to the files.
Step 2: The developer defines user permissions, for example,
# spec/features/security/endpoints_public_project.yml
projects:
settings:
ci_cd:
show:
admin: allowed
owner: allowed
master: allowed
developer: denied
reporter: denied
guest: denied
user: denied
external: denied
visitor: denied
pipelines:
stage:
admin: allowed
owner: allowed
master: allowed
developer: allowed
reporter: allowed
guest: allowed
user: allowed
external: allowed
visitor: allowed
# spec/features/security/endpoints_private_project.yml
...
# spec/features/security/endpoints_internal_project.yml
...
Step 3: The security tests will be executed according to the files, for example, if the new endpoint fails the test,
Failures:
1) Private Project Access GET /:project_path/pipelines/:id/stage should be denied for visitor
Failure/Error: it { is_expected.to be_denied_for(:visitor) }
expected "/namespace216/gitlabhq/pipelines/20/stage" to be denied for visitor
# ./spec/features/security/project/private_access_spec.rb:404:in `block (3 levels) in <top (required)>'
Concerns
- This test would be a heavy process. (So that,
spec/features/security
doesn't cover all??) - It's possible to fully automate security implementation with YAML file (i.e. Moving authorization coding from controllers to the YAML file), however, it seems not so feasible.
/cc @briann