spiffe / helm-charts-flex Goto Github PK

In a custom plugin, the pattern is

plugins {
  <pluginType> <pluginName> {
     plugin_data {
         plugin_cmd = "/usr/bin/customKeyManager"
         plugin_checksum = "3f363c538588bbbbbcbe5374274c2c01f0d1387e012b68a22178e3dd790dc26c"
         enabled = true
         plugin_data {
            <stuff>
         }
     }
  }
}

Currently our custom plugins permit the user to set the custom plugin name.

The following items are not clear:

• Should the name be specified by the user
• Should the name be hardwired to "custom" or some other fixed string
• Does the name have to match the custom plugin in some way

We should decide on which if the above policies is the correct one, document it, and adjust the charts to enforce the policy

We need to alter the defaults to add the deployment name into the path of the disk keymanager hostpath volume. That way one can perform the following commands

helm install aaa spire-flex-<version>.tgz
helm install bbb spire-flex-<version>.tgz

without the two deployments interacting with each other.

If possible, place the configuration.md documentation into the helm chart (zip) bundle.

When the agent pod is initializing with the Disk KeyManager activated, it will mount a hostPath volume in order to have a persistent location for the KeyManager's backing store. The problem is that such a location might not exist within a typicaly operating system.

What is needed is an initcontainer within the daemonset that performs the corresponding OS "mkdir" command to install the directory such that the hostPath volume can be created unblocking the launch of the agent under the Disk KeyManager configuration.

This mkdir should be recursive (mkdir -p) to avoid loops. Ideally a very popular image should be used (alpine?) and the command "mkdir" should be the visible element on the pod's launching arguments.

We missed an obvious IPv4 address, the alias of 0.0.0.0, currently we only permit "localhost", "127.0.0.1", and "::1"

@kfox1111 Is there a IPv6 equivalent of "0.0.0.0"?

Based on the initial design ideas, we need to add agent image pull policies to the agent-daemonset.

This would add the configuration points:

• image.pullPolicy (default depends on image.tag)
• agent.image.pullPolicy (default depends on agent.image.tag)

The value is constrained to one of "never", "IfNotPresent", and "always"

• If the tag value is "latest", or nil/empty the default is "always"
• If the tag value is not "latest" or nil/empty the default is "IfNotPresent"

The following agent flags all control agent bootstrapping,
the process by which an agent obtains a CA permitting it
to validate and trust the TLS response of the server.

agent {
  insecure_bootstrap = true
  trust_bundle_url = protocol://server/path/
  trust_bundle_path = /path/
}

We need one enumeration type setting to decide which of the
three approaches is used, and for the url and path options,
we need another flag each for specifying the url or path
value.

The agent requires a server address / hostname so it can launch. This name is used to connect to the server.

In our deployments, we have two options:

• Launch a single instance of the server; and, directly bind to that instance
• Launch a k8s service, and indirectly bind to the instances exposed by that service.

The advantages of the latter are many.

• It permits the scaling of server instances without reconfiguration.

• It provides a text DNS name that is automatically managed by the Kubernetes environment.

  This request only covers the support of the latter approach.

Expectations:

• Unit testing that the service name and the agent-config settings refer to the same service
• Different service names for each installation within a namespace
• The service name can be configured to have a specific value, as well as a sensible default value.

Based on the initial design ideas, we need to add the base image to the agent-deployment set.

This would add the configuration points:

• image.registry (defaults to ghcr.io)
• image.registryPort (defaults to nothing)
• image.tag (defaults to .Chart.appVersion)
• agent.image.repository (defaults to .image.repository's value)
• agent.image.repositoryPort (defaults to .image.repositoryPort's value)
• agent.image.name (defaults to "spire/spire-agent")
• agent.image.tag (defaults to .image.tag)

A volume needs to exist to hold the agent config file. This volume should be a config map volume.

The agent should have a volume mount that binds the agent to the volume. The agent command line parameters should reference the agent-configmap's agent configuration as a file at its mounted location.

It is unclear if there is a need to specify the volume mount path, but for biodegradability, the volume name and mount path names should not be configurable.

Its not clear in all cases in the documentation what defaults values have.

An ideal framework should:

• call helm install with configurable command line parameters / values.yaml files
• have the ability to call other helm commands to verify and confirm helm output
• have the ability to call helm upgrade to test updating of installation
• have the ability to call helm rollback to test reversions
• have the ability to call kubectl commands to verify elements outside of helm's output
• have the ability to verify the helm test output
• have the ability to launch pods to perform further testing.

Ideally this would be configurable with YAML files, to reduce developer overhead, depend on tooling outside of the project that can be packaged with docker, and produce a configurable output that supports both command line reporting and junit xml reporting.