Introduction

This Blog Post consists of three parts and demonstrates, how you can use Helm 3 to run the Kubernetes Connector:

• Part 1: Running Infrastructure Kubernetes Connectors as CronJobs
• Part 2: Infrastructure Kubernetes Connector – Add an Application
• Part 3: Run a Kubernetes Connector with a Helm Hook

In the first article, the Infrastructure Kubernetes Connectors were set up. As a result, the ConfigSeeder & Infrastructure Kubernetes Connectors are ready to provision Secrets containing API Keys to the Kubernetes Clusters. And this is exactly what we will show in this follow-up article.

We recommend that you create a dedicated Configuration Group in ConfigSeeder for every Application. We also recommend that you create a dedicated namespace for every Application and Environment.

Part 2: Infrastructure Kubernetes Connector – Add an Application

Prepare Kubernetes

The new Application ‘Application 1’ will be set up in the following two Namespaces:

• application1-test
• application1-prod

Prepare rbac-apikey-role.yaml:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: kubernetes-connector-api-key
rules:
  - apiGroups: [""]
    resources: ["secrets"]
    verbs: ["create", "get", "patch", "update", "delete"]

Create the Namespaces and RBAC objects. In this step, the previously defined RBAC role is used.

kubectl create ns application1-test
kubectl create ns application1-prod
kubectl -n application1-test apply -f rbac-apikey-role.yaml
kubectl -n application1-prod apply -f rbac-apikey-role.yaml
kubectl create rolebinding -n application1-test kubernetes-connector-apikey --role="kubernetes-connector-apikey" --serviceaccount=kubernetes-connector-infrastructure:kubernetes-connector-test
kubectl create rolebinding -n application1-prod kubernetes-connector-apikey --role="kubernetes-connector-apikey" --serviceaccount=kubernetes-connector-infrastructure:kubernetes-connector-prod

Prepare ConfigSeeder

• Firstly, create the ConfigurationGroup Application 1. In this example, only the environment is relevant as filter criteria. Therefore, deactivate the other filter criteria.
  
  
  
• Secondly, open the Configuration Group Infrastructure Kubernetes Connector and create a Value Assembly of Type Secret: API Key:
  
  
  
  apiKey.type: Select the Type Kubernetes Connector if another Kubernetes Connector will use this Key to access the ConfigSeeder. However, if you plan to use the OS Connector as an Init Container, select Type OS Connector. Otherwise, use Type Client.
  meta.namespace: If the namespaces configured in Configseeder and Kubernetes don’t match, the Kubernetes Connector won’t be able to manage the API Key Secrets. Therefore use the same namespaces as configured in the Prepare Kubernetes section.
  meta.secretname: The Helm Template uses the name kubernetes-connector-apikey per default. You can either use this value as the secret name or you can override the attribute apiKeySecretName for the Kubernetes Connector responsible for managing the ConfigMaps and Secrets of the application.

View Results

As soon as the CronJobs have executed the Infrastructure Kubernetes Connectors, the new Secrets will be available in the Kubernetes Cluster.

kubectl get secret -n application1-test                 
NAME                          TYPE                                  DATA   AGE 
default-token-27rv6           kubernetes.io/service-account-token   3      12m 
kubernetes-connector-apikey   Opaque                                1      12s

kubectl get secret -n application1-prod 
NAME                          TYPE                                  DATA   AGE 
default-token-rw5ns           kubernetes.io/service-account-token   3      12m 
kubernetes-connector-apikey   Opaque                                1      10s

You can view the log of the Kubernetes Connectors:

kubectl logs -n kubernetes-connector-infrastructure kubernetes-connector-cronjob-test-...

...
time="2019-12-08T11:25:11+01:00" level=info msg="Received ApiKey for secret application1-test/kubernetes-connector-apikey" 
time="2019-12-08T11:25:12+01:00" level=info msg="Stored ApiKey for Application Application 1 in Secret application1-test/kubernetes-connector-apikey"
...

And look into the state of the Infrastructure Kubernetes Connector responsible for the environment TEST:

kubectl get cm -n kubernetes-connector-infrastructure kubernetes-connector-state-test -o json | jq -r .data.state | jq 
{ 
  "ModelVersion": "1", 
  "ObjectState": [ 
    { 
      "AssemblyName": "API Key Secret", 
      "AssemblyApplication": "Application 1", 
      "AssemblyType": "K8S_SECRET_API_KEY", 
      "Environment": "TEST", 
      "Name": "kubernetes-connector-apikey", 
      "LastAction": "CREATED", 
      "LastActionSuccessfull": true, 
      "Message": "", 
      "LastModified": "2019-12-08T11:30:13", 
      "AdditionalInfo": { 
        "namespace": "application1-test" 
      } 
    } 
  ] 
}

Conclusion

To sum up, we showed in this article how you should add a new application to ConfigSeeder. Setting the application up this way ensures that the Infrastructure Kubernetes Connectors are able to create and manage ConfigSeeder API Keys for the new application. In addition, we showed the resulting API Key secrets and how you can look into the actions the Kubernetes Connector is performing.

In the next article, we will show how you can execute a Kubernetes Connector as a pre-* Hook when installing an Application with a Helm Template.