-
Notifications
You must be signed in to change notification settings - Fork 22
Adding quick-start example #476
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: cccsss01 <56396984+cccsss01@users.noreply.github.com>
Signed-off-by: cccsss01 <56396984+cccsss01@users.noreply.github.com>
Signed-off-by: cccsss01 <56396984+cccsss01@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for contributing this. It looks very helpful. :)
Some comments inline
|
||
# Obtain the Required Files | ||
|
||
This guide requires a number of **.yaml** files. To obtain this directory of files clone **https://github.com/spiffe/spire-tutorials** and obtain the **.yaml** files from the **spire-tutorials/k8s/quickstart-helm** subdirectory. Remember to run all kubectl commands in the directory in which those files reside. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This I think isn't true anymore when in the helm-charts repo?
In order to enable SPIRE to perform workload attestation -- which allows the agent to identify the workload to attest to its agent -- you must register the workload in the server. This tells SPIRE how to identify the workload and which SPIFFE ID to give it. | ||
|
||
1. Create a new registration entry for the node, specifying the SPIFFE ID to allocate to the node: | ||
> **Note** change -selector k8s_sat:cluster:demo-cluster to your cluster name | ||
|
||
```shell | ||
$ kubectl exec -n spire spire-server-0 -- \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The controller-manager provided with the chart will automatically do this. Its the recommended way.
In this section, you configure a workload container to access SPIRE. Specifically, you are configuring the workload container to access the Workload API UNIX domain socket. | ||
|
||
The **client-deployment.yaml** file configures a no-op container using the **spire-k8s** docker image used for the server and agent. Examine the `volumeMounts` and `volumes configuration` stanzas to see how the UNIX domain `spire-agent.sock` is bound in. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe some comment about the spire-agent with the parameters "api watch" makes it function as a normal workload and not as the spire-agent itself. Otherwise we might confuse the user into thinking they need their own spire-agent in each workload?
Co-authored-by: kfox1111 <Kevin.Fox@pnnl.gov> Signed-off-by: cccsss01 <56396984+cccsss01@users.noreply.github.com>
Co-authored-by: Faisal Memon <fymemon@yahoo.com> Signed-off-by: cccsss01 <56396984+cccsss01@users.noreply.github.com>
Had issues w/ current readme in spiffe.io, changed the quick-start guide to deploy spiffe/spire.