spiffe / helm-charts Goto Github PK

Helm charts for SPIRE and other SPIFFE components.

License: Apache License 2.0

Shell 21.15% Smarty 63.01% Makefile 7.16% Go 8.68%

helm-charts's Introduction

The Secure Production Identity Framework For Everyone (SPIFFE) Project defines a framework and set of standards for identifying and securing communications between application services. At its core, SPIFFE is:

A standard defining how services identify themselves to each other. These are called SPIFFE IDs and are implemented as Uniform Resource Identifiers (URIs).
A standard for encoding SPIFFE IDs in a cryptographically-verifiable document called a SPIFFE Verifiable Identity Document or SVIDs.
An API specification for issuing and/or retrieving SVIDs. This is the Workload API.

The SPIFFE Project has a reference implementation, the SPIRE (the SPIFFE Runtime Environment), that in addition to the above, it:

Performs node and workload attestation.
Implements a signing framework for securely issuing and renewing SVIDs.
Provides an API for registering nodes and workloads, along with their designated SPIFFE IDs.
Provides and manages the rotation of keys and certs for mutual authentication and encryption between workloads.
Simplifies access from identified services to secret stores, databases, services meshes and cloud provider services.
Interoperability and federation to SPIFFE compatible systems across heterogeneous environments and administrative trust boundaries.

SPIFFE is a graduated project of the Cloud Native Computing Foundation (CNCF). If you are an organization that wants to help shape the evolution of technologies that are container-packaged, dynamically-scheduled and microservices-oriented, consider joining the CNCF.

SPIFFE Standards

Getting Started

spiffe: This repository includes the SPIFFE ID, SVID and Workload API specifications, example code, and tests, as well as project governance, policies, and processes.
spire: This is a reference implementation of SPIFFE and the SPIFFE Workload API that can be run on and across varying hosting environments.
go-spiffe: Golang client libraries.
java-spiffe: Java client libraries

Communications

Slack (Join here).
[email protected] (View or join here).
[email protected] (View or join here).
[email protected] (View or join here).

Contribute

SIGs & Working Groups

Most community activity is organized into Special Interest Groups (SIGs), time-bounded working groups, and our monthly community-wide meetings. SIGs follow these guidelines, although each may operate differently depending on their needs and workflows. Each group's material can be found in the /community directory of this repository.

Name	Lead	Group	Slack Channel	Meetings
SIG-Community	Umair Khan (HPE)	Here	Here	Notes
SIG-Spec	Evan Gilman (VMware)	Here	Here	Notes
SIG-SPIRE	Daniel Feldman (HPE)	Here	Here	Notes

Follow the SPIFFE Project You can find us on Github and Twitter.

SPIFFE SSC

The SPIFFE Steering Committee meets on a regular cadence to review project progress, address maintainer needs, and provide feedback on strategic direction and industry trends. Community members interested in joining this call can find details below.

Calendar: iCal or Browser-based
Meeting Notes: Google Doc
Call Details: Zoom Link

To contact the SSC privately, please send an email to [email protected].

helm-charts's People

Contributors

Stargazers

Watchers

helm-charts's Issues

cluster.local override

Not all clusters use cluster.local for the root dns for service discovery. It should be made overridable.

Add support for spire-server admin_ids

See https://github.com/spiffe/spire/blob/main/doc/spire_server.md#server-configuration-file

Would be great if we somehow can configure the admin_ids.

E.g. via spire-controller-manager CRDs? Maybe as a separate Helm chart to provision admin_ids CRDs so we can configure the same on spire-server.

Resolve warning in release workflow

Warning: Unexpected input(s) 'version', valid inputs are ['cosign-release', 'install-dir', 'use-sudo']

https://github.com/spiffe/helm-charts/actions/runs/4296328858/jobs/7487905678#step:4:1

default spire-agent.nameOverride=agent

The root of the chart is overriding the name of spire-agent by default:

