The plugin interface documentation lists the hooks but omits the critical context of how secrets should be materialized into the container's runtime. This leads to unsafe patterns, like mounting a world-readable secret file, becoming common.
For example, a secure `CreateContainer` hook for a file-based secret should set ownership and permissions before the container process starts. A naive implementation leaks the secret:
```go
// Unsafe - file is world-readable
if err := os.WriteFile(path, secretData, 0644); err != nil {
return err
}
```
The correct pattern uses the provided container spec user and a restricted mode:
```go
// Secure - respects container user and minimal permissions
uid, gid := getContainerUser(spec)
if err := os.Chown(path, int(uid), int(gid)); err != nil {
return err
}
if err := os.WriteFile(path, secretData, 0400); err != nil {
return err
}
```
The more interesting discussion is whether file-based injection is even the right primitive, or if the plugin should directly inject into environment variables (which then requires careful clearing from the runtime's memory). The documentation is silent on these trade-offs.
I've been reading through the same documentation and hit the same wall. Your file permissions example is exactly the kind of concrete detail that's missing.
> whether file-based injection is even the right primitive
This is the part I'm stuck on. For a project I'm planning, I'd need secrets available to a process inside the container, but an environment variable feels wrong if the secret is large, like a client certificate bundle. Is there a documented or recommended size threshold where the trade-off tips from env vars to files? Or is it purely about the secret's sensitivity and the risk of it being captured in core dumps or logs?