Changes to pull docs from latest spire release

Signed-off-by: Maximiliano Churichi <maximiliano.churichi@hpe.com>

.editorconfig

@@ -0,0 +1,7 @@
+root = true
+
+[*.{yaml,yml}]
+indent_size = 4
+
+[*.py]
+indent_size = 4

Pipfile

@@ -12,6 +12,7 @@ argh = "*"
 [packages]
 pyyaml = "~=5.3"
 toml = "~=0.10.1"
+requests = "~=2.25.1"
 
 [requires]
 python_version = "3.7"

assets/sass/custom.sass

@@ -107,4 +107,7 @@
 
 a
   code
-    color: $link
+    color: $link
+
+.non-actionable
+  cursor: default

config.toml

@@ -7,6 +7,7 @@ canonifyurls = true
 googleAnalytics = "UA-99605331-1"
 enableGitInfo = true
 publicUrl = "https://spiffe.io"
+spireGitHubUrl = "http://github.com/spiffe/spire"
 
 [markup]
   [markup.tableOfContents]

content/docs/latest/deploying/install-agents.md

@@ -13,7 +13,7 @@ aliases:
 
 Pre-built SPIRE releases can be found on the [SPIRE downloads page](/downloads/#spire-releases). The tarballs contain both server and agent binaries.
 
-If you wish, you may also [build SPIRE from source](https://github.com/spiffe/spire/blob/master/CONTRIBUTING.md).
+If you wish, you may also [build SPIRE from source](https://github.com/spiffe/spire/blob/{{< spire-latest "tag" >}}/CONTRIBUTING.md).
 
 ## Step 2: Install the Server and Agent {#step-2}
 

content/docs/latest/deploying/registering.md

@@ -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/master/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 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.
 
 {{< 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:
@@ -34,7 +34,7 @@ kubectl exec -n spire spire-server-0 -- \
 ```
 {{< /info >}}
 
-To learn more about the `spire-server entry create` and `spire-server entry update` commands and options, consult the [SPIRE Server reference guide](https://github.com/spiffe/spire/blob/master/doc/spire_server.md).
+To learn more about the `spire-server entry create` and `spire-server entry update` commands and options, consult the [SPIRE Server reference guide](/docs/latest/deploying/spire_server/).
 
 # How to register a workload
 
@@ -62,9 +62,9 @@ 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/main/doc/plugin_server_nodeattestor_k8s_sat.md)
-| **AWS**       | The [configuration reference page for the AWS Node Attestor](https://github.com/spiffe/spire/blob/main/doc/plugin_server_nodeattestor_aws_iid.md)
-| **Azure**       | The [configuration reference page for the Azure Managed Service Identity Node Resolver](https://github.com/spiffe/spire/blob/main/doc/plugin_server_noderesolver_azure_msi.md)
+| **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)
+| **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
 
@@ -81,9 +81,9 @@ spire-server entry create \
 
 | For a list of supported selectors for this platform | Go here |
 | ---------------- | ----------- |
-| **Unix**       | The [configuration reference page for the Unix Workload Attestor](https://github.com/spiffe/spire/blob/master/doc/plugin_agent_workloadattestor_unix.md)
-| **Kubernetes** | The [configuration reference page for the Kubernetes Workload Attestor](https://github.com/spiffe/spire/blob/master/doc/plugin_agent_workloadattestor_k8s.md)
-| **Docker** | The [configuration reference page for the Docker Workload Attestor](https://github.com/spiffe/spire/blob/master/doc/plugin_agent_workloadattestor_docker.md)
+| **Unix**       | The [configuration reference page for the Unix Workload Attestor](https://github.com/spiffe/spire/blob/{{< spire-latest "tag" >}}/doc/plugin_agent_workloadattestor_unix.md)
+| **Kubernetes** | The [configuration reference page for the Kubernetes Workload Attestor](https://github.com/spiffe/spire/blob/{{< spire-latest "tag" >}}/doc/plugin_agent_workloadattestor_k8s.md)
+| **Docker** | The [configuration reference page for the Docker Workload Attestor](https://github.com/spiffe/spire/blob/{{< spire-latest "tag" >}}/doc/plugin_agent_workloadattestor_docker.md)
 
 # How to list registration entries
 
@@ -101,7 +101,7 @@ For example, to list all registration entries that match a set of EC2 instances
 spire-server entry show -selector tag:app:webserver
 ```
 
-To learn more about the `spire-server entry show` command and options, consult the [SPIRE Server reference guide](https://github.com/spiffe/spire/blob/master/doc/spire_server.md).
+To learn more about the `spire-server entry show` command and options, consult the [SPIRE Server reference guide](/docs/latest/deploying/spire_server/).
 
 # How to remove registration entries
 
@@ -113,7 +113,7 @@ For example:
 spire-server entry delete -entryID 92f4518e-61c9-420d-b984-074afa7c7002
 ```
 
-To learn more about the `spire-server entry delete` command and options, consult the [SPIRE Server reference guide](https://github.com/spiffe/spire/blob/master/doc/spire_server.md).
+To learn more about the `spire-server entry delete` command and options, consult the [SPIRE Server reference guide](/docs/latest/deploying/spire_server/).
 
 # Mapping Workloads to Multiple Nodes
 

content/docs/latest/deploying/svids.md

@@ -62,4 +62,4 @@ will:
 3.   Write the X.509-SVID, private key associated with each of those identities to `/tmp/`
 4.   Write the trust bundle (certificate chain) needed to validate X.509-SVIDs issued under that trust domain to `/tmp/` as well
 
-A complete list of relevant commands can be found in the [SPIRE Agent Documentation](https://github.com/spiffe/spire/blob/master/doc/spire_agent.md#command-line-options).
+A complete list of relevant commands can be found in the [SPIRE Agent Documentation](/docs/latest/deploying/spire_agent/#command-line-options).

content/docs/latest/planning/extending.md

@@ -15,7 +15,7 @@ SPIRE is highly extensible via a plugin framework that allows many core operatio
 
 A Node Attestor implements validation logic for nodes (physical or virtual machines) that are attempting to establish their identity. Typically a Node Attestor is implemented as a plugin on the Server and with a corresponding plugin on the Agent. A Node Attestor plugin will often expose selectors that can be used when creating the registration entries that define a workload.
 
-SPIRE comes with a set of built-in Node Attestor plugins for the [Server](https://github.com/spiffe/spire/blob/master/doc/spire_server.md) and [Agent](https://github.com/spiffe/spire/blob/master/doc/spire_agent.md) that support various cloud platforms, schedulers and other machine identity sources. Servers can have multiple Node Attestor plugins enabled simultaneously, however a given Agent may only have one Node Attestor plugin enabled at a time.
+SPIRE comes with a set of built-in Node Attestor plugins for the [Server](/docs/latest/deploying/spire_server/) and [Agent](/docs/latest/deploying/spire_agent/) that support various cloud platforms, schedulers and other machine identity sources. Servers can have multiple Node Attestor plugins enabled simultaneously, however a given Agent may only have one Node Attestor plugin enabled at a time.
 
 In addition, known third-party Node Attestor plugins include:
 
@@ -29,39 +29,39 @@ Once the identity of an individual node has been determined, in some cases it is
 
 Node Resolver plugins are typically coupled to a specific Node Attestor plugin (such as the AWS EC2 IID Node Attestor), since they will rely on that plugin to verify the initial identity of the node.
 
-SPIRE comes with a set of built-in Node Resolver plugins for the [Server](https://github.com/spiffe/spire/blob/master/doc/spire_server.md).
+SPIRE comes with a set of built-in Node Resolver plugins for the [Server](/docs/latest/deploying/spire_server/).
 
 # Workload Attestor plugins
 
 While Node Attestors help SPIRE verify the identity of a node running a workload, Workload Attestors identify a specific workload running on that node. Workload attestors run on the Agent. A workload attestor may leverage kernel metadata retrieved during a call to the Workload API to determine the identity of a workload, but it may also choose to interrogate other local sources (such as the calling binary, the Docker daemon or the Kubernetes kubelet) to verify the identity of a workload. As with Node Attestor plugins, Workload Attestor plugins expose selectors that allow registration entries to be created for workloads based on the properties of the workload that the attestor verified.
 
-SPIRE comes with a set of built-in Workload Attestor plugins for the [Agent](https://github.com/spiffe/spire/blob/master/doc/spire_agent.md).
+SPIRE comes with a set of built-in Workload Attestor plugins for the [Agent](/docs/latest/deploying/spire_agent/).
 
 # Upstream Authority plugins
 
 UpstreamAuthority plugins allow the SPIRE Server to integrate with existing public key infrastructure, such that the certificates it generates derive from specific intermediate or root certificates supplied to SPIRE. By choosing or developing different UpstreamAuthority plugins it is possible to customize how SPIRE retrieves these certificates (for example from a file, or a particular secrets manager or certificate vault).
 
-SPIRE comes with a set of built-in UpstreamAuthority plugins for the [Server](https://github.com/spiffe/spire/blob/master/doc/spire_server.md).
+SPIRE comes with a set of built-in UpstreamAuthority plugins for the [Server](/docs/latest/deploying/spire_server/).
 
 # KeyManager plugins
 
 In some cases it might be desirable for SPIRE to avoid being exposed to a signing key at all - for example if the signing key is held in a secure hardware enclave. In such a case, the SPIRE Server and Agent can leverage KeyManager plugins to delegate the actual signing operation to another system (such as a TPM).
 
-SPIRE comes with a set of built-in KeyManager plugins for the [Server](https://github.com/spiffe/spire/blob/master/doc/spire_server.md) and [Agent](https://github.com/spiffe/spire/blob/master/doc/spire_agent.md).
+SPIRE comes with a set of built-in KeyManager plugins for the [Server](/docs/latest/deploying/spire_server/) and [Agent](/docs/latest/deploying/spire_agent/).
 
 # Notifier plugins
 
 Notifier plugins allow actions to be triggered in other systems when certain events occur on the SPIRE Server, and in some cases interrupt the event itself. Notifier plugins can support a number of different use cases, such as when certificate rotation events occur.
 
-SPIRE comes with a set of built-in Notifier plugins for the [Server](https://github.com/spiffe/spire/blob/master/doc/spire_server.md).
+SPIRE comes with a set of built-in Notifier plugins for the [Server](/docs/latest/deploying/spire_server/).
 
 # Working with first-party plugins
 
 First party plugins can be enabled by including the appropriate configuration stanza in the `plugins` section of the Server or Agent configuration file. 
 
 *   For instructions on modifying the Server and Agent configuration files, please follow [Configuring the SPIRE Server](/docs/latest/spire/using/configuring/).
-*   For more information on enabling the plugins in the Server, read the [Server configuration guide](https://github.com/spiffe/spire/blob/master/doc/spire_server.md).
-*   For more information on enabling the plugins in the Agent, read the [Agent configuration guide](https://github.com/spiffe/spire/blob/master/doc/spire_agent.md).
+*   For more information on enabling the plugins in the Server, read the [Server configuration guide](/docs/latest/deploying/spire_server/).
+*   For more information on enabling the plugins in the Agent, read the [Agent configuration guide](/docs/latest/deploying/spire_agent/).
 
 # Working with third party plugins
 

content/docs/latest/spiffe-about/get-involved.md

@@ -26,7 +26,7 @@ SPIFFE is guided by a small but very active community of passionate software eng
 You can contribute to SPIFFE and SPIRE by filing issues and submitting pull requests on GitHub. See these contribution guidelines for details such as GitHub etiquette and coding conventions:
 
 * [SPIFFE contribution guidelines](https://github.com/spiffe/spiffe/blob/master/CONTRIBUTING.md)
-* [SPIRE contribution guidelines](https://github.com/spiffe/spire/blob/master/CONTRIBUTING.md)
+* [SPIRE contribution guidelines](https://github.com/spiffe/spire/blob/{{< spire-latest "tag" >}}/CONTRIBUTING.md)
 
 While anyone is welcome to propose contributions via pull requests, we strongly encourage significant contributions - particularly those that might require a significant change to core components - to be first discussed and a high level design agreed upon with the appropriate SIGs or WGs (see above).
 

content/docs/latest/spire-about/spire-concepts.md

@@ -41,7 +41,7 @@ The behavior of the server is determined through a series of plugins. SPIRE come
 
 **Upstream authority plugins**. By default the SPIRE Server acts as its own certificate authority. However, you can use an upstream authority plugin to use a different CA from a different PKI system.
 
-You customize the server’s behavior by configuring plugins and various other configuration variables. See the [SPIRE Server Configuration Reference](https://github.com/spiffe/spire/blob/master/doc/spire_server.md) for details. 
+You customize the server’s behavior by configuring plugins and various other configuration variables. See the [SPIRE Server Configuration Reference](/docs/latest/deploying/spire_server/) for details. 
 
 ## All About the Agent
 
@@ -61,7 +61,7 @@ The agent’s main components include:
 
 * Key manager plugins, which the agent uses to generate and use private keys for X.509-SVIDs issued to workloads.
 
-You customize the agent’s behavior by configuring plugins and other configuration variables. See the [SPIRE Agent Configuration Reference](https://github.com/spiffe/spire/blob/master/doc/spire_agent.md) for details.
+You customize the agent’s behavior by configuring plugins and other configuration variables. See the [SPIRE Agent Configuration Reference](/docs/latest/deploying/spire_agent/) for details.
 
 ## Custom Server and Agent Plugins
 
@@ -74,7 +74,7 @@ This section walks through a “day in the life” of how SPIRE issues an identi
 1. The SPIRE Server starts up.  
 2. Unless the user has configured an UpstreamAuthority plugin, the server generates a self-signed certificate (a certificate signed with its own private key); the server will use this certificate to sign SVIDs for all the workloads in this server’s trust domain.
 3. If it’s the first time starting up, the server automatically generates a trust bundle, whose contents it stores in a sql datastore you specify in the datastore configuration -- described in the section "Built-in plugins" in the
-[Server plugin: DataStore sql](https://github.com/spiffe/spire/blob/master/doc/plugin_server_datastore_sql.md).
+[Server plugin: DataStore sql](https://github.com/spiffe/spire/blob/{{< spire-latest "tag" >}}/doc/plugin_server_datastore_sql.md).
 4. The server turns on its registration API, to allow you to register workloads.  
 5. The SPIRE Agent starts up on the node that the workload is running on.  
 6. The agent performs node attestation, to prove to the server the identity of the node it is running on. For example, when running on an AWS EC2 Instance it would typically perform node attestation by supplying an [AWS Instance Identity Document](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-identity-documents.html) to the server.  
@@ -177,7 +177,7 @@ For cases where there is no platform that can directly identify a node, SPIRE in
 
 **with server-generated join tokens** -- A join token is a pre-shared key between a SPIRE Server and Agent. The server can generate join tokens once installed that can be used to verify an agent when it starts. To help protect against misuse, join tokens expire immediately after use.
 
-**using an existing X.509 certificate** -- For information on configuring node attestors, see the [SPIRE Server Configuration Reference](https://github.com/spiffe/spire/blob/master/doc/spire_server.md) and [SPIRE Agent Configuration Reference](https://github.com/spiffe/spire/blob/master/doc/spire_agent.md).
+**using an existing X.509 certificate** -- For information on configuring node attestors, see the [SPIRE Server Configuration Reference](/docs/latest/deploying/spire_server/) and [SPIRE Agent Configuration Reference](/docs/latest/deploying/spire_agent/).
 
 #### Node Resolution
 

content/docs/latest/try/getting-started-k8s.md

@@ -251,9 +251,9 @@ When deploying SPIRE in a production environment the following considerations sh
 In the [Create Server Configmap](#create-server-configmap) step: set the the cluster name in the `k8s_sat NodeAttestor` entry to the name you provide in the **agent-configmap.yaml** configuration file.
 
 If your Kubernetes cluster supports projected service account tokens, consider using the built-in 
-[Projected Service Account Token k8s Node Attestor](https://github.com/spiffe/spire/blob/master/doc/plugin_server_nodeattestor_k8s_psat.md) for authenticating the SPIRE agent to the server. Projected Service Account Tokens are more tightly scoped than regular service account tokens, and thus more secure.
+[Projected Service Account Token k8s Node Attestor](https://github.com/spiffe/spire/blob/{{< spire-latest "tag" >}}/doc/plugin_server_nodeattestor_k8s_psat.md) for authenticating the SPIRE agent to the server. Projected Service Account Tokens are more tightly scoped than regular service account tokens, and thus more secure.
 
-As configured, the SPIRE agent does not verify the identity of the Kubernetes kubelet when requesting metadata for workload attestation. For additional security, you may wish to configure the Kubernetes workload attestor to perform this verification on compatible Kubernetes distributions by setting `skip_kubelet_verification` to `false`. [Read more](https://github.com/spiffe/spire/blob/master/doc/plugin_agent_workloadattestor_k8s.md)
+As configured, the SPIRE agent does not verify the identity of the Kubernetes kubelet when requesting metadata for workload attestation. For additional security, you may wish to configure the Kubernetes workload attestor to perform this verification on compatible Kubernetes distributions by setting `skip_kubelet_verification` to `false`. [Read more](https://github.com/spiffe/spire/blob/{{< spire-latest "tag" >}}/doc/plugin_agent_workloadattestor_k8s.md)
 
 # Next steps