If a Build's service account contains a secret, the secret should not be re-added if it is re-created

[tylerphelan]

This can happen if you use kp to create a secret, then delete it with kubectl, then create it with the same name.

When this happens build pods will fail to initialize with "duplicate volume" error.

[matthewmcnew]

We should also make kpack resilient to a service account with multiple secrets.

[noamichael]

Just ran into this - secrets are forced to be managed via kp:

kp create secret uses a Service Account to store image registry/git secrets. Later, when creating a build pod, kpack will setup an initContainer mounting the secret as a volume.

1. If a secret is created via kubectl, the default service account is not updated with the secret reference and builds will be unaware that the secret is available.

2. If a secret is deleted using kp image delete, then the command will remove the secrets from the service account. However, if kubectl is used to remove the secret, then the service account will not be updated and the old secret will remain on the service account. If the secret is then recreated, the service account will receive a duplicate key causing the initContainers mentioned above to fail to mount

Since all kpack objects are really kubernetes resources, a user should be able to manage them through the k8s api. One use case for creating secrets via kubectl is generically duplicating a namespace. For example, my team creates ephemeral build environments for feature testing, and we copy git-pull secrets from a develop environment to a temporary environment so as not to interfere with development.

[matthewmcnew]

Since all kpack objects are really kubernetes resources, a user should be able to manage them through the k8s api.

@noamichael The secrets/service accounts that kpack uses should be manageable via the k8s api. kp is just designed to make this process easier. kpack Secret/Service Account is available on the kpack repo.