Skip to content

Conversation

@timmc-edx
Copy link
Contributor

@timmc-edx timmc-edx commented Mar 11, 2025

  • Add deployment and configuration docs (and move some of that info out of the README)
  • Add prod_requirements target to make deployment instructions easier
  • Remove feature toggles docs, since we don't use Waffle
  • Removes Concepts, Getting Started, Internationalization, Quickstart, References, and How-Tos docs until we have something to put in there
  • Remove some make targets from Testing that don't actually exist
  • Remove auto-documentation of "API" (don't need doc pages for all of the Python modules, since this is an IDA, not a library)

Run make docs to preview.


Merge checklist:
Check off if complete or not applicable:

  • Version bumped
  • Changelog record added
  • Documentation updated (not only docstrings)
  • Unit tests added/updated
  • Manual testing instructions provided
  • Noted any: Concerns, dependencies, migration issues, deadlines, tickets

- Add deployment and configuration docs (and move some of that info out of
  the README)
- Add `prod_requirements` target to make deployment instructions easier
- Remove feature toggles docs, since we don't use Waffle
- Removes Concepts, Getting Started, Internationalization, Quickstart,
  References, and How-Tos docs until we have something to put in there
- Remove some make targets from Testing that don't actually exist
- Remove auto-documentation of "API" (don't need doc pages for all of the
  Python modules, since this is an IDA, not a library)
Comment on lines 23 to 27
This is intended to be run as a fully internal service with no database or admin frontend, with the LMS and CMS making calls to it unauthenticated. **It should not be callable directly from the internet.**

While the service uses AppArmor as a first (and really, only) line of defense, it should also be deployed in a way that does not allow direct connections to other IDAs or internal services within the Open edX deployment. In the ideal situation, networking would be set up to only allow outbound connections to a predetermined set of IPs or domains.

After any significant change to security settings, consider running the tests in ``./api_tests/``. These are run manually against a deployed service and can check for various sandbox weaknesses.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd note here something about the important of properly securing this service, and sending people to the deployment doc for details.


def on_init(app): # pylint: disable=unused-argument
"""
Run sphinx-apidoc after Sphinx initialization.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. Are swagger docs completely separate from all this?
  2. How does the LMS generate these docs? https://docs.openedx.org/projects/edx-platform/en/latest/references/lms_apis.html. Wouldn't we want something similar for this service?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Swagger is separate, yeah. I'll add that to #3 for future work.


The host or Docker image must be set up with a sandbox user, sandbox virtualenv, and sudoers file according to the documentation of the `codejail library <https://github.com/openedx/codejail>`__. This forms the foundation of the sandboxing, but does not provide much security by itself.

See `2U's Dockerfile <https://github.com/edx/public-dockerfiles/blob/main/dockerfiles/codejail-service.Dockerfile>`__ for an example of how you could set up your host or container. (There is not yet a Tutor plugin.)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like including a date for notes that you know will soon be outdated:

Suggested change
See `2U's Dockerfile <https://github.com/edx/public-dockerfiles/blob/main/dockerfiles/codejail-service.Dockerfile>`__ for an example of how you could set up your host or container. (There is not yet a Tutor plugin.)
See `2U's Dockerfile <https://github.com/edx/public-dockerfiles/blob/main/dockerfiles/codejail-service.Dockerfile>`__ for an example of how you could set up your host or container. (As of March 2025, there is not yet a Tutor plugin.)

Consider adding an issue/ticket to codejail-service for replacing references to 2U once the Tutor plugin exists. I'm not sure if it makes sense to make it a ticket for the Tutor plugin itself or not, but you can decide.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea, created #26 and will add a date here.


Again following the codejail library's instructions, create an AppArmor profile and load it into the host.

This profile will need to be customized according to your service's app user, sandbox setup, and other details. It will also look different if you are using Docker or running the service dierctly on the host. For reference, here is `2U's AppArmor profile <https://github.com/edx/public-dockerfiles/blob/main/apparmor/openedx_codejail_service.profile>`__; note that the inner profile is the one that actually applies the sandboxing.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
This profile will need to be customized according to your service's app user, sandbox setup, and other details. It will also look different if you are using Docker or running the service dierctly on the host. For reference, here is `2U's AppArmor profile <https://github.com/edx/public-dockerfiles/blob/main/apparmor/openedx_codejail_service.profile>`__; note that the inner profile is the one that actually applies the sandboxing.
This profile will need to be customized according to your service's app user, sandbox setup, and other details. It will also look different if you are using Docker or running the service directly on the host. For reference, here is `2U's AppArmor profile <https://github.com/edx/public-dockerfiles/blob/main/apparmor/openedx_codejail_service.profile>`__; note that the inner profile is the one that actually applies the sandboxing.

@timmc-edx timmc-edx mentioned this pull request Mar 12, 2025
6 tasks
@timmc-edx timmc-edx merged commit 12fdc81 into main Mar 12, 2025
7 checks passed
@timmc-edx timmc-edx deleted the timmc/docs branch March 12, 2025 14:04
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.

2 participants