NSFS | NC | IAM Service - Phase 1 (dummy impls)

[shirady]

Explain the changes

1. Add the boilerplate implementation of the IAM service based on the S3 and STS services that were already implemented.
2. Add basic tests (only test the return structure).

Issues:

Gaps:

1. Check the error by AWS when the request doesn't contain the header 'application/x-www-form-urlencoded'.
2. Move the requesting account to be called from the accountSpace (currently it is copied).
3. Refactor endpoint.js and nsfs.js so the both will reuse the config.js values (and not process.env in some cases).
4. Consolidate the calls of the functions http_utils.authorize_session_token(req, headers_options); and authenticate_request(req); in one place and reuse in S3, STS and IAM.
5. In nb.d define the params in every action (even as an object inline).
6. Implement the simple flow in account SDK.
7. Parsing and validating the params (for example: username).
8. Remove unused errors that were copied from STS errors.

Testing Instructions:

Unit Tests

Those tests are basic and test the return structure of the API.
sudo npx jest test_accountspace_fs.test.js (without sudo will also work, but later tests in future PR will need the root permissions).

Manual Tests

These tests will only test the flow of the service (without any changes in the config files).

1. Create the root user account with the CLI: sudo node src/cmd/manage_nsfs account add --name shira-1002 --new_buckets_path /tmp/nsfs_root1 --access_key <access-key> --secret_key <secret-key> --uid <uid> --gid <gid>
   Note: before creating the account need to give permission to the new_buckets_path: chmod 777 /tmp/nsfs_root1.
2. Start the NSFS server with: sudo node src/cmd/nsfs --debug 5 --https_port_iam 7005
   Note: before starting the server please add this line: process.env.NOOBAA_LOG_LEVEL = 'nsfs'; in the endpoint.js (before the condition if (process.env.NOOBAA_LOG_LEVEL) {)
3. Create the alias for IAM service: alias s3-nc-user-1-iam='AWS_ACCESS_KEY_ID=<acess-key> AWS_SECRET_ACCESS_KEY=<secret-key> aws --no-verify-ssl --endpoint-url https://localhost:7005'.
4. Use AWS CLI to send requests to the IAM service, for example: s3-nc-user-1-iam iam create-user --user-name Bob --path '/division_abc/subdivision_xyz/' (more examples in the comment below)

Note: For checking the error parsing: comment out the return part in create_user and add throw new IamError(IamError.AccessDeniedException);.

• Doc added/updated
• Tests added

[shirady]

Manual Tests examples:

Note: assuming that you already created the alias s3-nc-user-1-iam as mentioned in the PR description in the Testing Instructions part.

user (CRUD)

• s3-nc-user-1-iam iam create-user --user-name Bob --path '/division_abc/subdivision_xyz/'
  • s3-nc-user-1-iam iam get-user (without --user-name flag)
• s3-nc-user-1-iam iam get-user --user-name Bob
• s3-nc-user-1-iam iam update-user --user-name Bob --new-user-name Robert --new-path '/division_abc/subdivision_abc/'
• s3-nc-user-1-iam iam delete-user --user-name Bob
• s3-nc-user-1-iam iam list-users

access keys (CRUD)

• s3-nc-user-1-iam iam create-access-key --user-name Bob
• s3-nc-user-1-iam iam get-access-key-last-used --access-key-id <access-key> (currently of the root account)
• s3-nc-user-1-iam iam update-access-key --access-key-id <access-key> --user-name Bob --status Inactive
• s3-nc-user-1-iam iam delete-access-key --access-key-id <access-key> --user-name Bob
• s3-nc-user-1-iam iam list-access-keys --user-name Bob

[guymguym]

approving with few small comments.
also I think this feature deserves its own design doc in docs/design/iam.md
we don't need all the details in that doc, but we should start pouring content into it to describe our rational, implementation, limitations, roadmap. I would already create it with this PR, even with a single paragraph if no more time.