spire-agent:
  nameOverride: agent

None of the other charts have this done. Is there a reason behind this? Should we remove it so its the default like the other charts?

Production Documentation

There needs to be documentation on how to deploy a production ready system using the chart.

yaml based config

There is the option to switch to using a yaml based config instead of hcl to better integrate with values.

We should gather up the pros and cons in this issue so we can make a decision on which route we may want to go.

Test for bad formatting

We have config to editors to try and ensure formatting issues don't come into the tree. But it seems like it can happen anyway. We need a blocking test to ensure it doesn't merge and the contributor knows to fix it.

Support configurable CA and workload TTLs

Support the following SPIRE Server configurables:

ca_ttl - The default CA/signing key TTL | 24h
default_x509_svid_ttl - The default X509-SVID TTL
default_jwt_svid_ttl -The default JWT-SVID TTL

Reference SPIRE Server configuration

extra init containers and volumes

The agent and server needs the option to add extra mounts and init containers.

Section for raw config for custom plugins

Standard plugins should follow standard helm yaml syntax. To support custom plugins users have created we need a section where they can enter raw config for these plugins.

Can't install sub charts independently

We should be able to install the components individually. When i try i see these errors:

SPIRE Agent:

$ helm template .
Error: template: spire-agent/templates/daemonset.yaml:1:19: executing "spire-agent/templates/daemonset.yaml" at <include (print $.Template.BasePath "/configmap.yaml") .>: error calling include: template: spire-agent/templates/configmap.yaml:55:12: executing "spire-agent/templates/configmap.yaml" at <dig "telemetry" "prometheus" "enabled" .Values.telemetry.prometheus.enabled .Values.global>: error calling dig: interface conversion: interface {} is nil, not map[string]interface {}

Use --debug flag to render out invalid YAML

SPIRE Server:

$ helm template .
Error: template: spire-server/templates/statefulset.yaml:1:19: executing "spire-server/templates/statefulset.yaml" at <include (print $.Template.BasePath "/configmap.yaml") .>: error calling include: template: spire-server/templates/configmap.yaml:85:12: executing "spire-server/templates/configmap.yaml" at <dig "telemetry" "prometheus" "enabled" .Values.telemetry.prometheus.enabled .Values.global>: error calling dig: interface conversion: interface {} is nil, not map[string]interface {}

Use --debug flag to render out invalid YAML

CSI Driver:

$ helm template .
Error: template: spiffe-csi-driver/templates/daemonset.yaml:102:21: executing "spiffe-csi-driver/templates/daemonset.yaml" at <include "spire.agent-socket-path" .>: error calling include: template: no template "spire.agent-socket-path" associated with template "gotpl"

Use --debug flag to render out invalid YAML

OIDC:

$ helm template .
Error: template: spiffe-oidc-discovery-provider/templates/configmap.yaml:33:45: executing "spiffe-oidc-discovery-provider/templates/configmap.yaml" at <include "spire.agent-socket-path" .>: error calling include: template: no template "spire.agent-socket-path" associated with template "gotpl"

Use --debug flag to render out invalid YAML

Kubelet dir configurable

Some distro's put kubelets dir somewhere else. Need to make it configurable. CSI driver in particular.

Fix up maintainers lists in charts

Add support for AWS Secrets Manager as UpstreamAuthority

See following where to add:

Add additional annotations to the charts to add more information on artifacthub.io

https://artifacthub.io/docs/topics/annotations/helm/

Ingress support for oidc-discovery

Need a templateable object for the subchart. It must be possible to expose the service outside the cluster.

Ingress support for spire-server

There should be an optional ingress object for the spire server so it can be exposed outside the cluster.

Values in root chart using yaml variables are not overwritable

Values like clusterName and clusterDomain and trustBundle are not overwriteable.

https://github.com/spiffe/helm-charts/blob/main/charts/spire/values.yaml#L14-L17

