Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Fix broken links #240

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Fix broken links #240

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
d3d6a2b
Fix broken links
georgevanburgh Apr 15, 2022
2e8d203
Fix a link to use-cases
georgevanburgh Apr 15, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions content/docs/latest/deploying/registering.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -21,7 +21,7 @@ The server will send to the agent a list of all registration entries for workloa

During workload attestation, the agent discovers selectors and compares them to those in the cached registration entries to determine which SVIDs they should assign to the workload.

You register a workload either by issuing the `spire-server entry create` command at the command line or calling directly into the Registration API, as described in the [Registration API documentation](https://github.com/spiffe/spire/blob/{{< spire-latest "tag" >}}/proto/spire/api/registration/registration.proto). Existing entries can be modified using the `spire-server entry update` command.
You register a workload either by issuing the `spire-server entry create` command at the command line or calling directly into the Entry API, as described in the [Entry API documentation](https://github.com/spiffe/spire/blob/{{< spire-latest "tag" >}}/proto/spire/api/server/entry/v1/entry.proto). Existing entries can be modified using the `spire-server entry update` command.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that the "registration api" was removed in spiffe/spire#2487, and replaced by the entry api? (@azdagron)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems like the protos have been moved to their own repo now, the Entry API is here. Would you mind confirming this @azdagron?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that is correct, @mchurichi.


{{< info >}}
When running on Kubernetes, a common way to invoke commands on the SPIRE Server is through the `kubectl exec` command on a pod running the SPIRE Server. For example:
Expand Down Expand Up @@ -63,7 +63,7 @@ Different selectors are available depending on the platform or architecture on w
| For a list of supported selectors for this platform | Go here |
| ---------------- | ----------- |
| **Kubernetes** | The [configuration reference page for the Kubernetes Node Attestor](https://github.com/spiffe/spire/blob/{{< spire-latest "tag" >}}/doc/plugin_server_nodeattestor_k8s_sat.md)
| **AWS** | The [configuration reference page for the AWS Node Resolver](https://github.com/spiffe/spire/blob/{{< spire-latest "tag" >}}/doc/plugin_server_noderesolver_aws_iid.md)
| **AWS** | The [configuration reference page for the AWS Node Attestor](https://github.com/spiffe/spire/blob/{{< spire-latest "tag" >}}/doc/plugin_server_nodeattestor_aws_iid.md)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the node resolver was retired in spiffe/spire#2191, and functionality moved into the node attestor plugin

| **Azure** | The [configuration reference page for the Azure Managed Service Identity Node Resolver](https://github.com/spiffe/spire/blob/{{< spire-latest "tag" >}}/doc/plugin_server_noderesolver_azure_msi.md)

## 2. Defining the SPIFFE ID of the Workload
Expand Down
4 changes: 2 additions & 2 deletions content/docs/latest/spiffe-about/get-involved.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -36,5 +36,5 @@ Day to day contributions are vetted by the project's maintainers. Overall projec

Find SPIFFE and SPIRE logos here:

* [SPIFFE](https://branding.cncf.io/projects/spiffe)
* [SPIRE](https://branding.cncf.io/projects/spire)
* [SPIFFE](https://branding.cncf.io/tree/master/projects/spiffe)
* [SPIRE](https://branding.cncf.io/tree/master/projects/spire)
Comment on lines +39 to +40
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per the README in cncf/cncf-branding this site has been retired, and now blindly redirects to cncf/artwork. As a result, the paths to the artwork folders need to be "github paths". We could go directly to the github links and cut out the redirect if we wanted? Happy to change this if that is preferred.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd rather go with the github links directly, not that I'm concerned about an extra redirect, but would be better in case that the cncf removes the redirects in the future

2 changes: 1 addition & 1 deletion content/docs/latest/spire-about/comparisons.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@ Secrets managers typically control, audit and securely store sensitive informati

A common architectural challenge in deploying secrets managers is how to securely store the credential that is used by the workload to access the secret store itself. This is sometimes called "credential zero", the "bootstrap credential", or more broadly, the process of "secure introduction".

By contrast, while SPIRE does _generate_ SPIFFE identities that can be used to [authenticate to other systems](/docs/latest/spire-integrations/use-cases/), SPIRE does not aim to store existing keys (such as a database password) on behalf of a workload.
By contrast, while SPIRE does _generate_ SPIFFE identities that can be used to [authenticate to other systems](/docs/latest/spire-about/use-cases/), SPIRE does not aim to store existing keys (such as a database password) on behalf of a workload.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this page was just moved in #194, and the alias went one level too deep for this link to work (/docs/latest/spire-integrations/use-cases/use-cases instead of /docs/latest/spire-integrations/use-cases.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice catch!


SPIRE's attestation policies provide a flexible and powerful solution for secure introduction to secrets managers. A common use of SPIRE-issued [SVIDs](/docs/latest/spiffe/concepts/#spiffe-verifiable-identity-document-svid) is to authenticate to secret stores to allow an application to retrieve secrets.

Expand Down