Skip to content

API authentication#406

Closed
mgrdevport wants to merge 6 commits intoaptly-dev:masterfrom
mgrdevport:api-auth
Closed

API authentication#406
mgrdevport wants to merge 6 commits intoaptly-dev:masterfrom
mgrdevport:api-auth

Conversation

@mgrdevport
Copy link

@smira
Thank you for making aptly, I really enjoy using it.

For secure api access I've included gin-jwt and implemented the basic authorization and authentication pattern.

New config file content:

  • apiSecretKey
    (string containing the api secret key)
  • apiUsers
    (dict containing username, password and array of roles)

Example:

...
"apiSecretKey": "supersecretkey",
"apiUsers": {  
    "admin": {
        "password": "admin",
        "roles": ["admin"]
    }
},
...

Modified system test:

  • config file creation with new content elements
  • added parameter --auth to use authentication on api system test
  • run api system test with or without authentication (see Makefile)

Modified Makefile:

  • new task system-test.api (standalone api authentication system test)
  • new task _system-test.api.noauth (standalone api system test without authentication - default)

Question:
Should we test the api with and without authentication when running default system test? We could do so if we add the task system-test.api to the default sytem-test or all.

Anonymous access without authentication is still granted if api users are not defined in the config file (backwards compatibility).

Currently there is only support for the role admin.

Security note:

Aptly config file should be read protected (plain passwords)
Secure api access with SSL to prevent security issues (Nginx, Apache, ...)

@smira
Copy link
Contributor

smira commented May 31, 2016

Thanks, this looks really interesting. I was looking more towards protecting API with nginx and basic auth if required, but this brings out of the box solution which might be good enough.

@mgrdevport
Copy link
Author

The documentation should recommend the usage of nginx/apache as SSL proxy. I am planning to use the api in conjunction with a continuous delivery server to update mirrors, create snapshots, publish tehm and as preparation for web frontends.

The return code for the SIGINT termination (t07_serve) of the process seems to be different when using go 1.5 / go 1.6 in the travis ci builds (1.5 -> 2, 1.6 -> **-**2).
The python documentation says that the return code for the signal N would be -N (at least on Unix).

@morph027
Copy link

morph027 commented Nov 6, 2016

@morph027
Copy link

morph027 commented Nov 6, 2016

Also this ;)

https://morph027.gitlab.io/post/push-deb-packages-from-ci-jobs-to-aptly-repo/

If you'd like, i can take care of the documentation for nginx/ssl setup here (once i figured out your gitlab-pages structure g)

@smira
Copy link
Contributor

smira commented Mar 16, 2017

@morph027 any docs are really welcome as PRs to https://github.com/aptly-dev/aptly-dev.github.io repository

@morph027
Copy link

Sure, will have a look at it tomorrow!

@sevki
Copy link

sevki commented Dec 5, 2018

has this been rejected?

@lbolla lbolla closed this Jan 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants