Skip to main content

Secret Management

Canary checker uses the Kubernetes ValuesFrom pattern to retrieve sensitive values like usernames, password and access keys.

Whenever a field uses the EnvVar object type you have the option of specifying the value in multiple ways.

  1. Statically in the value
  2. Via a Kubernetes Config Map via the configMapKeyRef
  3. Via a Kubernetes Secret via the secretKeyRef
  4. From a value of a deployed helm chart using helmRef
  5. From a service account using serviceAccount

Static Values​

Using a HTTP health check as an example for static values:

http-basic-auth-static.yaml
apiVersion: canaries.flanksource.com/v1
kind: Canary
metadata:
  name: http-basic-auth
spec:
  http:
    - url: https://httpbin.org/basic-auth/hello/world
      responseCodes: [200]
      authentication:
        username:
          value: hello
        password:
          value: world

Configmaps​

To use a configmap, we first need to create the configmap:

kubectl create configmap basic-auth --from-literal=user=hello --from-literal=pass=world -n default
http-basic-auth-configmap.yaml
apiVersion: canaries.flanksource.com/v1
kind: Canary
metadata:
  name: http-basic-auth-configmap
spec:
  http:
    - url: https://httpbin.org/basic-auth/hello/world
      responseCodes: [200]
      authentication:
        username:
          valueFrom:
            configMapKeyRef:
              name: basic-auth
              key: user
        password:
          valueFrom:
            configMapKeyRef:
              name: basic-auth
              key: pass

Secrets​

To use a secret, first we create the secret:

kubectl create secret generic basic-auth --from-literal=user=hello --from-literal=pass=world -n default
http-basic-auth-secret.yaml
apiVersion: canaries.flanksource.com/v1
kind: Canary
metadata:
  name: http-basic-auth-configmap
spec:
  http:
    - url: https://httpbin.demo.aws.flanksource.com/basic-auth/hello/world
      username:
        valueFrom:
          secretKeyRef:
            name: basic-auth
            key: user
      password:
        valueFrom:
          secretKeyRef:
            name: basic-auth
            key: pass

Helm Values​

To use a secret, first we deploy a helm chart

helm install podinfo  podinfo/podinfo -n podinfo --set ingress.enabled=true
http-from-helm.yaml
apiVersion: canaries.flanksource.com/v1
kind: Canary
metadata:
  name: http-from-helm
spec:
  http:
    - env:
        - name: url
          valueFrom:
            helmRef:
              name: podinfo
              key: .ingress.hosts[0].host

      url: $(url)

Service Accounts​

Checks can use service accounts for authentication with external services that have existing trust established

http-service-accounts.yaml
apiVersion: canaries.flanksource.com/v1
kind: Canary
metadata:
  name: http-basic-auth-configmap
spec:
  http:

    interval: 30
  http:
    - name: vault-example-sre
      description: "HashiCorp Vault functionality check."
      url:  https://vault.example/v1/auth/kubernetes/login
      env:
        - name: TOKEN
          valueFrom:
            serviceAccount: default-account
      templateBody: true
      body: |
        {
          "jwt": "$(TOKEN)",
          "role": "example-role"
        }

note

For service account token issuing the canary-checker service account canary-checker-sa will need to be granted permissions to issue tokens using:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: canary-checker-sa-issuing-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: canary-checker-sa-issuing
subjects:
  - kind: ServiceAccount
    name: canary-checker-sa
    namespace: canary-checker
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  creationTimestamp: null
  name: canary-checker-sa-issuing
rules:

- apiGroups: [""]
  resources:
  - "serviceaccounts/token"
  - "serviceaccounts"
  verbs:
  - "create"
  - "get

Recommendations

Kubernetes Secrets are, by default, stored unencrypted in the API server's underlying data store (etcd). Anyone with API access can retrieve or modify a Secret, and so can anyone with access to etcd. With this in mind, it is recommended to implement some level of security to prevent unauthorized access to your Kubernetes secrets. You may consider the following for your encryption and security needs: