From 6257eec97c726effab29ada75d33e3de01742a50 Mon Sep 17 00:00:00 2001 From: Ryan Moran Date: Tue, 1 Nov 2022 14:16:31 -0700 Subject: [PATCH] Adds Kerberos Buildpack RFC --- text/0054-kerberos-buildpack.md | 56 +++++++++++++++++++++++++++++++++ 1 file changed, 56 insertions(+) create mode 100644 text/0054-kerberos-buildpack.md diff --git a/text/0054-kerberos-buildpack.md b/text/0054-kerberos-buildpack.md new file mode 100644 index 00000000..8ae116ba --- /dev/null +++ b/text/0054-kerberos-buildpack.md @@ -0,0 +1,56 @@ +# Introduce Kerberos Buildpack + +## Summary + +Introduce a buildpack that installs the [MIT +Kerberos](https://kerberos.org/dist/) libraries and executables such that +applications authenticating with Kerberos can do so on any of the supported +stacks. + +## Motivation + +Kerberos is currently supported for applications built on top of the Full +stack. This is enabled through the addition of the `krb5-user` package in our +stack definition. Unfortunately, the Full stack also includes a number of other +packages that many application developers would like to avoid installing. + +Creating a new Kerberos buildpack will allow these developers to make a more +focused addition to their application image be ensuring that only those +packages relating to Kerberos are installed. It will also allow the project to +support Kerberos on top of stacks that are not the Full stack without needing +to also include that package in these other stack definitions. + +## Detailed Explanation + +A new repository will be created at `paketo-buildpacks/kerberos`. This repo +will house a buildpack that has the singular purpose of installing the Kerberos +libraries and executables into a layer made available to other buildpacks or at +runtime. The buildpack will include Kerberos as a precompiled package that can +be dropped into a layer with support for Jammy only. The buildpack will follow +the existing provide/requires conventions, exposing a dependency called +`kerberos`. + +## Rationale and Alternatives + +An alternative would be to add the `krb5-user` package to the Base stack +images. Avoiding this would be preferrable as we should try not to increase the +scope or vectors of attack for our most commonly used stack image. + +## Implementation + +The implementation will use all of the new dependency management infrastructure +and so be contained to this one repository. The dependency will need to be +compiled against a Jammy stack and hosted by ourselves as no precompiled +distribution has been found. + +## Prior Art + +The most immediately similar example of this kind of library-installing +buildpack is the ICU buildpack that is used within the .NET Core language +family. + +## Unresolved Questions and Bikeshedding + +* Do we need to backport support to Bionic? +* Should we explore using stack extensions to implement this? +* What team should own this buildpack?