Owner: Architect:

Francesco Ilario

Story (Required)

As a developer,
I would like to have data projected in my workload in different format (files, JSON, YAML, etc)
so that it is easier to integrate with the framework I use

Background (Required)

As of now, Primaza project data into workload in a Service Binding Spec compatible way.
We would also like to manipulate this data before projection happens.
Examples of manipulation are key remapping or formatting as JSON or YAML.

We want to introduce the projection field in Service Binding's and Service Claim's spec where to define the projectors to use.
In this story we will just focus on Service Binding Projector.

See epic for arch document link.

Glossary

See glossary in architecture document

Out of scope

• Projector for JSON, YAML, or other format

In Scope

• Service Binding Projector

Approach(Required)

Add a projections field to ServiceClaim and ServiceBinding spec.
The projections field will eventually have a subfield for each projector supported by Primaza (i.e., ServiceBindingSpec, JSON, YAML, etc).
Service Binding logic is already implemented and should be the default if no projection is defined.

spec: 
  # ...
  projections: 
    serviceBinding: 
    - root: /secrets
      mappings: 
      - key: pwd
        filename: password
    - root: /var/secrets
      mappings: 
      - key: pwd
        filename: pass

In the following you can find examples of the ServiceClaim and ServiceBinding updated yaml.

ServiceClaim

apiVersion: primaza.io/v1alpha1
kind: ServiceClaim
metadata: 
  name: psql-sc
  namespace: primaza-system
spec: 
  serviceClassIdentity: 
  - name: type
    value: psqlserver
  serviceEndpointDefinitionKeys: 
  - password
  environmentTag: stage
  application: 
    apiVersion: apps/v1
    kind: Pod
    name: newapp
  projections: 
    serviceBinding: 
    - root: /secrets
      mappings: 
      - key: pwd
        filename: password

ServiceBinding

apiVersion: primaza.io/v1alpha1
kind: ServiceBinding
metadata: 
  name: newapp-binding
  namespace: applications
spec: 
  serviceEndpointDefinitionSecret: demo
  application: 
    apiVersion: apps/v1
    kind: Pod
    name: newapp
  projections: 
    serviceBinding: 
    - root: /secrets
      mappings: 
      - key: pwd
        filename: password

Service Binding controller should:

• set the SERVICE_BINDING_ROOT environment variable to the value specified in projections.serviceBinding.root or default it to /secrets/
• if projections.serviceBinding.mappings is defined, use the mappings to generate the volumes.secret.items section of the secret's volume

As a result of applying the above ServiceBinding, the newapp pod should look like the following:

apiVersion: v1
kind: Pod
metadata: 
  labels: 
    run: newapp
  name: newapp
spec: 
  containers: 
  - image: bash:latest
    name: newapp
    command: 
    - sleep
    - infinite
    env: 
    - name: SERVICE_BINDING_ROOT
      value: /secrets
    volumeMounts: 
    - name: primaza-sbs-newapp-binding
      mountPath: /secrets/psqlserver
  volumes: 
  - name: primaza-sbs-newapp-binding
    secret: 
      secretName: demo
      optional: false
      items: 
      - key: pwd
        path: password

In the following you find the secret used for test

apiVersion: v1
kind: Secret
metadata: 
  name: demo
type: Opaque
data: 
  pwd: V2h5U29TZXJpb3VzPw==

Demo requirements(Required)

NA

Dependencies

NA

Edge Case

NA

BDD Tests

You can find BDD Test specification for this story in the "Testing Instruction" Field Tab or in the GitHub Issue linked to this story.
Click here for all BDD Tests Issues.

Acceptance Criteria

• Development
  ServiceClaim spec is updated with projections field
  ServiceBinding spec is updated with projections field
  Data is projected into workload taking care of projections.serviceBinding configuration

• QE
  There are test cases for a single projections.serviceBinding configuration
  There are test cases for multiple projections.serviceBinding configurations

• Docs
  There is a page in our Service Binding docs dedicated to explaining Service Binding's data projection
  Update architecture document with any changes while implementing

INVEST Checklist

Dependencies identified
Blockers noted and expected delivery timelines set
Design is implementable
Acceptance criteria agreed upon
Story estimated

Legend

Unknown
Verified
Unsatisfied