Clarify inputs to the extender

Signed-off-by: Natalie Arellano <[email protected]>

Author: Natalie Arellano

content/docs/features/dockerfiles.md

@@ -8,10 +8,10 @@ summary="Dockerfiles can be used to extend base images for buildpacks builds"
 Buildpacks can do a lot, but there are some things buildpacks can't do. They can't install operating system packages,
 for example. Why not?
 
-Buildpacks run unprivileged (i.e, buildpacks do not run as the `root` user) and cannot make arbitrary changes to the
-filesystem. This enhances security, enables buildpack interoperability, and preserves the ability to rebase - but it
-comes at a cost. Base image authors must anticipate the OS-level dependencies that will be needed at build and run-time
-ahead of time, and this isn't always possible.
+Buildpacks do not run as the `root` user and cannot make arbitrary changes to the filesystem. This enhances security,
+enables buildpack interoperability, and preserves the ability to rebase - but it comes at a cost. Base image authors
+must anticipate the OS-level dependencies that will be needed at build and run-time ahead of time, and this isn't always
+possible.
 
 This has been a longstanding source of [discussion](https://github.com/buildpacks/rfcs/pull/173) within the CNB project:
 how can we preserve the benefits of buildpacks while enabling more powerful capabilities?

content/docs/reference/spec/migration/platform-api-0.9-0.10.md

@@ -77,8 +77,10 @@ Note: image extensions are not supported for Windows container images.
     * The new run image will be written to `analyzed.toml`
 * Invoke `restorer` with a new required argument (when using extensions): `-build-image`, a tag reference to the builder image in use
   * A new volume mount is introduced with target `/kaniko`; this volume must be writable by the `restorer` user
-* Invoke `extender` (new lifecycle binary) as the `root` user, instead of `builder`; the extender will use kaniko to apply the relevant generated Dockerfiles to the build image and then drop privileges to run the `build` phase
+* Invoke `extender` (new lifecycle binary), instead of `builder`; the extender will use kaniko to apply the relevant generated Dockerfiles to the build image and then drop privileges to run the `build` phase
   * The same volume from `restore` should be mounted at `/kaniko`
+  * The `extender` user should have sufficient permissions to execute all `RUN` instructions in each Dockerfile - typically, it should run as `root`
+  * Consult the [platform specification](https://github.com/buildpacks/spec/blob/main/platform.md) for the full list of configuration options for the `extender`
 * Invoke `exporter` as usual
   * If Dockerfiles for customizing the run image were output by extensions, the `exporter` will use the run image designated by the extension process