Is your feature request related to a problem? Please describe.
With Kubernetes auth having been added in #2040, it is restricted to known ServiceAccount tokens. I'm not certain of the use-case here as the secret required in spec.vault.auth.kubernetes.secretRef.name should have a random value appended to the service account name. That aside, I think what #558 was asking for was for the cert-manager Deployment to authenticate to Vault using its own SA token.

Was the choice not to support 'ambient' credentials in Kubernetes a design decision or just not implemented?

Describe the solution you'd like
Support for cert-manager to auth to Vault using its own service-account and without Issuer CRDs to need access to or know the name of secrets. The flow here would be that cert-manager would default to its own JWT token for auth to Vault. The Issuers would not need to specify spec.vault.auth.kubernetes.secretRef in the config.

Additional context
The current use-case requires knowing the SA token name. This is because the secrets.name is populated after creation of v1/ServiceAccount. The Issuer requires runtime knowledge and isn't purely declarative. An alternative here is specifying a service account name and allowing cert-manager to find the associated token.

Environment details (if applicable):

• Kubernetes version (e.g. v1.10.2): 1.16
• Cloud-provider/provisioner (e.g. GKE, kops AWS, etc): n/a
• cert-manager version (e.g. v0.4.0): 0.11.0
• Install method (e.g. helm or static manifests): static manifests

/kind feature