Skip to Content
Technical Articles
Author's profile photo Piotr Tesny

Kyma functions with GitRepository source with SSH authentication.

Kyma functions are managed custom resources in the underlying SAP Kyma Runtime k8s cluster.

There are two ways of managing functions source code: either using the inline editor or with a git repository.

While the inline source code is a perfect choice for quick prototyping it lacks versioning and is not suitable for continuous development/integration.

I shall demonstrate how to create a secure git repository connection to a kyma nodejs function source code using SSH keypair.

I shall also showcase how to extend the definition of a function object by adding environment variables into a config map.

Good to know:

  • one may need to connect to GitHub with SSH even to public repositories if for instance 2FA has been enabled for the GitHub account.

Putting it all together

Step 1a. Connecting to GitHub with SSH.

The first step is to either create a new pair of SSH keys or re-use the existing ones as described in the github documentation.

Then goto SSH Keys configuration screen in your GitHub account at https://github.com/settings/keys and add the public SSH key as depicted below:

cat ~/.ssh/id_rsa.pub

Good to know:

  • You can maintain several SSH keys in your GitHub account. For instance you might want to use different keys to segregate source code access to different development groups in different namespaces, etc.

Step 1b. Create a git repository secret in kyma, in a given namespace

In order for a kyma namespace to be able to grant access to git repository based functions source code and dependencies it will need to verify the public SSH key of the github repository in the repository connection with the private key of the SSH keypair.

Thus, a secret object in a given kyma namespace (I am using the default namespace) with the base64-encoded private key string must be created as depicted below:

The preferred option is to do it using the below kubectl command with the –from-file argument pointing to the private SSH key.

Why ? This is because this command will take care of encoding the private key into the base64-encoded string format.

$ ls ~/.ssh/id_rsa
/Users/<userid>/.ssh/id_rsa

$ kubectl -n default create secret generic git-creds-key3 --from-file=key=/Users/<userid>/.ssh/id_rsa --kubeconfig ~/.kube/kubeconfig.yaml

secret/git-creds-key3 created

Alternatively, you might want to use a yaml descriptor file to create a secret. However, then you would need to provide the base64-encoded SSH private key string yourself.

Please refer to appendix for further details.

Step 2. Create a GitHub repo connection in kyma

Git Repository (with public SSH key) Kyma namespace (with private SSH key)

Goto repository main branch level and retrieve the SSH connection string as the URL of your repository connection.

Goto Workloads/Functions/Repositories/Connect Repository

 

kubectl get crd gitrepositories.serverless.kyma-project.io -o yaml --kubeconfig ~/.kube/kubeconfig.yaml

Alternatively this can be done using a yaml file as described in the appendix below.

 

Step 3. Create a GitHub repo directory with function’s code and dependencies.

A function source code (handler.js) and dependencies (package.json) must be present in the git repository before creating the function object itself.

This is mandatory.

 

Step 4. Create a git repository connected function in kyma

After completing the previous step, one can create a function’s object in kyma as depicted below in the right hand side table column.

Alternatively, one may also opt for creating a function object using a function deployment yaml file. Especially, if there is need to create other objects like for instance config maps objects that are mapped to a function’s environment variables.

This is described in appendix in more details.

As soon as a function object has been created, the kyma reconciler will spot it and the function object will enter the build/deployment and then running phases.

 

Same behaviour is triggered with any code commit afterwards.

That makes the git repo based functions suitable for automated development lifecycle management.

 


 

Appendix

 

a. create a git repository secret with yaml file

$ kubectl apply -n default --kubeconfig ~/.kube/kubeconfig.yaml -f - <<EOF
 apiVersion: v1
 kind: Secret
 metadata:
   name: git-creds-key3
   namespace: default
 type: Opaque
 data:
   key: LS0tLS1CRUdJTUFBQUVibTl1W0hQUklWQVRFS0VZLS0tLS0=
 EOF
secret/git-creds-key2 created

 

b. create a git repository connection (name: poster)

$ kubectl apply -n default --kubeconfig ~/.kube/kubeconfig.yaml -f - <<EOF
 apiVersion: serverless.kyma-project.io/v1alpha1
 kind: GitRepository
 metadata:
   name: poster
   namespace: default
 spec:
   url: "git@github.com:<repo root>/RTH10.git"
   auth:
     type: "key"
     secretName: "git-creds-key3"
 EOF
gitrepository.serverless.kyma-project.io/poster created

 

c. create a git repository connected function from yaml with kubectl

$ kubectl apply -n default --kubeconfig ~/.kube/kubeconfig.yaml -f - <<EOF
 apiVersion: serverless.kyma-project.io/v1alpha1
 kind: Function
 metadata:
   name: demo-poster
   namespace: default
 spec:
   labels:
     podLabel1: data1
   minReplicas: 1
   maxReplicas: 1
   type: git              # git repo function
   runtime: nodejs14      # function runtime
   source: poster         # git repo connection name
   reference: main        # git repo branch name
   baseDir: /demo/poster  # directory path to function source code
   env:
     - name: "DATA"
       value: "123"
     - name: DATA_FROM_CM
       valueFrom:
         configMapKeyRef:
           name: demo-poster
           key: superData
     - name: DATA2_FROM_CM
       valueFrom:
         configMapKeyRef:
           name: demo-poster
           key: superData2
     - name: DATA3_FROM_CM
       valueFrom:
         configMapKeyRef:
           name: demo-poster
           key: superData3
 ---
 apiVersion: v1
 kind: ConfigMap
 metadata:
   name: demo-poster
 data:
   superData: 
     "{}"
   superData2: 
     "{}"
   superData3: 
     "{}"
 EOF
function.serverless.kyma-project.io/demo-poster created
configmap/demo-poster created

Assigned Tags

      2 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Mohanraj Chandrasekar
      Mohanraj Chandrasekar

      I am facing the issue, which my repository was inside the secured network. Due to that the KYMA was not able to reach the repository.

      Do you have any suggestions how to resolve this issue please.

      Thanks in advance

      Author's profile photo Piotr Tesny
      Piotr Tesny
      Blog Post Author

      Hello Mohanraj Chandrasekar,

      Private and public git repositories are supported with kyma functions. With both basic authentication and secured with ssh key.

      However, assuming, you are using SAP BTP, Kyma runtime these git repositories must be internet facing. If you are not able to have your company git repos accessible over the public internet the only other way, known to me at this time, is to resort to using inline functions - in this case the source code of a function is kept in a config map, part of the function CRD inside the kyma cluster.

      Please refer to the official kyma documentation for all details: https://kyma-project.io/docs/kyma/latest/05-technical-reference/00-custom-resources/svls-02-gitrepository/

      I hope that helps; kind regards; Piotr