cashapp / cmmc Goto Github PK

Currently, cmmc only supports doing JSONSchema validation.

It would be nice to support something like a custom validators via some syntax in the MergeTarget like:

   # ....
   data: 
     key:
       validator:
         url: <...>

For this to be usable, this should also have a proto definition of a request/response spec of a sort.

Possibly have this configured by an argument or an environment variable.

docs: MaxConcurrentReconciles

Move the kube-system/aws-auth example from the README to docs/

I have a config map with mapRoles and mapUsers define that I want CMMC to merge in the aws-auth configmap. Unfortunately, it only merge the mapUsers and ignore the mapRoles.

Here is my configmap CMMC will grab

apiVersion: v1
data:
  mapRoles: |
    - "groups":
      - "system:masters"
      "rolearn": "arn:aws:iam::261357321482:role/shuffle-labs-atlantis-dev-ecs_task_execution"
      "username": "atlantis"
  mapUsers: |
    - "groups":
      - "system:masters"
      "userarn": "arn:aws:iam::261357321482:user/ben"
      "username": "ben"
kind: ConfigMap
metadata:
  annotations:
    config.cmmc.k8s.cash.app/watched-by-merge-source: kube-system/aws-auth-map-users
  labels:
    cmmc.k8s.cash.app/merge: aws-auth-map
  name: aws-auth-mapping-cmmc
  namespace: kube-system

Here is the merged aws-auth configmap

apiVersion: v1
data:
  mapRoles: |
    - groups:
      - system:bootstrappers
      - system:nodes
      rolearn: arn:aws:iam::261357321482:role/shuffle-labs-private_eks-dev-eks-node
      username: system:node:{{EC2PrivateDNSName}}
  mapUsers: |
    - "groups":
      - "system:masters"
      "userarn": "arn:aws:iam::261357321482:user/ben"
      "username": "ben"
kind: ConfigMap
metadata:
  annotations:
    config.cmmc.k8s.cash.app/managed-by-merge-target: kube-system/kube-system-aws-auth
  name: aws-auth
  namespace: kube-system

After #10, the controller tests are fairly brittle and hard to change/read. Need to invest some time into cleaning them up so they are easier to understand.

Currently, we support adding JSONSchema as a field that is an inlined string, it would be nice to also be able to reference a ConfigMap here so it can be managed separately.

This is not super important, but can be a nice to have.

Document the custom metrics that are emitted by CMMC.

I wanna use cmmc for managing my eks auth but I did not find any information explaining how to deploy it on a kubernetes cluster.
Is there any guide I can follow?
Thanks

Currently, once a MergeTarget manages a ConfigMap, any changes to the managed resource will be overwritten by CMMC. It might be useful to allow a permissive mode to the MergeTarget (probably per key), so that a change to the target, as long as it doesn't intersect with anything that CMMC is writing, will be persisted.

Rough notes here on how this could work during reconciliation:

• we do all target CM data manipulation in MergeTarget.ReduceDataState
• While the output of the target config map is deterministic generally, the order of the merge depends on the order of the MergeSourceList, and we can make sure that this has a deterministic order as well (a subtask).
• If that merge order is deterministic, we should be able to do some simpler diffing to see what features has been added/removed given the prior Init state.
• We probably want to update the Init state to reflect this.
• If someone appends to the target CM, we currently have only one initial state, not a bunch of patches, so we would (in the current implementation), reorder the target. Does this matter? Would we be able to maintain this order going forward? Probably not since someone can then change contributing sources to add things so we might want to keep the simple thing here.

A simple workaround for this right now is to remove the MergeTarget and then create it without the missing key.

Ideally the behavior is that the key is reverted as if ^ the above action is taken.

I'd like to debug this issue by myself but there is no information about how to contribute / how to run the project locally.

This should either probably be resolved, or included in the design for:

• #3

Because JSON is a subset of YAML, we do YAML parse of everything that has a JSONSchema.

1. This should not be implicit
2. There should be options for this