Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(feat): Define the naming pattern for auto-generated resources within the event-manager. #235

Closed
gianlucam76 opened this issue Aug 21, 2024 · 0 comments
Assignees
Milestone

Comments

@gianlucam76
Copy link
Member

Is your feature request related to a problem? Please describe.
In certain situations, responding to events may require deploying additional resources that rely not only on the resources that triggered the event but also on existing resources within the management cluster.

Image that for each managed cluster, there is a corresponding ConfigMap on the management cluster storing the server IP address, port, and certificate authority (CA) data. We use an EventSource to detect the creation of Secrets (type: kubernetes.io/service-account-token) within each managed cluster. These Secrets contain tokens used for authentication.

Our objective, in response to the creation of such Secret, is to generate Kubeconfig files that incorporate information from both sources:

  • Server and certificate authority data from the ConfigMaps.
  • The newly created service account token retrieved from the event (secret created).

Unfortunately, the current event-manager lacks the ability to directly fetch ConfigMap data. This is purposefully done as we don't want the event-manager to start watchers. Yet we want to be able to solve this use case as it is a pretty common one.

Describe the solution you'd like

Let's say EventTrigger, in a new configMapOrSecretGenerator section, reference following ConfigMap.

apiVersion: v1
kind: ConfigMap
metadata:
  name: calico-sa-token
  namespace: default
  annotations:
    projectsveltos.io/template: "ok"
    projectsveltos.io/instantiated-name: "{{ .Cluster.metadata.name }}-token"
data:
    token: {{ .Resource.data.token }}

Because the annotation projectsveltos.io/template: "ok" is present, event-manager is going to instantiate its content using the resource that generated the event. But instead of giving a random name (current case), it generates a ConfigMap with name using cluster name "{{ .Cluster.metadata.name }}-token"

Now because we know the name of the instantiated ConfigMap, we can list the generated ConfigMap in the templateResourceRefs section (so that addon-controller can fetch it and have the token at its disposal):

  - resource:
      apiVersion: v1
      kind: ConfigMap
      name: "{{ .Cluster.metadata.name }}-token"
      namespace: projectsveltos
    identifier: ConfigDataToken

The full EventTrigger becomes

apiVersion: lib.projectsveltos.io/v1beta1
kind: EventTrigger
metadata:
  name: tigera-federation-service-cluster-a
spec:
  sourceClusterSelector:
    matchLabels:
      federationid: cluster-a
  destinationClusterSelector:
    matchLabels:
      federationid: cluster-b
  eventSourceName: tigera-federation-service
  oneForEvent: true
  templateResourceRefs:
  - resource:
      apiVersion: v1
      kind: ConfigMap
      name: "{{ .Cluster.metadata.name }}"
    identifier: ConfigDataServerAndCert
  - resource:
      apiVersion: v1
      kind: ConfigMap
      name: "{{ .Cluster.metadata.name }}-token"
      namespace: projectsveltos
    identifier: ConfigDataToken
  policyRefs:
  - name: calico-remote-cluster-config
    namespace: default
    kind: ConfigMap
  configMapOrSecretGenerator:
  - name: calico-sa-token
    namespace: default
    kind: ConfigMap      

When an event happens, event-manager will:

  1. instantiate the default/calico-sa-token ConfigMap (referenced in the configMapOrSecretGenerator section). This creates a new one in the projectsveltos namespace with name "{{ .Cluster.metadata.name }}-token"
  2. create a ClusterProfile that fetches both the ConfigMap with managed cluster server and cert-auth and the ConfigMap created above that contains the token
  3. ClusterProfile will reference the ConfigMap default/calico-remote-cluster-config and deploy its content

The ConfigMap default/calico-remote-cluster-config is

apiVersion: v1
kind: ConfigMap
metadata:
  name: calico-remote-cluster-config 
  namespace: default
  annotations:
    projectsveltos.io/template: "ok"
    projectsveltos.io/event-skip-instantiation: "ok"
data:
  secrets.yaml: |
    {{ $token := .((getResource "ConfigDataToken")).data.token }}
    {{ $certauthdata := ((getResource "ConfigDataServerAndCert")).data.certauthdata }}
    {{ $server := (( getResource "ConfigDataServerAndCert")).data.server }}
    {{ $config := `     apiVersion: v1
      kind: Config
      users:
        - name: tigera-federation-remote-cluster
          user:
            token: %s
      clusters:
        - name: tigera-federation-remote-cluster
          cluster:
            certificate-authority-data: %s
            server: %s
      contexts:
        - name: tigera-federation-remote-cluster-ctx
          context:
            cluster: tigera-federation-remote-cluster
            user: tigera-federation-remote-cluster
      current-context: tigera-federation-remote-cluster-ctx `  }}
    ---
    apiVersion: v1
    data:
      datastoreType: {{ "kubernetes" | b64enc }}
      kubeconfig: {{ printf $config $token $certauthdata $server | b64enc }}
    kind: Secret
    metadata:
      name: remote-cluster-secret-name
      namespace: (( getResource "ConfigMap")).data.namespace      
@gianlucam76 gianlucam76 self-assigned this Aug 21, 2024
@gianlucam76 gianlucam76 added this to the v0.37.0 milestone Aug 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant