Feature request: support uploading certs and keys directly as Kubernetes Secrets

[tsaarni]

Certyaml shall be able to store generated certificates to Kubernetes secrets, besides storing them in files in filesystem.

API description

Draft for the API:

(1) Store certificate and private key to secret ca in namespace default. By default the certificate is stored in file tls.crt and private key in file tls.key. Secret type will default to kubernetes.io/tls.

subject: cn=ca
kubernetes:
- secret: ca

(2) Store only certificate to secret ca in namespace myapp. Certificate is stored in file ca.pem. Secret type will default to Opaque.

subject: cn=ca
kubernetes:
- secret: myapp/ca
  certificate: ca.pem

(3) Store certificate and private key in secret server-cert in namespace default. The filenames are explicitly set. Certificate will be stored in file server.pem and private key in file server-key.pem. Secret type will default to Opaque.

subject: cn=server-cert
issuer: cn=ca
kubernetes:
- secret: server-cert
  certificate: server.pem
  key: server-key.pem

(4) Store CA certificate to verify clients in file ca.pem, server certificate in file tls.crt and private key in file tls.key. All files are stored in single secret server-credentials in namespace default. Secret type will default to kubernetes.io/tls.

subject: cn=server-ca
---
subject: cn=client-ca
kubernetes:
- secret: server-credentials
  certificate: ca.pem
---
subject: cn=server
issuer: cn=server-ca
kubernetes:
- secret: server-credentials

(5) Store certificate in file tls.crt and private key in file tls.key in secret client of type Opaque by overriding the default type for a secret with this content.

subject: cn=client
issuer: cn=client-ca
kubernetes:
- secret: client-credentials
  type: Opaque

When secret type is not explicitly set by user, it is determined automatically. The complete manifest is processed to collect a full list of secrets and their content before creating any secrets. Following rules are used to select type of each secret:

• When files tls.crt and tls.key are present and kubernetes.type is not set, then type kubernetes.io/tls is used by default.
• When files tls.crt and tls.key are missing and kubernetes.type is not set, then type Opaque is used by default.

If kubernetes.type is set multiple times using conflicting values, then processing is stopped and error is printed.

Example of invalid manifest:

subject: cn=ca
kubernetes:
- secret: server
  type: Opaque # error: server secret has conflicting types
---
subject: cn=server
issuer: cn=ca
kubernetes
- secret: server
  type: kubernetes.io/tls  # error: server secret has conflicting types