When defining different values for these, they are still using the values as defined in the main chart.

e.g.:

spire-server:
  clusterName: my-cluster
  clusterDomain: my-cluster-domain.com
  trust-bundle: my-trust-domain

The solution can probably be found in https://helm.sh/docs/chart_template_guide/subcharts_and_globals/

Add support for cert-manager UpstreamAuthority

The spire-server can use a ca from cert-manager.

See
https://github.com/spiffe/spire/blob/main/doc/plugin_server_upstreamauthority_cert_manager.md

See following where to add:

main/charts/spire/charts/spire-server/values.yaml#L94-L106
main/charts/spire/charts/spire-server/templates/configmap.yaml#L61-L73

Values Profiles

Having a set of prebuilt values files (see examples) for use with various production deployments may prove too burdensome for the end users to be able to juggle.

I'm proposing a possible change. First we come up with an api like:

global:
  spire:
    # - Select a list of predefined sets of values to automatically default to.
    tags:
    - production
    - expose-oidc-ingress-nginx
    - expose-spire-server-ingress-nginx

What settings are for what tags are not really important at the moment.

Each chart would look for a set of tags that it supports and use the merge function to add some extra defaults into values, preferring what the user specified over its own values.

Running with podSecurityContext as shown in production example fails spire-server bootup

Running spire-server with following as shown in production example fails:

spire-server:
  securityContext:
    runAsNonRoot: true
  podSecurityContext:
    runAsUser: 1000
    runAsGroup: 1000

See spire-server log:

time="2023-03-20T12:39:20Z" level=error msg="Fatal run error" error="datastore-sql: unable to open database file: permission denied"
time="2023-03-20T12:39:20Z" level=error msg="Server crashed" error="datastore-sql: unable to open database file: permission denied"

Support HA mode for spire-server using an external database (postgres)

In order to run multiple spire-server replicas we need to add support for a external database (postgres).

To be checked is how this works with the spire-controller-manager, that has to run in the same pod at the moment due to the hard requirement of needing to connect to the spire-server socket.

dataStorage vs persistence value

The very common convention is to have a persistence flag for dealing with volumes. This chart is using dataStorage instead. We should probably consider changing this flag before 1.0.

Check if we need to migrate any APIs for k8s 1.27 release

https://kubernetes.io/blog/2023/03/17/upcoming-changes-in-kubernetes-v1-27/

Revise release strategy

Do we want to put out a new release after each merged PR? Do we want to decide more manually when to release?

Allow to test multiple root level charts from CI

Add charts to the matrix similar like we do the scenarios.

     strategy:
       fail-fast: false
       matrix:
         # Choose tags corresponding to the version of Kind being used.
         # At a minimum, we should test the currently supported versions of
         # Kubernetes, but can go back farther as long as we don't need heroics
         # to pull it off (i.e. kubectl version juggling).
         k8s:
           - v1.26.0
           - v1.25.3
           - v1.24.7
           - v1.23.13
           - v1.22.15
           - v1.21.14
+        charts:
+          - ${{ fromJson(needs.build-matrix.outputs.charts) }}
         values:
           - ${{ fromJson(needs.build-matrix.outputs.tests) }}

This will allow us to test more root level charts later on.

Suggested is to introduce one folder level so we can group the test scenarios per chart.

tree .github/tests      
.github/tests
└── spire
    ├── extras
    │   └── values.yaml
    ├── no-spire-controller-manager
    │   └── values.yaml
    ├── prometheus
    …

Tornjak support

Add support for AWS Private Certificate Authority as UpstreamAuthority

AWS PCA is a widely used for an upstream CA. The official SPIRE helm chart should support the AWS PCA plugin.

https://spiffe.io/docs/latest/deploying/configuring/#configure-aws-certificate-manager

See following where to add:

Test for versions matching

We should have a quick test to ensure the spire versions are all set to the same version.

Add tests to spire-agent/templates/tests

