Spec requirements on certificate secrets

[jpeach]

There are a number of interoperability questions about the use of secrets to store TLS keys and certificates. It may be helpful to have consolidated language to address these.

• If it is a TypedLocalReference, what kinds must an implementation support?
• Is the secret type required (e.g. v1.SecretTypeTLS)
  • If so, spec required types for server and client certificates, keys and CA bundles
• Can secret data have multiple keys?
• Are any specific secret data keys required?
• What secret data formats must be supported? Only PEM?
• Are multiple items allowed in a single secret data value (i.e multiple PEM blocks)
• How items can be combined (e.g. is it OK to have key, cert and CA bundle all in one secret)

There may be existing certificate specs that we can incorporate by reference; we could also choose to punt this issue to implementations.

[bowei]

For sure supported:

1. Kubernetes Secrets, as used today by Ingress V1; let's take what is the current requirements from that and pull it here. This is easy for users to interoperate with and we have a solid basis to go from.

It's a typed ref for extension to other systems. The easiest thing to do here is to make anything else Support: custom and put this into the backlog.

[youngnick]

/assign @youngnick

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[jpeach]

/reopen
/remove-lifecycle rotten

[k8s-ci-robot]

@jpeach: Reopened this issue.

In response to this:

/reopen
/remove-lifecycle rotten

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[hbagdi]

I believe this is all documented in Go doc comments. Is it safe to close this?

[robscott]

I believe so as well, feel free to reopen if not.