[VC-35373] Add missing VenafiConnection templates and values to the Helm chart #559
Conversation
wallrj
force-pushed
the
VC-35373-venafi-connection-helm-chart
branch
from
cbb1f54 to
7790b80
Compare
|
I successfully ran It seems like Michael's instructions in https://gitlab.com/venafi/vaas/ua/clouddocs/-/merge_requests/1133 match the Helm values that you propose in your PR. I am happy with your proposed changes. Thank you a lot for helping with this! 🙏🙏 |
wallrj
force-pushed
the
VC-35373-venafi-connection-helm-chart
branch
from
7790b80 to
e35591d
Compare
|
I was wrong about the "crd_bases":
The CRDs under templates/ are full of Helm markup, so we need the "crd_bases" so that integration tests work. Could you add the file that was under crd_bases? You can do that with the following commands: gh pr checkout 556
git checkout -
git checkout step1-makefile-modules -- deploy/charts/venafi-kubernetes-agent/crd_bases/jetstack.io_venaficonnections.yaml |
| # -- When set to false, the rendered output does not contain the | ||
| # VenafiConnection CRDs and RBAC. This is useful for when the | ||
| # Venafi Connection resources are already installed separately. | ||
| enabled: false |
There was a problem hiding this comment.
People will probably want to install the CRDs separately but still use the venafi connection auth method. It looks like the helm chart doesn't allow you to do that at the moment, WDYT? I confused crds.enabled with venafiConnection.enabled. Never mind.
There was a problem hiding this comment.
Atanas also asked whether we could enable the venafi connection auth by default (i.e., --venafi-connection is used by default, but maybe not the CRDs).
For example, imagine that a customer install Venafi Kubernetes Agent through the VMG/operator, the Helm installation should work regardless of whether they forgot to configure Venafi Kubernetes Agent. They will see in the logs that the last step is to create a venafi connection object.
Would that work?
There was a problem hiding this comment.
Partly done. I rearranged the Helm values.
There are now
venafiConnection.include: Like VEI this controls whether the VenafiConnection CRD and related service account and RBAC get installed. (defaultfalse).config.venafiConnection.enabled: This controls whether--venafi-connection=venafi-componentsis added to the command line and if true disables the old mounted Service account mechanism. (defaultfalse).
wallrj
force-pushed
the
VC-35373-venafi-connection-helm-chart
branch
from
e35591d to
dd4ab58
Compare
deploy/charts/venafi-kubernetes-agent/templates/venafi-connection-crd.without-validations.yaml
Outdated
Show resolved
Hide resolved
wallrj
force-pushed
the
VC-35373-venafi-connection-helm-chart
branch
4 times, most recently
from
0dd0cc3 to
7d24222
Compare
wallrj
dismissed
maelvls’s stale review
I updated the Helm values to make the options for installing VenafiConnection and using VenafiConnection more intuitive and consistent with other TLSPK tools (like venafi-enhanced-issuer). I also updated the test script to use the new bare minium Helm values and applied your suggested MacOS compatible date command.
|
|
||
| # -- Configure the Venafi Kubernetes Agent to load credentials using a | ||
| # VenafiConnection resource. | ||
| venafiConnection: |
There was a problem hiding this comment.
Why is this under config? As far as I understand, the config value is passed as a YAML file using the flag --agent-config-file or -c for short:
$ go run . agent --help
The agent will periodically gather data for the configured data
gatherers and send it to a remote backend for evaluation
Usage:
preflight agent [flags]
preflight agent [command]
Available Commands:
info print several internal parameters of the agent
rbac print the agent's minimal RBAC manifest
Flags:
-c, --agent-config-file agent.yaml Config file location, default is agent.yaml in the current working directory. (default "./agent.yaml")This means that the configuration file that gets stored in the configmap agent-config will now contain the field venafiConnection. It doesn't have any impact because this field is skipped when the YAML file is parsed. But it looks a little weird since this bit of configuration doesn't configure anything in the agent.
Would it not make more sense to move this to outside of the config block in that case?
Another solution would be for me to implement the venafiConnection field in the config file so that the user can either use the flag --venafi-connection=name, or use the config file field venafiConnection.name. I could even drop the command line flag in that case.
WDYT?
There was a problem hiding this comment.
Why is this under config?
Because that's how it's currently documented:
There was a problem hiding this comment.
Ah, yes.
I'll add this to the configuration API then, which means you will no longer have to pass --venafi-connnection and --venafi-connnection-namespace in the deployment. This should make much more sense this way.
There was a problem hiding this comment.
This means that the configuration file that gets stored in the configmap agent-config will now contain the field venafiConnection
No. That's not how the config template works in this project. You're thinking of cert-manager I think:
There was a problem hiding this comment.
@maelvls I've moved the values around to hopefully make them more intuitive.
The venafiConnection.enabled value is now in the authentication section.
And the venafiConnection.include value is now in the crds section.
So the documentation would look like:
Use the following Helm chart values to install the VenafiConnection CRDs and to enable VenafiConnection based authentication:
config:
clusterName: venafi-kubernetes-agent-e2e
clusterDescription: |
A kind cluster used for testing the venafi-kubernetes-agent.
authentication:
venafiConnection:
enabled: true
crds:
venafiConnection:
include: trueOr use the following Helm install command:
helm install venafi-kubernetes-agent oci://registry.venafi.cloud/charts/venafi-kubernetes-agent \
--create-namespace \
--namespace "venafi" \
--set config.clusterName="replace-with-your-cluster-name" \
--set config.clusterDescription="replace-with-your-cluster-description" \
--set authentication.venafiConnection.enabled=true \
--set crds.venafiConnection.include=trueThere was a problem hiding this comment.
My bad, I didn't realize that config wasn't directly translated into a file, and that it is used to template the agent-config configmap. Thanks for pointing that out.
The new structure you propose is simple and clear, I like it.
I'm OK with the fact that --set crds.venafiConnection.include=true is a bit different in venafi-enhanced-issuer and approver-policy-enterprise (it would be --set venafiConnection.include=true on these two projects).
Signed-off-by: Richard Wall <richard.wall@venafi.com>
wallrj
force-pushed
the
VC-35373-venafi-connection-helm-chart
branch
from
7d24222 to
11621c5
Compare
There was a problem hiding this comment.
I removed all the installation documentation from the Helm chart README and instead defer to the website documentation.
Saves having to document the secretless auth here too.
|
I've re-run the script and it still works with the new structure in $ export VEN_API_KEY=$APIKEY VEN_OWNING_TEAM=$(curl --fail-with-body -sS https://api.venafi.cloud/v1/teams -H "tppl-api-key: $APIKEY" | jq '.teams[0].id' -r) OCI_BASE=ttl.sh/maelvls
$ ./hack/e2e/test.sh
~/code/jetstack/jetstack-secure ~/code/jetstack/jetstack-secure/hack/e2e
2024/08/22 13:58:14 Using base cgr.dev/chainguard/static:latest@sha256:791657dd88dea8c1f9d3779815429f9c681a9a2778fc66dac3fbf550e1f1d9c8 for github.com/jetstack/preflight
2024/08/22 13:58:14 Building github.com/jetstack/preflight for linux/amd64
2024/08/22 13:58:20 Publishing ttl.sh/maelvls/images/venafi-agent:v0.1.49-19-g11621c54d0b619
2024/08/22 13:58:22 mounted blob: sha256:50c2c4796b3d6fd72518badc070d1271a375c94857c5469b1b9380e43d2bc180
2024/08/22 13:58:25 pushed blob: sha256:d400f7676c038abdd3c93b890d8f53ce11e9ad6425056849b93ee196e8c3e7bb
2024/08/22 13:58:25 pushed blob: sha256:b9b678d5804b31f4c3c8d7b4fc83733c7d5026fa8bb0eacaad9dc8230ea49cec
2024/08/22 13:58:25 pushed blob: sha256:250c06f7c38e52dc77e5c7586c3e40280dc7ff9bb9007c396e06d96736cf8542
2024/08/22 13:58:26 pushed blob: sha256:07a8590cc2a36109717682aeac93e7d071dfa6cdc4c50ad370f8ada08778687b
2024/08/22 13:58:27 ttl.sh/maelvls/images/venafi-agent:sha256-e02cb526fc054f0a046f536c7de7aa867dd43a7fad2e18c5a5daf2e137d5ce9b.sbom: digest: sha256:2cdf8a95a902a0e05cdfb579d23472817e431d07e58e4739fe7e8bc68b1c7c96 size: 374
2024/08/22 13:58:27 Published SBOM ttl.sh/maelvls/images/venafi-agent:sha256-e02cb526fc054f0a046f536c7de7aa867dd43a7fad2e18c5a5daf2e137d5ce9b.sbom
2024/08/22 13:59:55 pushed blob: sha256:9aff5900a9448f4b820cc11839f014b1b038c3f7ac34bb441cb75a98a60b5393
2024/08/22 13:59:56 ttl.sh/maelvls/images/venafi-agent:v0.1.49-19-g11621c54d0b619: digest: sha256:e02cb526fc054f0a046f536c7de7aa867dd43a7fad2e18c5a5daf2e137d5ce9b size: 1246
2024/08/22 13:59:56 Published ttl.sh/maelvls/images/venafi-agent:v0.1.49-19-g11621c54d0b619@sha256:e02cb526fc054f0a046f536c7de7aa867dd43a7fad2e18c5a5daf2e137d5ce9b
ttl.sh/maelvls/images/venafi-agent:v0.1.49-19-g11621c54d0b619@sha256:e02cb526fc054f0a046f536c7de7aa867dd43a7fad2e18c5a5daf2e137d5ce9b
Successfully packaged chart and saved it to: /Users/mvalais/code/jetstack/jetstack-secure/venafi-kubernetes-agent-v0.1.49-19-g11621c54d0b619.tgz
Pushed: ttl.sh/maelvls/charts/venafi-kubernetes-agent:v0.1.49-19-g11621c54d0b619
Digest: sha256:98ae8aaccb3a662db3b39ed2c7bde100a7a8c3cd0546b44a8642bfef39f1c476
~/code/jetstack/jetstack-secure/hack/e2e
2024/08/22 14:00:01 docker -v
2024/08/22 14:00:02 docker info --format '{{json .}}'
2024/08/22 14:00:02 docker ps -a --filter label=io.x-k8s.kind.cluster=kind --format '{{.Names}}'
ERROR: failed to create cluster: node(s) already exist for a cluster with the name "kind"
Error from server (AlreadyExists): namespaces "venafi" already exists
NAME TYPE DATA AGE
venafi-image-pull-secret kubernetes.io/dockerconfigjson 1 42h
Error from server (AlreadyExists): namespaces "venafi-kubernetes-agent-e2e" already exists
NAME TYPE DATA AGE
cached-venafi-agent-service-account Opaque 2 42h
Applying releases count=1
No orphan releases to uninstall
{
"header": {
"alg": "ES256",
"kid": "Cy0co04hD3VHr1ZpT-ZHSCMMIxcRuunHbtrci5D1SIM",
"typ": "JWT"
},
"payload": {
"aud": "api.venafi.cloud/v1/oauth/token/serviceaccount",
"exp": 1724329824,
"iat": 1724328025,
"iss": "13427e8e-5f16-11ef-bff6-3e2631dd4b3e",
"jti": "95d5ff89eff4f2c80949b0f872e1f63344466769abe7c1fc925591ab66b28156",
"nbf": 1724328025,
"sub": "13427e8e-5f16-11ef-bff6-3e2631dd4b3e"
},
"signature": "XXX"
}
{"access_token":"XXX","expires_in":900,"token_type":"bearer"}
venaficonnection.jetstack.io/venafi-components unchanged
role.rbac.authorization.k8s.io/get-venafi-credentials unchanged
rolebinding.rbac.authorization.k8s.io/application-team-1-secret-rolebinding unchanged
secret/venafi-credentials configured
2024/08/22 12:00:23 Preflight agent version: development ()
2024/08/22 12:00:23 Loaded config:
schedule: ""
period: 0s
endpoint:
protocol: ""
host: ""
path: ""
server: https://api.venafi.cloud/
organization_id: ""
cluster_id: venafi-kubernetes-agent-e2e
cluster_description: |
A kind cluster used for testing the venafi-kubernetes-agent.
data-gatherers:
- kind: k8s-dynamic
name: k8s/fireflyissuers
data_path: ""
config:
kubeconfig: ""
groupversionresource:
group: firefly.venafi.com
version: v1
resource: issuers
exclude-namespaces: []
include-namespaces: []
input-path: ""
output-path: ""
venafi-cloud:
uploader_id: "no"
upload_path: /v1/tlspk/upload/clusterdata
vCert: 2024/08/22 12:00:23 Venafi Connection mode was specified, using Venafi Connection authentication.
vCert: 2024/08/22 12:00:23 ignoring venafi-cloud.upload_path. In Venafi Connection mode, this field is not needed.
vCert: 2024/08/22 12:00:23 ignoring venafi-cloud.uploader_id. In Venafi Connection mode, this field is not needed.
2024/08/22 12:00:23 Prometheus was enabled.
Running prometheus server on port :8081
2024/08/22 12:01:16 Posting data to: https://api.venafi.cloud/
2024/08/22 12:01:17 Data sent successfully.
2024/08/22 12:02:17 Posting data to: https://api.venafi.cloud/
2024/08/22 12:02:18 Data sent successfully. |
2 participants
Stacked on #552
Ref: VC-35373, VC-35374
Testing
hack/e2e/test.shI ran the
hack/e2e/test.shscript on my laptop and it successfully posted to venafi.cloud.helm templatediffThe default Helm chart output has not changed, which hopefully indicates that existing users should be able to upgrade without problems.
Here's how the rendered manifests differ with
authentication.venafiConnection.enabled: