define root level secrets and envFrom support

This commit allows defining root level secrets, as well as referencing those from the `envFrom` directive, which currently only supports configMaps. Minor refactors have been made in kubernetes.go to handle envFrom behavior for ConfigMaps and Secrets in a more consistent manner. The examples, related READMEs, and the file reference doc have also been modified to reflect the changes being brought upon. fixes kedgeproject#128 fixes kedgeproject#85
concaf · Jul 24, 2017 · 3ed3a23 · 3ed3a23
1 parent 83859a8
commit 3ed3a23
Show file tree

Hide file tree

Showing 5 changed files with 203 additions and 60 deletions.
diff --git a/docs/file-reference.md b/docs/file-reference.md
@@ -12,14 +12,13 @@ name: database
 containers:
 - image: mariadb:10
   env:
-  - name: MYSQL_ROOT_PASSWORD
-    valueFrom:
-      secretKeyRef:
-        name: wordpress
-        key: MYSQL_ROOT_PASSWORD
+  - name: APPVERSION
+    value: 0.3.0
   envFrom:
   - configMapRef:
       name: database
+  - secretRef:
+      name: wordpress
   volumeMounts:
   - name: database
     mountPath: /var/lib/mysql
@@ -39,6 +38,10 @@ volumeClaims:
 configMaps:
 - data:
     MYSQL_DATABASE: wordpress
+secrets:
+- name: wordpress
+  data:
+    MYSQL_ROOT_PASSWORD: YWRtaW4=
 ```
 
 # Root level constructs
@@ -120,17 +123,16 @@ simultaneously then the tool will error out.
 envFrom:
 - configMapRef:
     name: <string>
+- secretRef:
+    name: <string>
 ```
 
 This is similar to the envFrom field in container which is added since Kubernetes
-1.6. `envFrom` is a list of references. Right now the only reference that is
-supported is of `configMap`. The `configMap` that you refer here, all the data
-from that `configMap` will be populated as `env` inside the container.
+1.6. All the data from the ConfigMaps and Secrets referred here will be populated
+as `env` inside the container.
 
-The restriction being that the `configMap` also has to be defined in the file.
-If the `configMap` is not defined in the file under the root level field called
-`configMaps`, the tool will throw an error, since it has no way of knowing
-from where to populate the environment variables from.
+The restriction is that the ConfigMaps and Secrets also have to be defined in the
+file since there is no way to get the data to be populated.
 
 To read more about this field from the Kubernetes upstream docs see this:
 https://kubernetes.io/docs/api-reference/v1.6/#envfromsource-v1-core
@@ -401,21 +403,75 @@ More info about Probe: https://kubernetes.io/docs/api-reference/v1.6/#probe-v1-c
 
 The name of the Ingress.
 
+## secrets
+
+```yaml
+secrets:
+- <secret>
+- <secret>
+```
+
+| **Type**                         | **Required** |
+|----------------------------------|--------------|
+| array of [secret](#secret) | no           |
+
+###secret
+
+```yaml
+name: string
+<Kubernetes Secret Definition>
+```
+
+The Kubernetes Secret resource is being reused here.
+More info: https://kubernetes.io/docs/api-reference/v1.6/#secret-v1-core
+
+So, the Kubernetes Secret resource allows specifying the secret data as base64
+encoded as well as in plaintext.
+This would look in kedge as:
+
+```yaml
+secrets:
+- name: <name of the secret>
+  data:
+    <secret data key>: <base64 encoded value of the secret data>
+  stringData:
+    <secret data key>: <plaintext value of the secret data>
+```
+
+example:
+
+```yaml
+secrets:
+- name: wordpress
+  data:
+    MYSQL_ROOT_PASSWORD: YWRtaW4=
+    MYSQL_PASSWORD: cGFzc3dvcmQ=
+```
+
+#### Name
+
+`name: wordpress`
+
+| **Type** | **Required** |
+|----------|--------------|
+| string   | yes          |
+
+The name of the secret. This is a mandatory field.
+
 ## Complete example
 
 ```yaml
 name: database
 containers:
 - image: mariadb:10
   env:
-  - name: MYSQL_ROOT_PASSWORD
-    valueFrom:
-      secretKeyRef:
-        name: wordpress
-        key: MYSQL_ROOT_PASSWORD
+  - name: VERSION
+    value: v0.3.0
   envFrom:
   - configMapRef:
       name: database
+  - secretRef:
+      name: wordpress
   volumeMounts:
   - name: database
     mountPath: /var/lib/mysql
@@ -455,4 +511,8 @@ volumeClaims:
 configMaps:
 - data:
     MYSQL_DATABASE: wordpress
+secrets:
+- name: wordpress
+  data:
+    MYSQL_ROOT_PASSWORD: YWRtaW4=
 ```
diff --git a/examples/secrets/README.md b/examples/secrets/README.md
@@ -1,15 +1,26 @@
 # Using secrets
 
-Using secret is similar to any other pod. As of now this does not provide a way to create a secret but only to consume it.
-
 Creating secret:
 
-```bash
-oc create secret generic wordpress --from-literal='MYSQL_ROOT_PASSWORD=rootpasswd,DB_PASSWD=wordpress'
+Create a secret by defining it at the root level -
+```yaml
+secrets:
+- name: wordpress
+  data:
+    MYSQL_ROOT_PASSWORD: YWRtaW4=
+    MYSQL_PASSWORD: cGFzc3dvcmQ=
 ```
 
 Now consuming it, see the snippet from [db.yaml](db.yaml):
 
+```yaml
+  envFrom:
+  - secretRef:
+      name: wordpress
+```
+
+Alternatively, it can also be consumed by referencing it manually in `env:`
+
 ```yaml
   env:
   - name: MYSQL_ROOT_PASSWORD

diff --git a/examples/secrets/db.yaml b/examples/secrets/db.yaml
@@ -2,21 +2,19 @@ name: database
 containers:
 - image: mariadb:10
   env:
-  - name: MYSQL_ROOT_PASSWORD
-    valueFrom:
-      secretKeyRef:
-        name: wordpress
-        key: MYSQL_ROOT_PASSWORD
   - name: MYSQL_DATABASE
     value: wordpress
   - name: MYSQL_USER
     value: wordpress
-  - name: MYSQL_PASSWORD
-    valueFrom:
-      secretKeyRef:
-        name: wordpress
-        key: DB_PASSWD
+  envFrom:
+  - secretRef:
+      name: wordpress
 services:
 - name: database
   ports:
   - port: 3306
+secrets:
+- name: wordpress
+  data:
+    MYSQL_ROOT_PASSWORD: YWRtaW4=
+    MYSQL_PASSWORD: cGFzc3dvcmQ=
diff --git a/pkg/spec/spec.go b/pkg/spec/spec.go
@@ -45,9 +45,10 @@ type IngressSpecMod struct {
 	ext_v1beta1.IngressSpec `json:",inline"`
 }
 
-// EnvFromSource represents the source of a set of ConfigMaps
+// EnvFromSource represents the source of a set of ConfigMaps and Secrets
 type EnvFromSource struct {
 	ConfigMapRef *ConfigMapEnvSource `json:"configMapRef,omitempty"`
+	SecretRef    *SecretEnvSource    `json:"secretRef,omitempty"`
 }
 
 // ConfigMapEnvSource selects a ConfigMap to populate the environment
@@ -56,6 +57,11 @@ type ConfigMapEnvSource struct {
 	Name string `json:"name,omitempty"`
 }
 
+// SecretEnvSource selects a Secret to populate the environment variables with.
+type SecretEnvSource struct {
+	Name string `json:"name,omitempty"`
+}
+
 type Container struct {
 	// one common definitions for livenessProbe and readinessProbe
 	// this allows to have only one place to define both probes (if they are the same)
@@ -75,13 +81,19 @@ type PodSpecMod struct {
 	api_v1.PodSpec `json:",inline"`
 }
 
+type SecretMod struct {
+	Name          string `json:"name,omitempty"`
+	api_v1.Secret `json:",inline"`
+}
+
 type App struct {
 	Name                       string            `json:"name"`
 	Labels                     map[string]string `json:"labels,omitempty"`
 	VolumeClaims               []VolumeClaim     `json:"volumeClaims,omitempty"`
 	ConfigMaps                 []ConfigMapMod    `json:"configMaps,omitempty"`
 	Services                   []ServiceSpecMod  `json:"services,omitempty"`
 	Ingresses                  []IngressSpecMod  `json:"ingresses,omitempty"`
+	Secrets                    []SecretMod       `json:"secrets,omitempty"`
 	PodSpecMod                 `json:",inline"`
 	ext_v1beta1.DeploymentSpec `json:",inline"`
 }