From d3a7e254fe08e19e0292a48789a7f9af59be4c0e Mon Sep 17 00:00:00 2001 From: Patrick Smyth Date: Wed, 30 Aug 2023 17:35:15 -0400 Subject: [PATCH] Fix all 404 links (#229) * Fixed remaining 404 links Added link to Slack invite Changed link to external Slack community Resolves #228 Signed-off-by: Patrick Smyth * Appease the markdown linting gods Fixed trailing whitespace, spaces around headings and lists, consistent lists Updated another link to Slack Signed-off-by: Patrick Smyth More markdown fixes Signed-off-by: Patrick Smyth More linting Signed-off-by: Patrick Smyth --------- Signed-off-by: Patrick Smyth Signed-off-by: ltagliaferri Co-authored-by: ltagliaferri --- content/en/about/overview.md | 18 ++++++------- content/en/about/security.md | 30 ++++++++++++--------- content/en/about/support.md | 10 +++---- content/en/about/threat-model.md | 25 ++++++++++------- content/en/key_management/import-keypair.md | 2 +- content/en/logging/installation.md | 4 +-- 6 files changed, 50 insertions(+), 39 deletions(-) diff --git a/content/en/about/overview.md b/content/en/about/overview.md index 124293b6..9294f60b 100644 --- a/content/en/about/overview.md +++ b/content/en/about/overview.md @@ -16,19 +16,19 @@ It’s free to use for all developers and software providers, with Sigstore’s ## How to use Sigstore -* I want to [Quick Start](/signing/quickstart/) -* I want to [sign a blob](signing/signing_with_blobs/) -* I want to [sign a container](signing/signing_with_containers/) -* I want to [Sign Git commits with Gitsign](/signing/gitsign/) -* I want to [verify entries with Cosign](/verifying/verify/) +- I want to [Quick Start](/signing/quickstart/) +- I want to [sign a blob](signing/signing_with_blobs/) +- I want to [sign a container](signing/signing_with_containers/) +- I want to [Sign Git commits with Gitsign](/signing/gitsign/) +- I want to [verify entries with Cosign](/verifying/verify/) ## How Sigstore works -A Sigstore client, such as Cosign, requests a certificate from Fulcio, a code-signing certificate authority. A verifiable OpenID Connect identity token, which contains a user's email address or service account, is provided in the request. Fulcio verifies this token and issues a short-lived certificate bound to the provided identity. +A Sigstore client, such as Cosign, requests a certificate from Fulcio, a code-signing certificate authority. A verifiable OpenID Connect identity token, which contains a user's email address or service account, is provided in the request. Fulcio verifies this token and issues a short-lived certificate bound to the provided identity. You don’t have to manage signing keys, and Sigstore services never obtain your private key. The public key that a Sigstore client creates gets bound to the issued certificate, and the private key is discarded after a single signing. -After the client signs the artifact, the artifact's digest, signature and certificate are persisted in Rekor, an immutable, append-only transparency ledger, so that signing events can be publicly audited. Identity owners can monitor the log to verify that their identity is being properly used. This also timestamps the signing event, so that the short-lived certificate can be later verified. +After the client signs the artifact, the artifact's digest, signature and certificate are persisted in Rekor, an immutable, append-only transparency ledger, so that signing events can be publicly audited. Identity owners can monitor the log to verify that their identity is being properly used. This also timestamps the signing event, so that the short-lived certificate can be later verified. For verifying an artifact, a Sigstore client will verify the signature on the artifact using the public key from the certificate, verify the identity in the certificate matches an expected identity, verify the certificate's signature using Sigstore's root of trust, and verify proof of inclusion in Rekor. @@ -46,9 +46,9 @@ Sigstore is a Linux Foundation project backed by Google, Red Hat and Purdue Univ Up to date documentation, best practices and detailed scenarios for Sigstore live here. These pages are maintained by the community and intended to help anyone get set up easily with any of the technologies, to find what you’re looking for fast. It’s also where we keep all the relevant pages for the Sigstore trust root, from ceremonies to security practices. -Ready to jump in? Check the [contributing guidelines](/contributing/). +Ready to jump in? Check the [contributing guidelines](/about/contributing/). ## Learn more - [Sigstore YouTube Channel](https://www.youtube.com/@projectsigstore) -- [Sigstore Blog](https://blog.sigstore.dev/) +- [Sigstore Blog](https://blog.sigstore.dev/) diff --git a/content/en/about/security.md b/content/en/about/security.md index 809449b6..9ef19844 100644 --- a/content/en/about/security.md +++ b/content/en/about/security.md @@ -6,28 +6,31 @@ title: Security Model weight: 3 --- -The Sigstore security model has a few key components, each aimed at establishing trust or proving identity. For a quick overview of the key services mentioned in this document, see [Tooling](/tooling/). +The Sigstore security model has a few key components, each aimed at establishing trust or proving identity. For a quick overview of the key services mentioned in this document, see [Tooling](/about/tooling/). ## Proving Identity in Sigstore -Sigstore relies on the widely used OpenID Connect (OIDC) protocol to prove identity. When running something like `cosign sign`, users will complete an OIDC flow and authenticate via an identity provider (GitHub, GitLab, Google, etc.) to prove they are the owner of their account. Similarly, automated systems (like GitHub Actions) can use Workload Identity or [SPIFFE](https://spiffe.io/) Verifiable Identity Documents (SVIDs) to authenticate themselves via OIDC. The identity and issuer associated with the OIDC token is embedded in the short-lived certificate issued by Sigstore’s Certificate Authority, Fulcio. +Sigstore relies on the widely used OpenID Connect (OIDC) protocol to prove identity. When running something like `cosign sign`, users will complete an OIDC flow and authenticate via an identity provider (GitHub, Google, etc.) to prove they are the owner of their account. Similarly, automated systems (like GitHub Actions) can use Workload Identity or [SPIFFE](https://spiffe.io/) Verifiable Identity Documents (SVIDs) to authenticate themselves via OIDC. The identity and issuer associated with the OIDC token is embedded in the short-lived certificate issued by Sigstore’s Certificate Authority, Fulcio. ## Sigstore’s Trust Model -Sigstore’s trust model originates from the Trust Root and chains down to short-lived certificates issued by Fulcio. +Sigstore’s trust model originates from the Trust Root and chains down to short-lived certificates issued by Fulcio. ### Sigstore’s Trust Root The Trust Root, which was established during a public [root key signing ceremony](https://www.youtube.com/watch?v=GEuFsc8Zm9U), is made up of a rotation of five keyholders from varying companies and academic institutions who contribute to Sigstore. It leverages the principles of [The Update Framework](https://theupdateframework.io/) (TUF), a set of defined attacks and threat models specific to software distribution systems. TUF provides a cleverly designed set of protocols to protect against these types of attacks, which the Trust Root follows. The Sigstore Trust Root is used to secure the keys used by the entire Sigstore project. It allows individuals and systems to automatically retrieve trusted keys and certificates used to verify artifacts produced by the Sigstore ecosystem. Using the Sigstore Trust Root, end users can verify: -* Certificates issued by Fulcio -* Entries in the Rekor transparency log + +- Certificates issued by Fulcio +- Entries in the Rekor transparency log + This allows end users to verify (and trust) that the distributors of the software they use are who they say they are. For more details on the Trust Root or the key signing ceremony, see [A New Kind of Trust Root](https://blog.sigstore.dev/a-new-kind-of-trust-root-f11eeeed92ef). For an overview of TUF, see [The Update Framework and You](https://blog.sigstore.dev/the-update-framework-and-you-2f5cbaa964d5). ### Rekor Security Model + The Rekor service provides a transparency log of software signatures. The log is append-only and once entries are added they cannot be modified; a valid log can be cryptographically verified by any third-party. As entries are appended into this log, Rekor periodically signs the full [Merkle tree](https://transparency.dev) along with a timestamp. An entry in Rekor provides a single-party attestation that a piece of data existed prior to a certain time. These timestamps and the contents of the log cannot be tampered with or removed later, providing long-term trust. This long-term trust also requires that the log is monitored. @@ -36,24 +39,24 @@ Transparency Logs make it hard to forge timestamps long term, but in short time ### Fulcio Security Model -One of the targets secured by the Sigstore Trust Root is the Fulcio root certificate, which is used to issue short-lived code signing certificates. +One of the targets secured by the Sigstore Trust Root is the Fulcio root certificate, which is used to issue short-lived code signing certificates. -**Certificate Transparency Log** +### Certificate Transparency Log Fulcio assumes that a valid OIDC token from a trusted provider is sufficient “proof of ownership” of the associated identity. To mitigate against OIDC compromise, Fulcio appends certificates to an immutable, append-only cryptographically verifiable transparency log. This means: -* Fulcio MUST publish all certificates to the log. -* Clients MUST NOT trust certificates that are not in the log. +- Fulcio MUST publish all certificates to the log. +- Clients MUST NOT trust certificates that are not in the log. As a result, users can detect any mis-issued certificates, either due to the CA acting maliciously or a compromised OIDC identity provider. Combined with Rekor's signature transparency, artifacts signed with compromised accounts can be identified (auditability). _Note: Fulcio itself does not monitor the certificate transparency log; users are responsible for monitoring the log for unauthorized certificates issued to their identities._ -**Short Lived Certificates** +### Short Lived Certificates Fulcio also uses short-lived certificates as a solution to the key management problem. Traditional signing involves issuing long-lived certificates, but this method assumes that users won’t lose their private key or that the key won’t get stolen or otherwise compromised for long periods of time. -Fulcio was designed to avoid revocation by issuing short-lived certificates instead. When signing, the user only needs to know that the artifact was signed while the certificate was valid. +Fulcio was designed to avoid revocation by issuing short-lived certificates instead. When signing, the user only needs to know that the artifact was signed while the certificate was valid. How can a user do that? @@ -63,11 +66,12 @@ End users can leverage Fulcio's short-lived code signing certificates and Rekor' Storing the signature in a transparency log also makes certificates easily discoverable so that maintainers don’t have to worry about public key distribution. -**Ephemeral Keys** +### Ephemeral Keys Sigstore clients like Cosign can also eliminate the key management problem by using ephemeral keys. These ephemeral keys only exist in memory; the private key never hits disk and is never known by Sigstore services. Cosign will: + 1. Generate an ephemeral public/private keypair in memory 1. Bind the public key to a short-lived certificate requested from Fulcio 1. Sign an artifact with the ephemeral private key while the certificate is still valid @@ -75,7 +79,7 @@ Cosign will: Clients like Cosign only need to find the correct Rekor entry to verify the artifact. -## What Sigstore *Doesn't* Guarantee +## What Sigstore _Doesn't_ Guarantee - If an OIDC identity or OIDC provider is compromised, Fulcio might issue unauthorized certificates. However, these certificates are useless unless they are published to the certificate transparency log, so such compromise can be detected. - If Fulcio is compromised, it might issue unauthorized certificates. However, like before, these should be detectable. diff --git a/content/en/about/support.md b/content/en/about/support.md index 7144a25a..e2bdf975 100644 --- a/content/en/about/support.md +++ b/content/en/about/support.md @@ -10,11 +10,11 @@ If you are not able to find the relevant information to solve your issue, you ca This page describe how you could get in touch with us to get support. -# Help from the community +## Help from the community -Sigstore has a [Slack community](/community/#slack). Please post any support request in `#general` channel. +Sigstore has a [Slack community](https://sigstore.slack.com/), and you can [request an invite at this link](https://join.slack.com/t/sigstore/shared_invite/zt-1z7jzpemb-xEKSUtpgDFXpIEMwMYZQKQ). Please post any support requests in the `#general` channel. -# Help from project maintainers +## Help from project maintainers Each repository has a `CODEOWNERS` file describing current maintainers. Join our Slack channel and get in touch with them. @@ -28,6 +28,6 @@ Each repository has a `CODEOWNERS` file describing current maintainers. Join our [rekor]: https://github.com/sigstore/rekor/blob/main/CODEOWNERS [sigstore]: https://github.com/sigstore/sigstore/blob/main/CODEOWNERS -# Asking questions +## Asking questions -We welcome questions! You can either join the [Slack community][sc] and post them on `#general` channel or open a GitHub issue in the relevant repository. +We welcome questions! You can either join the [Slack community](https://sigstore.slack.com/) and post them on `#general` channel or open a GitHub issue in the relevant repository. diff --git a/content/en/about/threat-model.md b/content/en/about/threat-model.md index 67e3e0b7..4a85bd1d 100644 --- a/content/en/about/threat-model.md +++ b/content/en/about/threat-model.md @@ -9,7 +9,7 @@ weight: 3 ## Introduction **What types of security analysis have you done on Sigstore?** -This page contains the results of a threat modeling exercise on Sigstore. First, we enumerate the components of Sigstore along with third parties and infrastructure that it uses during the [“keyless” signing](/cosign/sign#keyless-signing) and verification flows. Second, we postulate an attacker that can compromise various subsets of these parties. Finally, we analyze the impact of such an attacker on these security properties. The results of a similar exercise are included in the peer-reviewed paper [Sigstore: Software Signing for Everybody](https://dl.acm.org/doi/pdf/10.1145/3548606.3560596). +This page contains the results of a threat modeling exercise on Sigstore. First, we enumerate the components of Sigstore along with third parties and infrastructure that it uses during the [“keyless” signing](/signing/overview/) and verification flows. Second, we postulate an attacker that can compromise various subsets of these parties. Finally, we analyze the impact of such an attacker on these security properties. The results of a similar exercise are included in the peer-reviewed paper [Sigstore: Software Signing for Everybody](https://dl.acm.org/doi/pdf/10.1145/3548606.3560596). This will be most useful to those building secure systems on top of Sigstore, rather than end users. The security guarantees of such systems depends on the details of integration; an example analysis can be found in [TAP-18](https://github.com/theupdateframework/taps/blob/master/tap18.md), which proposes using Sigstore identities with a [TUF](https://theupdateframework.com/) repository used to securely distribute software artifacts. @@ -27,11 +27,11 @@ It does not guarantee that the signer *should* be able to authenticate (for inst Further, if Sigstore itself is compromised, this property may not hold; see our analysis below. - **What should I do or keep in mind to mitigate these threats when using Sigstore?** First, users of Sigstore should ensure that they have tooling to audit Sigstore’s transparency logs for consistency and to monitor the use of their identities in Sigstore. Sistore operators provide [some tooling](https://github.com/sigstore/rekor-monitor) for these efforts. Second, all OIDC accounts used to create Sigstore signatures should have 2FA enabled to reduce the likelihood of a compromise. In this threat model, we consider the compromise of any of the following: + * Fulcio CA server * Fulcio CT Log * Rekor server @@ -45,29 +45,34 @@ Here’s a high-level diagram of the Sigstore signing flow, with the components ![Sigstore signing flow](/sigstore-threat-model-signing.svg) - ## Main takeaways + * Identity and consistency monitoring is critical to mitigate risks of compromise to both the Fulcio CT log and Rekor. All signers should monitor the Fulcio CT log for unauthorized use of their identity, and all verifiers should look for alerts from consistency monitors. * The Fulcio CA is a particularly important source of trust and must be hardened. * OIDC issuers are highly trusted in Sigstore, and only properly hardened OIDC issuers should be used. -* OIDC account compromise is not handled by Sigstore, but we recommend that OIDC issuers provide revocation in the case of a compromised OIDC account. In addition, we recommend the use of 2FA on all OIDC accounts used with Sigstore in order to reduce the likelihood of a compromise. +* OIDC account compromise is not handled by Sigstore, but we recommend that OIDC issuers provide revocation in the case of a compromised OIDC account. In addition, we recommend the use of 2FA on all OIDC accounts used with Sigstore in order to reduce the likelihood of a compromise. * TUF root of trust provides strong revocation abilities for all services managed by Sigstore. ## Sigstore threat model ### Scenario for Table 1 + This table analyzes the attacker capabilities when the attacker compromises different Sigstore components. This table assumes that Fulcio is used to sign any software artifacts. The storage mechanism (repository, etc.) for artifacts and metadata are out of scope for this model. The table description assumes TUF is not in play, except in the root of trust defined by Sigstore. We assume that there are multiple monitors of Rekor and the Fulcio CT log that communicate with a gossip protocol. Each monitor ensures that the log remains append only by reviewing the full state of the log. A compromise would mean all monitors are compromised. The table is sorted by the impact of the attacker’s capabilities. Compromises which have different capabilities with the same impact are grouped together. The actors in this table are described below: ### Action: Alice signs an artifact with Sigstore + Alice authenticates herself against the OIDC identity provider to get an OIDC ID token. She then sends a certificate request to the Fulcio CA with a generated public key and the OIDC ID token. The Fulcio CA verifies the authenticity of the OIDC ID token with the OIDC identity provider, then extracts the subject from the token to use as the SAN in the certificate. The Fulcio CA generates and signs a precertificate, which is uploaded to the Fulcio CT log. The Fulcio CT log generates and signs a SCT (signed certificate timestamp), which is sent back to the Fulcio CA. The Fulcio CA combines the SCT with the precertificate to get the final certificate which is sent to Alice. Alice uses the key associated with the certificate to sign the artifact. She uploads the certificate and signature to Rekor, which stores them in the logs and returns an SET (signed entry timestamp) that promises inclusion in the log at a particular time. The verifier can use this time to ensure the certificate was used while it was valid. ### Action: Bob verifies an artifact with Sigstore + Bob has an artifact, signature, and Fulcio certificate. He knows that Alice is trusted to sign this artifact due to either a TUF delegation that lists her as the identity, or some other namespacing mechanism such as a policy configuration. Bob gets trusted keys for Sigstore services using the TUF root of trust. He then checks that the certificate was signed by the Fulcio CA and that Alice is the subject. He verifies that the certificate is present in the Fulcio CT log. He checks the signature on the artifact using the key in the certificate. He then checks the Rekor SET embedded in the signature to ensure the signature was made during the validity window of the certificate. Next, he queries Rekor for the proof of inclusion to perform online verification and ensure that the signature is included in the Rekor TL. ### Action: Charlie monitors the Rekor CT log + Charlie queries Rekor periodically and ensures that the log is append-only by ensuring that all entries that were in the log are still present. Charlie also talks to other Rekor monitors to ensure that the tree head is consistent for all users. If he notices an issue, he reports it to Sigstore admins, who verify the report before working toward recovery. Charlie may do additional checks for entry validity. ### Action: Deborah monitors the Fulcio CT log + Deborah queries the Fulcio CT log periodically to ensure that all entries that were in the log are still present. She also talks to other Fulcio monitors to ensure that the tree head is consistent for all users. If she notices an issue, she reports it to Sigstore admins, who verify the report before working toward recovery. | **Compromise** | **Attacker capabilities** | **Other security impacts** | @@ -87,25 +92,26 @@ Deborah queries the Fulcio CT log periodically to ensure that all entries that w | OIDC server | Arbitrary software attack for anything that OIDC domain covers. | | Fulcio CA server AND OIDC server | Same as OIDC server + Fulcio. OIDC cannot recover, Fulcio is not domain limited | | Sigstore root of trust | Can become the Fulcio CA, Rekor, the Fulcio CA log, etc. Arbitrary software attack is trivial from there with MITM. | Monitors may detect the attack, but Sigstore admins can’t recover without control of the root of trust. | - ## Mitigations and recommendations Here, we describe recommendations for using Sigstore in such a way that the likelihood and impact of a compromise are both mitigated. ### 2FA on OIDC accounts -As shown in the table above, compromise of an OIDC account is sufficient for an arbitrary software attack for any packages that account is trusted to sign. To mitigate this risk, we recommend reducing the likelihood of account compromise through the use of 2FA on all accounts that will be used with Sigstore. 2FA requires that not just a password, but a second factor like a YubiKey or authenticator app is also compromised. For maximum security, users should avoid less secure forms of 2FA such as text messages and phone calls. + +As shown in the table above, compromise of an OIDC account is sufficient for an arbitrary software attack for any packages that account is trusted to sign. To mitigate this risk, we recommend reducing the likelihood of account compromise through the use of 2FA on all accounts that will be used with Sigstore. 2FA requires that not just a password, but a second factor like a YubiKey or authenticator app is also compromised. For maximum security, users should avoid less secure forms of 2FA such as text messages and phone calls. OIDC does not provide a mechanism for checking if accounts have 2FA enabled, and so enforcement of this recommendation is up to individual signers in the ecosystem. ### Identity monitors + All certificates that are issued by Fulcio are written to a Certificate Transparency log, accessible at ctfe.sigstore.dev. For each artifact, Sigstore clients publish the artifact's hash, signature, and certificate to this transparency log. A signature verifier must check that an artifact has been uploaded to Rekor and the certificate has been published to Fulcio's log before trusting the artifact. This ensures that the artifact and certificate are publicly auditable, so that the identity owner can monitor the log to find unexpected occurrences of their identity. Sigstore provides an easy-to-use GitHub Actions-based log monitor, [rekor-monitor](https://github.com/sigstore/rekor-monitor). Currently, it supports monitoring identities only for the hashedrekord Rekor type, which is the default uploaded type for Cosign and other Sigstore clients. See the [README](https://github.com/sigstore/rekor-monitor#readme) for information on setting up the reusable workflow with identity monitoring. Identities can include email or machine identity, for example for CI workflows such as GitHub Actions or GKE. rekor-monitor currently supports matching on exact string matches, which works well for email or specific CI workflows. We plan to add support for matching on regular expressions so that repository owners can monitor across repositories in an organization. - ### Secure distribution (and revocation) of Sigstore key material + The above compromise scenarios for Fulcio, Rekor, and other parties describe either a compromise of the infrastructure itself or a compromise of the signing material used by those parties to make claims. That is, if you had Fulcio’s signing key, you wouldn’t need to additionally hack Fulcio to make false claims. This means that secure distribution of Sigstore key material is paramount for security—if that process can be intercepted, we can consider all of the infrastructure effectively compromised. @@ -121,6 +127,7 @@ To deal with this, we recommend the use of a strong root of trust for distributi The Sigstore public good instance has a [root of trust](https://github.com/sigstore/root-signing) based on TUF that can be publicly audited, with geographically- and organizationally-distributed root key holders. ### Policy considerations + The security guarantees that Sigstore provides are useful but relatively minimal: it can show you that a signature came from someone controlling a specific digital identity, but not whether you should trust that identity. Critically, [not everything that’s signed is secure](https://blog.sigstore.dev/signatus-ergo-securus-who-can-sign-what-with-tuf-and-sigstore-ea4d3d84b8b6): when verifying software, you need a policy for knowing whom to trust. That policy should cover: @@ -128,8 +135,8 @@ That policy should cover: * How do you identify software artifacts (e.g., by their name)? * Which identities are permitted to sign a given software artifact? * Which identity providers can those identities come from? - * Do the identity providers perform identity verification like “know-your-customer?” - * Do they handle account compromise and recovery? + * Do the identity providers perform identity verification like “know-your-customer?” + * Do they handle account compromise and recovery? * Do you permit the use of public verification keys for identities, or must identities have an associated identity provider? * Which Sigstore instance(s) do you trust, and how do you retrieve the key material for those instances? * How do you handle revocation? diff --git a/content/en/key_management/import-keypair.md b/content/en/key_management/import-keypair.md index 0471f825..a96ca255 100644 --- a/content/en/key_management/import-keypair.md +++ b/content/en/key_management/import-keypair.md @@ -9,7 +9,7 @@ weight: 510 ### Import a Key Pair -To use a local key not generated by cosign for signing, the key must be imported. To use a key stored in a [KMS](/cosign/kms_support/), importing is not necessary and the key can be [specified by resource name](/cosign/kms_support/#signing-and-verification). +To use a local key not generated by cosign for signing, the key must be imported. To use a key stored in a [KMS](/key_management/overview/), importing is not necessary and the key can be [specified by resource name](/key_management/overview/#signing-and-verification). The importing of a key pair with `cosign` is as follows. diff --git a/content/en/logging/installation.md b/content/en/logging/installation.md index 706ee2e1..bca54f17 100644 --- a/content/en/logging/installation.md +++ b/content/en/logging/installation.md @@ -45,7 +45,7 @@ There are a few ways you can deploy a Rekor Server: 1. We have a [docker-compose](https://github.com/sigstore/rekor/blob/main/docker-compose.yml) file available. 2. Alternatively, you can build a Rekor server yourself. -Note: The Rekor server manually creates a new Merkle tree (or shard) in the Trillian backend every time it starts up, unless an existing one is specified in via the `--trillian_log_server.tlog_id` flag. If you are building the server yourself and do not need [sharding](/rekor/sharding/) functionality, you can find the existing tree's TreeID by issuing this client command while the server is running: +Note: The Rekor server manually creates a new Merkle tree (or shard) in the Trillian backend every time it starts up, unless an existing one is specified in via the `--trillian_log_server.tlog_id` flag. If you are building the server yourself and do not need [sharding](/logging/sharding/) functionality, you can find the existing tree's TreeID by issuing this client command while the server is running: `CURRENT_TREE_ID=$(rekor-cli loginfo --format json | jq -r .TreeID)` @@ -150,4 +150,4 @@ rekor-server serve --enable_retrieve_api=false #### Next Steps -Congratulations! Your local Rekor server is now running. You can interact with it using the [Rekor CLI](/rekor/CLI/). +Congratulations! Your local Rekor server is now running. You can interact with it using the [Rekor CLI](/logging/cli/).