Classic Confinement request: openapi-oathkeeper

[cerberauth]

To make the review of your request easier, please use the following template to provide all the required details and also include any other information that may be relevant.

---

• name: openapi-oathkeeper
• description: A CLI for generating Ory Oathkeeper rules from an OpenAPI 3 contract
• snapcraft: Snap built via GoReleaser. Config in the snapcrafts section of .goreleaser.yaml in the upstream repository (no standalone snapcraft.yaml).
• upstream: GitHub - cerberauth/openapi-oathkeeper: openapi-oathkeeper is a CLI for generating Ory Oathkeeper rules from an OpenAPI 3 contract and save a lot of time and effort, especially for larger projects with many endpoints or many services. · GitHub
• upstream-relation: Author & Maintainer
• supported-category: tools for local, non-root user driven configuration of/switching to development workspaces/environments
• reasoning: Tools access to arbitrary files (openapi and config files) on the host outside the snap’s runtime (eg, /usr) and can be outside personal-files and system-files

I understand that strict confinement is generally preferred over classic.

I’ve tried the existing interfaces to make the snap to work under strict confinement.

[jslarraz]

Hey @cerberauth

I don’t think openapi-oathkeeper fits in the tools for local, non-root user driven configuration of/switching to development workspaces/environments category. Moreover, the reasoning matches the unsupported reason: access to arbitrary files on the system due to developer/user inertia.

I think a strictly confined snap with home interface + manually connected removable-media makes more sense in this case.

Thanks!

[cerberauth]

Hi @jslarraz ,

Thank you for the clarification. I will proceed with strict confinement.

I do want to flag one situation that this approach does not fully cover. In many development environments openapi spec files are stored under system paths that fit developer workspace such as /var/ rather than under a user’s home directory.

With strict confinement and no straightforward workaround other the solution would be that the developer copy their openapi file into $HOME before running the CLI. That is not a great developer experience, and I am not sure it is a sustainable expectation for a tool primarily aimed at developers.

I understand the security rationale behind these rules but it does not offer a good developer experience. As a workaround, I will document this limitation clearly and direct affected users to the binary release as an alternative.

[jslarraz]

Thanks for your understanding

A usual approach is publishing the strictly confined snap to the store, which usually covers most scenarios. Distribute a classic snap directly from Github Releases for the rest of the users.

Of course this is up to you, but this way can still benefit from the snap dependencies model compared with directly distributing the binary artifact

Thanks!

[store-requests-bot]

This request has been added to the queue for review by the @reviewers team.