-
Notifications
You must be signed in to change notification settings - Fork 1.6k
SPIRE SDS integration documentation #11057
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
SPIRE SDS integration documentation #11057
Conversation
Co-authored-by: Maximiliano Churichi <mchurichi@gmail.com> Co-authored-by: Max Lambrecht <max.lambrecht@hpe.com> Co-authored-by: Juliano Fantozzi <juliano.fantozzi@gmail.com> Co-authored-by: sanderson042 <steve.anderson@hpe.com> * Apply PR feedbacks * Apply PR feedbacks, adds commands and bash outputs
Co-authored-by: Maximiliano Churichi <mchurichi@gmail.com> Co-authored-by: Max Lambrecht <max.lambrecht@hpe.com> Co-authored-by: Juliano Fantozzi <juliano.fantozzi@gmail.com> Co-authored-by: Steve Anderson <steve.anderson@hpe.com>
Co-authored-by: Maximiliano Churichi <mchurichi@gmail.com>
Adds Spire Integration Documentation
😊 Welcome! This is either your first contribution to the Istio documentation repo, or
Thanks for contributing! Courtesy of your friendly welcome wagon. |
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). For more information, open the CLA check for this pull request. |
Hi @alexandrealvino. Thanks for your PR. I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/ok-to-test Excited to see this integration! Are you working with a maintainer to shepherd it through? |
Yes, @howardjohn @linsun @lei-tang are aware of the integration |
app: sleep | ||
# Injects custom sidecar template | ||
annotations: | ||
inject.istio.io/templates: "sidecar,spire" |
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.
why spire enable or not is aware by every pod/deployment through the annotation? Is there a global flag for it ?
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 annotation applies the custom spire
template created on the configuration of the Install Istio
section:
templates:
spire: |
spec:
containers:
- name: istio-proxy
volumeMounts:
- name: workload-socket
mountPath: /run/secrets/workload-spiffe-uds
readOnly: true
volumes:
- name: workload-socket
csi:
driver: "csi.spiffe.io"
The custom template feature facilitates the injection of the spiffe-csi-driver
volume into workload pods.
But one can always do it manually by adding the volume to the workload spec:
volumes:
- name: tmp
emptyDir: {}
# CSI volume
- name: workload-socket
csi:
driver: "csi.spiffe.io"
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.
#11069 has changes for the two issues here as well as indention within the text blocks.
--- | ||
title: SPIRE | ||
description: Describes how to configure Istio to integrate with SPIRE to get cryptographic identities through Envoy's SDS API. | ||
weight: 40 |
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.
I'm fine leaving this last in the list, but it seems we currently have the weights having the integrations in alphabetical order. Since they are all separated by one, it's hard to add one into the list. We could change them all to be operated by 5 and add this into the mix.
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.
I've added 1 to the zipkin
page and updated SPIRE
page to be 31, is it ok?
/retest |
This integration with SPIRE provides flexible attestation options not available with the default Istio identity management while harnessing Istio's powerful service management. | ||
For example, SPIRE's plugin architecture enables diverse workload attestation options beyond the Kubernetes namespace and service account attestation offered by Istio. | ||
SPIRE's node attestation extends attestation to the physical or virtual hardware on which workloads run. | ||
|
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.
Let us make sure we add a warning that Istio 1.14 is required, assuming this feature lands in 1.14.
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.
I am not sure I agree? This is the docs for Istio 1.14 - it should be assumed everything needs 1.14?
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.
On the Istall Istio section, the doc recommends the latest version of Istio. Should I recommend 1.14+ then?
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.
Thinking more about it, i think it would be useful to note both data plane and control plane are required to be 1.14. (Is this correct?)
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.
Also would be useful to clarify if this only works with NEW istio 1.14 vs upgrading to Istio 1.14 @alexandrealvino
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.
Hi @linsun, only the data plane and istioctl
are required to be 1.14. I will clarify that on the docs.
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.
That sounds great, thanks @alexandrealvino !
Hi @alexandrealvino nice doc! Any plan to cover migration as well? migrating from existing CA (either istiod) or an external CA to SPIRE? Or is this only for new install? |
Hi @linsun, this is only for new installations. The code changes covers only the startup process of |
I wrote this on istio/istio#37948, but it probably should be in this issue instead: "I think this "quickstart" install of the spire server also includes the k8s-workload-registrar for auto-registration... we should add that to the doc somewhere and possibly indicate manual registration wouldn't be necessary here" |
Hi @christian-posta, I've pointed this out on this section from |
Ah, i see it now. I missed it. Can you also add under "Option 1: Automatic registration using the SPIRE workload registrar" that we do indeed set it up in this guide? |
Sorry about the delay @christian-posta, missed the notification. Do you mean add a sentence explaining that it won't be necessary to add registrations manually on the "Option 1: Automatic registration using the SPIRE workload registrar" section? |
Yeah, basically that since it's already being used... that we don't have to follow that Option it's already assumed in the guide... otherwise it seems optional (which it is -- but it actually is done in this doc) and that people should continue on to do it manually... which they don't need to do |
Got it! I will add some comments clarifying that on "Option 2: Manual Registration" and "Option 1: Automatic registration using the SPIRE workload registrar" sections. Now I see the confusion, thanks for your suggestion @christian-posta |
@christian-posta Thoughts on is this is ready to merge? |
yes @ericvn LGTM |
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.
Some possible minor changes.
Just to emphasize that this PR depends on #37948 |
/retest |
LGTM. Once Christian responds in the sample PR, I think they can both merge. |
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.
Samples are now merged.
- name: istio-proxy | ||
volumeMounts: | ||
- name: workload-socket | ||
mountPath: /run/secrets/workload-spiffe-uds |
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.
@alexandrealvino @maxlambrecht Why it is /run/secrets/xxx instead of /var/run/secrets/xxx? Why remove the /var prefix? I know this /run/secrets/xxxx is aligned with spire-agent configmap configuration, but istio-agent only check /var/run/secrets/workload-spiffe-uds/socket as following shows, or I missed anything?
WorkloadIdentitySocketPath = "./var/run/secrets/workload-spiffe-uds/socket"
...
socketExists, err := checkSocket(ctx, security.WorkloadIdentitySocketPath)
if err != nil {
return nil, fmt.Errorf("failed to check SDS socket: %v", err)
}
if socketExists {
log.Info("SDS socket found. Istio SDS Server won't be started")
} else {
log.Info("SDS socket not found. Starting Istio SDS Server")
err = a.initSdsServer()
if err != nil {
return nil, fmt.Errorf("failed to start SDS server: %v", err)
}
}
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.
/var/run
is a symlink to /run
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.
ok, thanks for clarification.
$ kubectl exec -i -t $SPIRE_SERVER_POD -n spire -c spire-server -- /bin/sh -c "bin/spire-server entry show -socketPath /run/spire/sockets/server.sock" | ||
Found 3 entries | ||
Entry ID : c8dfccdc-9762-4762-80d3-5434e5388ae7 | ||
SPIFFE ID : spiffe://example.org/ns/istio-system/sa/istio-ingressgateway-service-account |
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.
@alexandrealvino How about the TLS communication between istiod and istio-proxy? which kind of certification is used here?
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 TLS communication between istiod and istio-agent uses a certificate generated by istiod itself, as per default behavior. That communication wasn't changed at all.
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 TLS communication between istiod and istio-agent uses a certificate generated by istiod itself, as per default behavior. That communication wasn't changed at all.
Thanks, in fact, my question is why not integrate istiod to SPIRE also. It will look more complete. Or will it be the next step or anything block this?
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.
It's the next step.
Please provide a description for what this PR is for.
This PR adds documentation for the SPIRE SDS integration #37947
It depends on #37948