To get more safetynets in place it might make sense to add a couple of tests to:

charts/spire/charts/spire-agent/templates/tests.

What would be a useful testcase here?

Support configurable CA key type

Reference configurable on spire server: https://github.com/spiffe/spire/blob/main/doc/spire_server.md#:~:text=ca_key_type,by%20jwt_key_type)

Hard code agentSocketPath for spiffe csi driver

Other charts we hard code the socket path config. Should we do the same for csi driver?

Workload example to demonstrate functionality of obtaining workload identity

It would be very useful to demonstrate how we can start a workload that can obtain its own identity from SPIRE Agent using CSI driver

Support AWS PCA upstream

AWS PCA is a widely used for an upstream CA. The official SPIRE helm chart should support the AWS PCA plugin.

Add helm-docs documentation comments to values.yaml files

To improve documentation of the values, we should include some comments in the style # -- description of value to document the different values in the charts.

See https://github.com/norwoodj/helm-docs for more details on usage.

Run ./helm-docs.sh to update the README.md with enhanced documentation.

Add option to toggle "skip_kubelet_verification" flag for k8s workload attestor

The Spire-Agent sub-chart currently has the hard-coded line skip_kubelet_verification = true for its k8s workload attestor.

Upgrading an existing installation of spire helm chart fails on spire-controller-manager

This could be an installation order thing where spire-controller-manager is replaced while the CRD is being deployed at the same time. Subsequent run to perform the upgrade makes the install succeed.

$ helm  upgrade -n spire-system --install --values ../../../philips-labs/helm-charts/.local/spire-values.yaml spire ./charts/spire
Error: UPGRADE FAILED: cannot patch "spire-controller-manager-service-account-based" with kind ClusterSPIFFEID: Internal error occurred: failed calling webhook "vclusterspiffeid.kb.io": failed to call webhook: Post "https://spire-controller-manager-webhook.spire-system.svc:443/validate-spire-spiffe-io-v1alpha1-clusterspiffeid?timeout=10s": no endpoints available for service "spire-controller-manager-webhook"
$ helm  upgrade -n spire-system --install --values ../../../philips-labs/helm-charts/.local/spire-values.yaml spire ./charts/spire
Release "spire" has been upgraded. Happy Helming!
NAME: spire
LAST DEPLOYED: Wed Mar  1 11:32:51 2023
NAMESPACE: spire-system
STATUS: deployed
REVISION: 3
NOTES:
Installed spire…

How to reproduce.

$ helm -n spire-system uninstall spire
$ git checkout release
$ helm upgrade -n spire-system --install --values ../../../philips-labs/helm-charts/.local/spire-values.yaml spire ./charts/spire
Release "spire" has been installed. Happy Helming!
NAME: spire
LAST DEPLOYED: Wed Mar  1 11:32:51 2023
NAMESPACE: spire-system
STATUS: deployed
REVISION: 1
NOTES:
Installed spire…
$ git checkout main
$ helm upgrade -n spire-system --install --values ../../../philips-labs/helm-charts/.local/spire-values.yaml spire ./charts/spire
Error: UPGRADE FAILED: cannot patch "spire-controller-manager-service-account-based" with kind ClusterSPIFFEID: Internal error occurred: failed calling webhook "vclusterspiffeid.kb.io": failed to call webhook: Post "https://spire-controller-manager-webhook.spire-system.svc:443/validate-spire-spiffe-io-v1alpha1-clusterspiffeid?timeout=10s": no endpoints available for service "spire-controller-manager-webhook"
$ helm upgrade -n spire-system --install --values ../../../philips-labs/helm-charts/.local/spire-values.yaml spire ./charts/spire
Release "spire" has been upgraded. Happy Helming!
NAME: spire
LAST DEPLOYED: Wed Mar  1 11:35:51 2023
NAMESPACE: spire-system
STATUS: deployed
REVISION: 2
NOTES:
Installed spire…

