tlsutil

type CertConfig struct {
	// CertName is the name of the cert.
	CertName string
	// Optional CertType. Serving, client or both; defaults to both.
	CertType CertType
	// Optional CommonName is the common name of the cert; defaults to "".
	CommonName string
	// Optional Organization is Organization of the cert; defaults to "".
	Organization []string
	// Optional CA Key, if user wants to provide custom CA key via a file path.
	CAKey string
	// Optional CA Certificate, if user wants to provide custom CA cert via file path.
	CACert string
}

type CertGenerator interface {
	// GenerateCert generates a secret containing TLS encryption key and cert, a Secret
	// containing the CA key, and a ConfigMap containing the CA Certificate given the Custom
	// Resource(CR) "cr", the Kubernetes Service "Service", and the CertConfig "config".
	//
	// GenerateCert creates and manages TLS key and cert and CA with the following:
	// CA creation and management:
	// - If CA is not given:
	//  - A unique CA is generated for the CR.
	//  - CA's key is packaged into a Secret as shown below.
	//  - CA's cert is packaged in a ConfigMap as shown below.
	//  - The CA Secret and ConfigMap are created on the k8s cluster in the CR's namespace before
	//    returned to the user. The CertGenerator manages the CA Secret and ConfigMap to ensure it's
	//    unqiue per CR.
	// - If CA is given:
	//  - CA's key is packaged into a Secret as shown below.
	//  - CA's cert is packaged in a ConfigMap as shown below.
	//  - The CA Secret and ConfigMap are returned but not created in the K8s cluster in the CR's
	//    namespace. The CertGenerator doesn't manage the CA because the user controls the lifecycle
	//    of the CA.
	//
	// TLS Key and Cert Creation and Management:
	// - A unique TLS cert and key pair is generated per CR + CertConfig.CertName.
	// - The CA is used to generate and sign the TLS cert.
	// - The signing process uses the passed in "service" to set the Subject Alternative Names(SAN)
	//   for the certificate. We assume that the deployed applications are typically communicated
	//   with via a Kubernetes Service. The SAN is set to the FQDN of the service
	//   `<service-name>.<service-namespace>.svc.cluster.local`.
	// - Once TLS key and cert are created, they are packaged into a secret as shown below.
	// - Finally, the secret are created on the k8s cluster in the CR's namespace before returned to
	//   the user. The CertGenerator manages this secret to ensure that it is unique per CR +
	//   CertConfig.CertName.
	//
	// TLS encryption key and cert Secret format:
	// kind: Secret
	// apiVersion: v1
	// metadata:
	//  name: <cr-kind>-<cr-name>-<CertConfig.CertName>
	//  namespace: <cr-namespace>
	// data:
	//  tls.crt: ...
	//  tls.key: ...
	//
	// CA Certificate ConfigMap format:
	// kind: ConfigMap
	//   apiVersion: v1
	//   metadata:
	//     name: <cr-kind>-<cr-name>-ca
	//     namespace: <cr-namespace>
	//   data:
	//     ca.crt: ...
	//
	// CA Key Secret format:
	//  kind: Secret
	//  apiVersion: v1
	//  metadata:
	//   name: <cr-kind>-<cr-name>-ca
	//   namespace: <cr-namespace>
	//  data:
	//   ca.key: ..
	GenerateCert(cr runtime.Object, service *v1.Service, config *CertConfig) (*v1.Secret, *v1.ConfigMap, *v1.Secret, error)
}

type CertType int

type SDKCertGenerator struct {
	KubeClient kubernetes.Interface
}