Maybe we can control some things with the rollout strategy on the spire-server statefulset.

cert-manager support for spire-controller-manager webhooks

cert-manager should be an option to get certificates for the spire-controller-manager webhook so they can be standardized over all the webhooks on the cluster.

spire server entry commands

This doesn't work:

kubectl exec -it spire-server-0 -- spire-server entry show

Currently, you have to do:

kubectl exec -it spire-server-0 -- /opt/spire/bin/spire-server entry show -socketPath /run/spire/server-sockets/spire-server.sock

We should set things up in the pod so that its easier to administrate and the former command works.

Prometheus support

Prometheus is one of the most common monitoring stacks for Kubernetes. The chart should be deployable with support for Prometheus to be able to fetch metrics.

Unable to attach or mount volumes spire-oidc-discovery-provider

In some situations the spire-oidc-discovery-provider fails to boot on a fresh install.

Unable to attach or mount volumes: unmounted volumes=[spiffe-workload-api], unattached volumes=[kube-api-access-xmq62 spiffe-workload-api spire-oidc-sockets spire-oidc-config]: timed out waiting for the condition

Killing the pod does the trick to retry and fix it as a workaround, but would be great if we can fix this in a way it just always succeeds on a fresh install.

Are more people able to reproduce this?

Setup artifacthub-repo.yml

This has to be pushed to both the registry for he oci releases as well to the gh-pages branch.

See https://artifacthub.io/docs/topics/repositories/helm-charts/

Support namespaceOverride configuration

With the HPE helm charts we configured namespace similar to the name: https://github.com/alexandrealvino/spire-helm-charts/blob/main/helm/spire/spire-server/templates/statefulset.yaml#L5

And then had a section in the helpers.tpl to allow release namespace to overridden by a namespaceOverride variable specified in the values.yaml: https://github.com/alexandrealvino/spire-helm-charts/blob/main/helm/spire/spire-server/values.yaml#L8-L9

The helpers.tpl has a small snippet that brings it together: https://github.com/alexandrealvino/spire-helm-charts/blob/main/helm/spire/spire-server/templates/_helpers.tpl#L26-L35

Add a PR template to point to CONTRIBUTING.md

To ensure contributors have read the CONTRIBUTING.md it would be good to have a PR template that adds following at a minimum:

Please describe the changes of your PR here.

- [ ] I have read the [CONTRIBUTING.md](CONTRIBUTING.md) and comply with those guidelines.
- [ ] I have added tests

Any suggestions on making the PR template better are welcome.

Configmap update rollout

Ensure all configmaps have corresponding annotations on the pods to enable automatic rollouts.

Make workload attestors configurable

It may be beneficial to the user to be able to enable what workload attestors they want to use:

  workloadAttesters:
    k8s:
      enabled: false
    unix:
      enabled: true

Suggested by @kfox1111 here: #14 (comment)

Agent Socket Path not correctly rendered when custom values set

As listed above, when setting custom values for spire-agent.socketPath or spiffe-csi-driver.agentSocketPath, the custom values are not properly rendered in the resulting manifest, instead using the default values.

I have also noticed this occur for the health check port option spiffe-csi-driver.healthChecks.port for the SPIFFE-CSI Driver subchart.

I ran the following helm command to recreate this issue:

helm template mychart spiffe/spire --set spire-agent.socketPath="/custom/agent-sockets/spire-agent.sock" \
  --set spiffe-csi-driver.agentSocketPath="/custom/agent-sockets/spire-agent.sock" \
  --set spiffe-csi-driver.healthChecks.port=10000

spiffe / helm-charts Goto Github PK

helm-charts's Introduction

SPIFFE Standards

Getting Started

Communications

Contribute

SIGs & Working Groups

SPIFFE SSC

helm-charts's People

Contributors

Stargazers

Watchers

Forkers

helm-charts's Issues

Recommend Projects

Recommend Topics

Recommend Org