A full, open source zero trust overlay network. Including numerous SDKs for numerous languages such as [golang](https://github.com/openziti/sdk-golang) allowing you to embed zero trust principles directly into your applications. The [OpenZiti Test Kitchen](https://github.com/openziti-test-kitchen) has numerous examples to draw inspiration from including a [zero trust ssh client - zssh](https://github.com/openziti-test-kitchen/zssh)

[![Build Status](https://github.com/openziti/ziti/actions/workflows/main.yml/badge.svg?query=branch%3Arelease-next)](https://github.com/openziti/ziti/actions/workflows/main.yml?query=branch%3Arelease-next)
[![Go Report Card](https://goreportcard.com/badge/github.com/openziti/ziti)](https://goreportcard.com/report/github.com/openziti/ziti)
[![GoDoc](https://godoc.org/github.com/openziti/ziti?status.svg)](https://pkg.go.dev/github.com/openziti/ziti)
[![Discourse](https://img.shields.io/badge/Discourse-forum-blue?logo=discourse)](https://openziti.discourse.group/)
[![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://github.com/openziti/ziti/blob/main/LICENSE)
[![GitHub Stars](https://img.shields.io/github/stars/openziti/ziti?style=social)](https://github.com/openziti/ziti)

# OpenZiti

OpenZiti is an open-source zero-trust networking platform that makes network services invisible to unauthorized users. Every connection, whether from a user, a service, a device, or a workload, is authenticated with cryptographic identity, authorized by policy, and encrypted end-to-end.

OpenZiti works with both existing applications (using lightweight tunnelers with no code changes required) and new applications (using embedded SDKs for the strongest zero-trust model). This makes it practical for both brownfield environments and greenfield development.

Created and sponsored by [NetFoundry](https://netfoundry.io). Licensed under [Apache 2.0](LICENSE).

<p align="center">
  <img src="./doc/images/openziti-architecture.svg" alt="OpenZiti Architecture: Controller, Edge Routers, SDKs, and Tunnelers" width="100%"/>
</p>

---

## Table of Contents

- [Use Cases](#use-cases)
- [Key Capabilities](#key-capabilities)
- [Three Deployment Models](#three-deployment-models)
- [Getting Started](#getting-started)
- [Architecture](#architecture)
- [Zero Trust, Dark Services, and End-to-End Encryption](#zero-trust-dark-services-and-end-to-end-encryption)
- [SDKs](#sdks)
- [Community & Support](#community--support)
- [Contributing](#contributing)
- [Adopters](#adopters)
- [Managed Solution](#managed-solution)

---

## Use Cases

OpenZiti enables you to extend zero-trust anywhere for any use case, including non-human workloads and workflows, across multiple networks and third parties.  The following are some common use cases.

### Replace VPNs

Provide secure access to internal services without VPN clients, split tunneling headaches, or concentrator bottlenecks. Each service is individually authorized. No "once you're in, you can reach everything" problem.

### Dark APIs and Services

Make APIs and services invisible to the internet. Zero listening ports means zero attack surface. Authorized clients connect through OpenZiti; everyone else sees nothing.

### IoT and Non-Human Identity

Give every device, sensor, and machine a unique cryptographic identity. OpenZiti's identity model works for non-human workloads just as well as human users, providing strong authentication for the machine-to-machine connections that make up the majority of modern network traffic.

### Zero Trust Workloads

Secure workload-to-workload communication across clouds and environments. Services authenticate each other with cryptographic identity, not network location. No shared secrets, no IP allowlists, no ambient authority.

### Agentic AI

Secure agent-to-service and agent-to-agent communication with cryptographic identity for every AI participant. MCP servers, tool endpoints, and private LLMs stay dark, with no listening ports or public URLs. Agents authenticate with strong, unique identities and reach only the resources that the policy allows, so autonomous workflows get the access they need without ambient authority over everything else.

### Multi-Cloud and Hybrid Connectivity

One overlay network across AWS, Azure, GCP, on-prem data centers, and edge locations. No cloud-specific networking tools, no VPN tunnels between environments, no complex peering arrangements.

### Self-Hosted Service Access

Access home lab or self-hosted services like Nextcloud, Home Assistant, media servers, and development environments from anywhere. No open router ports, no dynamic DNS, no reliance on third-party tunnel services. You control the entire path.

### Kubernetes and Cross-Cluster Services

Connect services across Kubernetes clusters without complex ingress rules, service mesh sidecars, or VPN tunnels between clusters. Works beyond Kubernetes, supporting connecting k8s services to VMs, bare metal, IoT devices, or anything else on the overlay.

---

## Key Capabilities

| Capability | Description |
|---|---|
| **Dark Services** | Services have zero listening ports. Invisible to scanners and unauthorized users. |
| **Identity for Everything** | Cryptographic identity for users, services, devices, and non-human workloads (NHI). Not IP-based. |
| **Identity-Based Operations** | Manage networks through identities and policies instead of IP addresses and firewall rules. Simplifies operations and eliminates manual network configuration. |
| **End-to-End Encryption** | Data encrypted from source to destination using libsodium. mTLS for authentication. Zero trust in the network path. |
| **No VPNs or Open Ports** | Connections route through OpenZiti's overlay. No VPN clients, no inbound firewall rules, no exposed ports. |
| **Smart Routing** | Mesh fabric with intelligent path selection for performance and reliability. |
| **Flexible Deployment** | Embed SDKs, use tunnelers, or deploy at the network level. Mix and match per service. |
| **Policy-Driven Access** | Fine-grained, identity-based policies. Access can be revoked in real time, closing active connections. |
| **Programmable REST APIs** | Full management API for automation and integration. Web-based admin console included. |
| **Fully Self-Hostable** | Run the entire platform on your infrastructure. No vendor dependencies. Open source, Apache 2.0. |

---

## Three Deployment Models

OpenZiti supports three zero-trust models. Mix them in a single network and migrate between them over time.

### Network Access

Deploy an OpenZiti edge router in a trusted network zone. Traffic enters the overlay from authenticated clients and exits into the private network where services run.

- **Code changes:** None
- **Agent on service host:** None
- **Security model:** Identity-based access at the network boundary. Similar to a gateway, but with cryptographic identity and encrypted transport.

### Host Access

Run an OpenZiti tunneler on the same host as your service. The tunneler handles identity, authentication, and encryption. The service only needs to accept connections from localhost.

- **Code changes:** None
- **Setup:** Install tunneler, enroll identity
- **Security model:** Trust boundary at the host OS. Service is dark to the network and only reachable through the tunneler.

### Application Access (Strongest)

Embed an OpenZiti SDK directly in client and/or server applications. The application itself holds the cryptographic identity and encrypts traffic in-process. No listening ports exist, not even on localhost.

- **Code changes:** Yes
- **Security model:** Strongest. End-to-end encryption in-process. Fully dark. Identity at the application layer, not the network, not the host.

> **Where to start:** Many teams begin with **Host Access** (tunnelers) for existing services. It deploys in minutes with no code changes. For new development or high-security workloads, **Application Access** (SDKs) provides the strongest zero-trust posture.

---

## Getting Started

The following Quick Starts show how to set up a local OpenZiti network for development, testing, and learning.  For production deployments, see the product documentation at https://netfoundry.io/docs/openziti/category/deployments/.

### Quick Start with Docker

The fastest way to get a local OpenZiti network running:

```bash
wget https://get.openziti.io/dock/all-in-one/compose.yml
docker compose up
```

This starts a controller, edge router, and the Ziti console in a single compose stack. The console is available at `https://localhost:1280/zac/`. From here you can create identities, define services, and configure access policies.

See the [all-in-one Docker quickstart](./quickstart/docker/all-in-one) for full details including storage options, environment variables, and CLI usage.

### Quick Start with the CLI

Download the latest `ziti` binary from [GitHub Releases](https://github.com/openziti/ziti/releases/latest), then:

```bash
ziti edge quickstart
```

This brings up a local development network: controller, router, and a default admin identity. Ideal for testing and learning.

### Learn More

| Resource | Description |
|---|---|
| [Introduction](https://netfoundry.io/docs/openziti/learn/introduction/) | Core concepts and how OpenZiti works |
| [Quickstart Guides](https://netfoundry.io/docs/openziti/learn/quickstarts/) | Step-by-step setup for local, Docker, and hosted environments |
| [Zero Trust Models](https://netfoundry.io/docs/openziti/learn/core-concepts/zero-trust-models/overview/) | Deep dive into the three deployment models |
| [Tunneler Reference](https://netfoundry.io/docs/openziti/reference/tunnelers/) | Get started with zero code changes |

---

## Architecture

OpenZiti's overlay network runs on top of existing infrastructure: any IP network, any cloud, any combination. The core components:

### Controller

The controller is the management plane. It handles:

- **Identity management**: issues and verifies cryptographic identities (x509 certificates) for every participant in the network
- **Policy enforcement**: defines which identities can access which services, through which edge routers
- **Network state**: tracks routers, services, and topology; provides a REST API and web-based admin console for management

### Edge Routers

Edge routers form the data plane, a mesh fabric that carries encrypted traffic between endpoints.

- **Public routers** are reachable from the internet, serving as entry points to the network
- **Private ("dark") routers** are deployed inside private networks with only outbound connections

Routers automatically discover each other, form mesh connections, and use smart routing to select the best path based on latency, throughput, and cost.

### Endpoints: SDKs and Tunnelers

Endpoints are how applications and users connect to the OpenZiti network:

- **SDKs** (Go, C, Python, Node.js, Java, Swift, C#): embed zero trust directly in your application. The app itself holds the identity and handles encryption. No sidecar, no agent, no listening ports.

- **Tunnelers** (Linux, Windows, macOS, iOS, Android): lightweight apps that provide OpenZiti connectivity to unmodified software. Traffic is intercepted and routed through the overlay transparently. No code changes required.

---

## Zero Trust, Dark Services, and End-to-End Encryption

### Zero Trust and Application Segmentation

Every participant (e.g., user, service, device, workload) in an OpenZiti network carries a unique cryptographic identity backed by x509 certificates. When a connection is attempted, OpenZiti verifies:

1. The identity is valid and enrolled
2. A policy exists granting that identity access to the requested service
3. The connection is through an authorized edge router

If any check fails, the connection is denied. If access is later revoked, active connections are terminated immediately. There is no implicit trust based on network location. Being on the same LAN grants no more access than being across the internet, unless policy explicitly allows it.

This model provides zero trust application segmentation: each service is independently authorized. Gaining access to one service does not grant access to any other.

### Dark Services

A "dark" service has no open ports. It doesn't listen on any network interface for incoming connections. Instead, the service (or a tunneler alongside it) makes an **outbound** connection to an OpenZiti edge router and registers itself. Clients reach it only through the OpenZiti fabric, after authentication and authorization.

What this means in practice:

- **Port scans find nothing**: there are no listening ports to discover
- **No attack surface**: you can't exploit what you can't reach
- **DDoS resistance**: there is no public endpoint to flood
- **Invisible to unauthorized users**: only identities with matching policy even know the service exists
- **NAT and firewall friendly**: all connections are outbound, so CG-NAT, double-NAT, and restrictive firewalls are not a concern

Edge routers can also be dark. Private routers make only outbound connections, so no inbound firewall rules are needed in your private network.

### End-to-End Encryption

With OpenZiti SDKs, traffic is encrypted from the sending application to the receiving application using libsodium for the data path and mTLS for identity authentication. Even if routers or intermediate networks are compromised, traffic cannot be decrypted or tampered with.

With tunnelers, encryption covers the path from tunneler to tunneler (or tunneler to SDK), providing machine-to-machine encryption without application changes.

---

## SDKs

Embed zero-trust networking directly in your applications:

| Language | Repository | Notes |
|---|---|---|
| Go | [sdk-golang](https://github.com/openziti/sdk-golang) | Used by the OpenZiti project itself |
| C | [ziti-sdk-c](https://github.com/openziti/ziti-sdk-c) | Ideal for embedded systems, IoT, and high-performance use cases |
| Java / Kotlin | [ziti-sdk-jvm](https://github.com/openziti/ziti-sdk-jvm) | Includes Android support |
| Swift | [ziti-sdk-swift](https://github.com/openziti/ziti-sdk-swift) | iOS and macOS |
| Node.js | [ziti-sdk-nodejs](https://github.com/openziti/ziti-sdk-nodejs) | |
| C# / .NET | [ziti-sdk-csharp](https://github.com/openziti/ziti-sdk-csharp) | |
| Python | [ziti-sdk-py](https://github.com/openziti/ziti-sdk-py) | |

All SDKs are listed under the [OpenZiti GitHub organization](https://github.com/openziti).

---

## Security

OpenZiti is a security-focused project. Responsible disclosure of vulnerabilities helps us keep the platform and its users safe.

**Reporting a vulnerability:** If you discover a security issue, please review our [Vulnerability Disclosure Policy](https://github.com/openziti/security/blob/main/vulnerability_disclosure_policy.md) for full details. Sensitive issues should be reported to **security@openziti.org**. Non-sensitive issues can be filed as GitHub issues in the appropriate repository. You should receive a response within 7 days.

**How we handle vulnerabilities:** Our [Product Security Incident Response Process](https://github.com/openziti/security/blob/main/product_security_incident_response_process.md) describes how reported vulnerabilities are triaged, documented, and resolved — including how CVE releases are coordinated with fixes.

**Safe harbor:** OpenZiti and NetFoundry will not pursue legal action against anyone who researches and reports vulnerabilities in good faith. We encourage security research and attribute reported findings to their reporters in advisories and release notes.

---

## Community & Support

OpenZiti has an active and growing community:

- **[Discourse Forum](https://openziti.discourse.group/)**: Ask questions, share projects, get help from the community and maintainers
- **[YouTube](https://www.youtube.com/@OpenZiti)**: Tutorials, demos, and deep dives
- **[Blog](https://blog.openziti.io)**: Project updates and technical articles
- **[Twitter/X](https://twitter.com/openziti)**: News and announcements

---

## Contributing

The OpenZiti project welcomes contributions including code, documentation, bug reports, and feedback.

### Key Repositories

| Repository | Description |
|---|---|
| [openziti/ziti](https://github.com/openziti/ziti) | Core platform: controller, routers, CLI |
| [sdk-golang](https://github.com/openziti/sdk-golang) | Go SDK |
| [ziti-sdk-c](https://github.com/openziti/ziti-sdk-c) | C SDK |
| [ziti-sdk-jvm](https://github.com/openziti/ziti-sdk-jvm) | Java / Kotlin / Android SDK |
| [ziti-sdk-swift](https://github.com/openziti/ziti-sdk-swift) | Swift / iOS SDK |
| [ziti-sdk-nodejs](https://github.com/openziti/ziti-sdk-nodejs) | Node.js SDK |
| [ziti-sdk-csharp](https://github.com/openziti/ziti-sdk-csharp) | C# SDK |
| [ziti-sdk-py](https://github.com/openziti/ziti-sdk-py) | Python SDK |
| [ziti-tunnel-sdk-c](https://github.com/openziti/ziti-tunnel-sdk-c) | Linux tunneler and core tunneler SDK |
| [ziti-tunnel-apple](https://github.com/openziti/ziti-tunnel-apple) | macOS and iOS edge clients |
| [desktop-edge-win](https://github.com/openziti/desktop-edge-win) | Windows desktop edge client |
| [ziti-doc](https://github.com/openziti/ziti-doc) | Documentation site |

### Building from Source

See the [local development tutorial](./doc/002-local-dev.md) for build instructions.

### Developer Documentation

- [Developer Overview](./doc/001-overview.md)
- [Local Development](./doc/002-local-dev.md)
- [Local Deployment](./doc/003-local-deploy.md)
- [Controller PKI](./doc/004-controller-pki.md)
- [Release Notes](./CHANGELOG.md)

---

## Adopters

OpenZiti is used in production by organizations including [DeltaSecure](https://deltasecure.de/) (managed SOC), [Resulticks](https://www.resulticks.com/) (marketing automation), [Chirp Wireless](https://chirpwireless.io/) (IoT/telecom), [GIGO Dev](https://gigo.dev/) (cloud dev environments), [OSMIT](https://osmit.de/) (managed IT/GDPR compliance), and open-source projects like [zrok](https://zrok.io) and [BlueBubbles](https://bluebubbles.app).

See the full list: **[ADOPTERS.md](./ADOPTERS.md)**. Using OpenZiti? We'd love to add you — open an issue or submit a PR.

---

## Managed Solution

For zero-trust networking without managing your own infrastructure, [NetFoundry](https://netfoundry.io/docs/openziti/#deploy_an_overlay) provides a fully managed, globally distributed OpenZiti network as a service, with SLAs, enterprise support, and a global fabric of edge routers.

---

*OpenZiti is developed and open-sourced by [NetFoundry, Inc](https://netfoundry.io).*

OpenZiti

Utilizes Spiffe JWT authentication with Hashicorp Vault for secretless authentication

# SPIFFE Vault

Integrates [SPIFFE][spiffe] SVID authentication with [Hashicorp Vault][hashivault] to retrieve a `VAULT_TOKEN`.

[![Go CI](https://github.com/philips-labs/spiffe-vault/actions/workflows/golang.yml/badge.svg)](https://github.com/philips-labs/spiffe-vault/actions/workflows/golang.yml)
[![Go Report Card](https://goreportcard.com/badge/github.com/philips-labs/spiffe-vault)](https://goreportcard.com/report/github.com/philips-labs/spiffe-vault)
[![codecov](https://codecov.io/gh/philips-labs/spiffe-vault/branch/main/graph/badge.svg)](https://codecov.io/gh/philips-labs/spiffe-vault)

## Example usecases

- Read secrets from Hashicorp Vault [Hashicorp Vault][hashivault] without providing a secret to authenticate against [Hashicorp Vault][hashivault]. Instead we will be using a [SPIFFE][spiffe] SVID to authenticate ourself against [Hashicorp Vault][hashivault].

- Perform secretless/keyless code signing by utilizing the [Hashicorp Vault Transit engine](https://www.vaultproject.io/docs/secrets/transit) as a software defined HSM. This resolves the issue of having signing keys on a local machine as well resolves the issue of managing secrets to access the signing keys. Again we utilize the [SPIFFE][spiffe] SVID to authenticate against Hashicorp Vault.

[hashivault]: https://vaultproject.org "hashicorp Vault"
[spiffe]: https://spiffe.io "SPIFFE"

## Build

### Compile

```bash
make build
```

### Docker

Using the default `DOCKER_HOST` on your system (usually `unix:///var/run/docker.sock`), you can build the docker image with:

```bash
make image
```

Using e.g. the colima `DOCKER_HOST` (usually `unix:///Users/marco/.colima/default/docker.sock`), you can build the docker image with:

```bash
DOCKER_HOST=unix:///Users/marco/.colima/default/docker.sock make image
```

## Use

### Basic

```bash
$ export VAULT_ADDR=http://localhost:8200
$ bin/spiffe-vault auth -role my-role
# Export following environment variable to authenticate to Hashicorp Vault
export VAULT_TOKEN=s.IK1LBrCGXFQDAgawmhNLbcDH
```

### Advanced

Depending on the shell you are using you can automatically export the variable.

<details>
  <summary>bash</summary>

```bash
$ export VAULT_ADDR=http://localhost:8200
$ echo "$(bin/spiffe-vault auth -role my-role)" > /tmp/spiffe-vault
$ source /tmp/spiffe-vault
$ vault kv get secrets/my-key
====== Metadata ======
Key              Value
---              -----
created_time     2021-08-24T08:20:54.925866504Z
deletion_time    n/a
destroyed        false
version          1

============= Data =============
Key                       Value
---                       -----
username                  marco
password                  Supers3cr3t!
$ vault token lookup
Key                 Value
---                 -----
accessor            rwpXIHXzbVIMN2TL25Lfssef
creation_time       1629970184
creation_ttl        1m
display_name        jwt-spiffe://dev.localhost/ns/my-app/sa/my-app-backend
entity_id           8904661e-5a9f-3af5-c269-257e8a0a31d0
expire_time         2021-08-26T09:30:44.424072877Z
explicit_max_ttl    0s
id                  s.eOdhqe1hVV0OPS7M0TSeEqjG
issue_time          2021-08-26T09:29:44.424078028Z
meta                map[role:my-role]
num_uses            0
orphan              true
path                auth/jwt/login
policies            [default my-role]
renewable           true
ttl                 13s
type                service
$ vault token renew
Key                  Value
---                  -----
token                s.f1mFvr0TdEuvmfcZT0jBLCc5
token_accessor       vxginlb81XMEIPefLpRz1P24
token_duration       1m
token_renewable      true
token_policies       ["default" "my-role"]
identity_policies    []
policies             ["default" "my-role"]
token_meta_role      my-role
$ vault token lookup
Key                  Value
---                  -----
accessor             vxginlb81XMEIPefLpRz1P24
creation_time        1629970320
creation_ttl         1m
display_name         jwt-spiffe://dev.localhost/ns/my-app/sa/my-app-backend
entity_id            8904661e-5a9f-3af5-c269-257e8a0a31d0
expire_time          2021-08-26T09:33:53.57444787Z
explicit_max_ttl     0s
id                   s.f1mFvr0TdEuvmfcZT0jBLCc5
issue_time           2021-08-26T09:32:00.135787193Z
last_renewal         2021-08-26T09:32:53.574447972Z
last_renewal_time    1629970373
meta                 map[role:my-role]
num_uses             0
orphan               true
path                 auth/jwt/login
policies             [default my-role]
renewable            true
ttl                  56s
type                 service
$ vault write transit/sign/my-key input="$(echo stuff | base64)"
Key            Value
---            -----
key_version    1
signature      vault:v1:MEUCIFAWmHPyLJ6V0mjMgqr5UnV40bkCEUEGqApcYI54VAPIAiEAqyG2VkFc2wpYs/n47mK4vgfTVbXjWJzMM7Fxr/bR7LE=
$ vault write transit/verify/my-key input="$(echo stuff | base64)" signature=vault:v1:MEUCIFAWmHPyLJ6V0mjMgqr5UnV40bkCEUEGqApcYI54VAPIAiEAqyG2VkFc2wpYs/n47mK4vgfTVbXjWJzMM7Fxr/bR7LE=
```

</details>

<details>
  <summary>zsh</summary>

```zsh
$ export VAULT_ADDR=http://localhost:8200
$ source <(bin/spiffe-vault auth -role my-role)
$ vault kv get secrets/my-key
====== Metadata ======
Key              Value
---              -----
created_time     2021-08-24T08:20:54.925866504Z
deletion_time    n/a
destroyed        false
version          1

============= Data =============
Key                       Value
---                       -----
username                  marco
password                  Supers3cr3t!
$ vault token lookup
Key                 Value
---                 -----
accessor            rwpXIHXzbVIMN2TL25Lfssef
creation_time       1629970184
creation_ttl        1m
display_name        jwt-spiffe://dev.localhost/ns/my-app/sa/my-app-backend
entity_id           8904661e-5a9f-3af5-c269-257e8a0a31d0
expire_time         2021-08-26T09:30:44.424072877Z
explicit_max_ttl    0s
id                  s.eOdhqe1hVV0OPS7M0TSeEqjG
issue_time          2021-08-26T09:29:44.424078028Z
meta                map[role:my-role]
num_uses            0
orphan              true
path                auth/jwt/login
policies            [default my-role]
renewable           true
ttl                 13s
type                service
$ vault token renew
Key                  Value
---                  -----
token                s.f1mFvr0TdEuvmfcZT0jBLCc5
token_accessor       vxginlb81XMEIPefLpRz1P24
token_duration       1m
token_renewable      true
token_policies       ["default" "my-role"]
identity_policies    []
policies             ["default" "my-role"]
token_meta_role      my-role
$ vault token lookup
Key                  Value
---                  -----
accessor             vxginlb81XMEIPefLpRz1P24
creation_time        1629970320
creation_ttl         1m
display_name         jwt-spiffe://dev.localhost/ns/my-app/sa/my-app-backend
entity_id            8904661e-5a9f-3af5-c269-257e8a0a31d0
expire_time          2021-08-26T09:33:53.57444787Z
explicit_max_ttl     0s
id                   s.f1mFvr0TdEuvmfcZT0jBLCc5
issue_time           2021-08-26T09:32:00.135787193Z
last_renewal         2021-08-26T09:32:53.574447972Z
last_renewal_time    1629970373
meta                 map[role:my-role]
num_uses             0
orphan               true
path                 auth/jwt/login
policies             [default my-role]
renewable            true
ttl                  56s
type                 service
$ vault write transit/sign/my-key input="$(echo stuff | base64)"
Key            Value
---            -----
key_version    1
signature      vault:v1:MEUCIFAWmHPyLJ6V0mjMgqr5UnV40bkCEUEGqApcYI54VAPIAiEAqyG2VkFc2wpYs/n47mK4vgfTVbXjWJzMM7Fxr/bR7LE=
$ vault write transit/verify/my-key input="$(echo stuff | base64)" signature=vault:v1:MEUCIFAWmHPyLJ6V0mjMgqr5UnV40bkCEUEGqApcYI54VAPIAiEAqyG2VkFc2wpYs/n47mK4vgfTVbXjWJzMM7Fxr/bR7LE=
```

</details>

See the [example](example) directory for an example infrastructure setup on Kubernetes integration the whole eco-system. This includes a Spire, Vault deployment as well utilizing `spiffe-vault` as en example workload.


Spiffe-Vault

SPIRE (the SPIFFE Runtime Environment) is a toolchain of APIs for establishing trust between software systems across a wide variety of hosting platforms

![SPIRE Logo](/doc/images/spire_logo.png)

[![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/3303/badge)](https://bestpractices.coreinfrastructure.org/projects/3303)
[![Build Status](https://github.com/spiffe/spire/actions/workflows/pr_build.yaml/badge.svg)](https://github.com/spiffe/spire/actions/workflows/pr_build.yaml)
[![Go Report Card](https://goreportcard.com/badge/github.com/spiffe/spire)](https://goreportcard.com/report/github.com/spiffe/spire)
[![Production Phase](https://img.shields.io/badge/SPIFFE-Prod-green.svg?logoWidth=18&logo=data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHJvbGU9ImltZyIgdmlld0JveD0iMC4xMSAxLjg2IDM1OC4yOCAzNTguMjgiPjxzdHlsZT5zdmcge2VuYWJsZS1iYWNrZ3JvdW5kOm5ldyAwIDAgMzYwIDM2MH08L3N0eWxlPjxzdHlsZT4uc3QyLC5zdDN7ZmlsbC1ydWxlOmV2ZW5vZGQ7Y2xpcC1ydWxlOmV2ZW5vZGQ7ZmlsbDojYmNkOTE4fS5zdDN7ZmlsbDojMDRiZGQ5fTwvc3R5bGU+PGcgaWQ9IkxPR08iPjxwYXRoIGQ9Ik0xMi4xIDguOWgyOC4zYzIuNyAwIDUgMi4yIDUgNXYyOC4zYzAgMi43LTIuMiA1LTUgNUgxMi4xYy0yLjcgMC01LTIuMi01LTVWMTMuOWMuMS0yLjcgMi4zLTUgNS01eiIgY2xhc3M9InN0MiIvPjxwYXRoIGQ9Ik04OC43IDguOWgyNThjMi43IDAgNSAyLjIgNSA1djI4LjNjMCAyLjctMi4yIDUtNSA1aC0yNThjLTIuNyAwLTUtMi4yLTUtNVYxMy45YzAtMi43IDIuMi01IDUtNXoiIGNsYXNzPSJzdDMiLz48cGF0aCBkPSJNMzQ2LjcgODUuNWgtMjguM2MtMi43IDAtNSAyLjItNSA1djI4LjNjMCAyLjggMi4yIDUgNSA1aDI4LjNjMi43IDAgNS0yLjIgNS01VjkwLjVjMC0yLjgtMi4zLTUtNS01eiIgY2xhc3M9InN0MiIvPjxwYXRoIGQ9Ik0xOTMuNiA4NS41SDEyLjFjLTIuNyAwLTUgMi4zLTUgNXYyOC4zYzAgMi43IDIuMiA1IDUgNWgxODEuNWMyLjcgMCA1LTIuMiA1LTVWOTAuNWMwLTIuOC0yLjItNS01LTV6IiBjbGFzcz0ic3QzIi8+PHBhdGggZD0iTTI3MC4yIDg1LjVoLTI4LjNjLTIuNyAwLTUgMi4yLTUgNXYyOC4zYzAgMi44IDIuMiA1IDUgNWgyOC4zYzIuNyAwIDUtMi4yIDUtNVY5MC41Yy0uMS0yLjgtMi4zLTUtNS01eiIgY2xhc3M9InN0MiIvPjxwYXRoIGQ9Ik0yNzAuMiAxNjJIODguN2MtMi43IDAtNSAyLjItNSA1djI4LjNjMCAyLjcgMi4yIDUgNSA1aDE4MS41YzIuNyAwIDUtMi4yIDUtNVYxNjdjLS4xLTIuOC0yLjMtNS01LTV6IiBjbGFzcz0ic3QzIi8+PHBhdGggZD0iTTM0Ni43IDE2MmgtMjguM2MtMi43IDAtNSAyLjItNSA1djI4LjNjMCAyLjggMi4yIDUgNSA1aDI4LjNjMi43IDAgNS0yLjIgNS01VjE2N2MwLTIuOC0yLjMtNS01LTV6bS0zMDYuMyAwSDEyLjFjLTIuNyAwLTUgMi4yLTUgNXYyOC4zYzAgMi44IDIuMiA1IDUgNWgyOC4zYzIuNyAwIDUtMi4yIDUtNVYxNjdjMC0yLjgtMi4yLTUtNS01em0tMjguMyA3Ni41aDI4LjNjMi43IDAgNSAyLjIgNSA1djI4LjNjMCAyLjctMi4yIDUtNSA1SDEyLjFjLTIuNyAwLTUtMi4yLTUtNXYtMjguM2MuMS0yLjcgMi4zLTUgNS01eiIgY2xhc3M9InN0MiIvPjxwYXRoIGQ9Ik0xNjUuMiAyMzguNWgxODEuNWMyLjcgMCA1IDIuMiA1IDV2MjguM2MwIDIuNy0yLjIgNS01IDVIMTY1LjJjLTIuNyAwLTUtMi4yLTUtNXYtMjguM2MwLTIuNyAyLjItNSA1LTV6IiBjbGFzcz0ic3QzIi8+PHBhdGggZD0iTTg4LjcgMjM4LjVIMTE3YzIuNyAwIDUgMi4yIDUgNXYyOC4zYzAgMi43LTIuMiA1LTUgNUg4OC43Yy0yLjcgMC01LTIuMi01LTV2LTI4LjNjMC0yLjcgMi4yLTUgNS01em0yNTggNzYuN2gtMjguM2MtMi43IDAtNSAyLjItNSA1djI4LjNjMCAyLjggMi4yIDUgNSA1aDI4LjNjMi43IDAgNS0yLjIgNS01di0yOC4zYzAtMi44LTIuMy01LTUtNXoiIGNsYXNzPSJzdDIiLz48cGF0aCBkPSJNMjcwLjIgMzE1LjJoLTI1OGMtMi43IDAtNSAyLjItNSA1djI4LjNjMCAyLjcgMi4yIDUgNSA1aDI1OGMyLjcgMCA1LTIuMiA1LTV2LTI4LjNjLS4xLTIuOC0yLjMtNS01LTV6IiBjbGFzcz0ic3QzIi8+PC9nPjwvc3ZnPg==)](https://github.com/spiffe/spiffe/blob/main/MATURITY.md#production)

SPIRE (the [SPIFFE](https://github.com/spiffe/spiffe) Runtime Environment) is a toolchain of APIs for establishing trust between software systems across a wide variety of hosting platforms. SPIRE exposes the [SPIFFE Workload API](https://github.com/spiffe/go-spiffe/blob/main/proto/spiffe/workload/workload.proto), which can attest running software systems and issue [SPIFFE IDs](https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE-ID.md) and [SVID](https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE-ID.md)s to them.  This in turn allows two workloads to establish trust between each other, for example by establishing an mTLS connection or by signing and verifying a JWT token. SPIRE can also enable workloads to securely authenticate to a secret store, a database, or a cloud provider service.

- [Get SPIRE](#get-spire)
- [Learn about SPIRE](#learn-about-spire)
- [Integrate with SPIRE](#integrate-with-spire)
- [Contribute to SPIRE](#contribute-to-spire)
- [Further Reading](#further-reading)
- [Security](#security)

SPIRE is a [graduated](https://www.cncf.io/projects/spire/) project of the [Cloud Native Computing Foundation](https://cncf.io) (CNCF). If you are an organization that wants to help shape the evolution of technologies that are container-packaged, dynamically-scheduled and microservices-oriented, consider joining the CNCF.

## Get SPIRE

- Pre-built releases of SPIRE can be found at [https://github.com/spiffe/spire/releases](https://github.com/spiffe/spire/releases). These releases contain both SPIRE Server and SPIRE Agent binaries.
- Container images are published for [spire-server](https://ghcr.io/spiffe/spire-server), [spire-agent](https://ghcr.io/spiffe/spire-agent), and [oidc-discovery-provider](https://ghcr.io/spiffe/oidc-discovery-provider).
- Alternatively, you can [build SPIRE from source](/CONTRIBUTING.md).

## Learn about SPIRE

- Before trying SPIRE, it's a good idea to learn about its [architecture](https://spiffe.io/spire/) and design goals.
- Once ready to get started, see the [Quickstart Guides](https://spiffe.io/spire/try/) for Kubernetes, Linux, and MacOS.
- There are several examples demonstrating SPIRE usage in the [spire-examples](https://github.com/spiffe/spire-examples) and [spire-tutorials](https://github.com/spiffe/spire-tutorials) repositories.
- Check [ADOPTERS.md](./ADOPTERS.md) for a list of production SPIRE adopters, a view of the ecosystem, and use cases.
- See the [SPIRE Roadmap](/ROADMAP.md) for a list of planned features and enhancements.
- [Join](https://slack.spiffe.io/) the SPIFFE community on Slack. If you have any questions about how SPIRE works, or how to get it up and running, the best places to ask questions are the [SPIFFE Slack channels](https://spiffe.slack.com).
- Download the free book about SPIFFE and SPIRE, "[Solving the Bottom Turtle](https://spiffe.io/book/)."

## Integrate with SPIRE

- See [Extend SPIRE](https://spiffe.io/spire/docs/extending/) to learn about the highly extensible SPIRE plugin framework.
- Officially maintained client libraries for interacting with the [SPIFFE Workload API](https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE_Workload_API.md) are available in [Go](https://github.com/spiffe/go-spiffe/tree/main) and [Java](https://github.com/spiffe/java-spiffe). See [SPIFFE Library Usage Examples](https://spiffe.io/spire/try/spiffe-library-usage-examples/) for a full list of official and community libraries, as well as code samples.
- SPIRE provides an implementation of the [Envoy](https://envoyproxy.io) [Secret Discovery Service](https://www.envoyproxy.io/docs/envoy/latest/configuration/security/secret) (SDS) for use with [Envoy Proxy](https://envoyproxy.io).  SDS can be used to transparently install and rotate TLS certificates and trust bundles in Envoy. See [Using SPIRE with Envoy](https://spiffe.io/spire/docs/envoy/) for more information.

For supported integration versions, see [Supported Integrations](/doc/supported_integrations.md).

## Contribute to SPIRE

The SPIFFE community maintains the SPIRE project. Information on the various SIGs and relevant standards can be found in
<https://github.com/spiffe/spiffe>.

- See [CONTRIBUTING](https://github.com/spiffe/spire/blob/main/CONTRIBUTING.md) to get started.
- Use [GitHub Issues](https://github.com/spiffe/spire/issues) to request features or file bugs.
- See [GOVERNANCE](https://github.com/spiffe/spiffe/blob/main/GOVERNANCE.md) for SPIFFE and SPIRE governance policies.

## Further Reading

- The [Scaling SPIRE guide](/doc/scaling_spire.md) covers design guidelines, recommendations, and deployment models.
- For an explanation of how SPIRE compares to related systems such as secret stores, identity providers, authorization policy engines and service meshes see [comparisons](https://spiffe.io/spire/comparisons/).

## Security

### Security Assessments

A third party security firm ([Cure53](https://cure53.de/)) completed a security audit of SPIFFE and SPIRE in February of 2021. Additionally, the [CNCF Technical Advisory Group for Security](https://github.com/cncf/tag-security) conducted two assessments on SPIFFE and SPIRE in 2018 and 2020. Please find the reports and supporting material, including the threat model exercise results, below.

- [Cure53 Security Audit Report](doc/cure53-report.pdf)
- [SIG-Security SPIFFE/SPIRE Security Assessment: summary](https://github.com/cncf/sig-security/tree/main/community/assessments/projects/spiffe-spire)
- [SIG-Security SPIFFE/SPIRE Security Assessment: full assessment](https://github.com/cncf/sig-security/blob/main/community/assessments/projects/spiffe-spire/self-assessment.md)
- [Scrutinizing SPIRE to Sensibly Strengthen SPIFFE Security](https://blog.spiffe.io/scrutinizing-spire-security-9c82ba542019)

### Reporting Security Vulnerabilities

If you've found a vulnerability or a potential vulnerability in SPIRE please let us know at <security@spiffe.io>. We'll send a confirmation email to acknowledge your report, and we'll send an additional email when we've identified the issue positively or negatively.

Spire

Container Signing, Verification and Storage in an OCI registry

Cosign

Go implementation of the in-toto (provides a framework to protect the integrity of the software supply chain) python reference implementation

# Go implementation of in-toto
[![build](https://github.com/in-toto/in-toto-golang/workflows/build/badge.svg)](https://github.com/in-toto/in-toto-golang/actions?query=workflow%3Abuild) [![Coverage Status](https://coveralls.io/repos/github/in-toto/in-toto-golang/badge.svg)](https://coveralls.io/github/in-toto/in-toto-golang) [![PkgGoDev](https://pkg.go.dev/badge/github.com/in-toto/in-toto-golang)](https://pkg.go.dev/github.com/in-toto/in-toto-golang) [![Go Report Card](https://goreportcard.com/badge/github.com/in-toto/in-toto-golang)](https://goreportcard.com/report/github.com/in-toto/in-toto-golang)
[![OpenSSF Scorecard](https://api.securityscorecards.dev/projects/github.com/in-toto/in-toto-golang/badge)](https://api.securityscorecards.dev/projects/github.com/in-toto/in-toto-golang)

Go implementation of the
[in-toto specification](https://github.com/in-toto/docs/blob/master/in-toto-spec.md).

## Docs

To read the documentation along with some examples, run:

```bash
godoc -http :8080
```

and navigate to `localhost:8080/pkg/github.com/in-toto/in-toto-golang/`

Alternatively, you can use [pkg.go.dev](https://pkg.go.dev/github.com/in-toto/in-toto-golang).

## Example

A very simple example, just to help you starting:

```go
package main

import (
	"time"
	toto "github.com/in-toto/in-toto-golang/in_toto"
)

func main() {
	t := time.Now()
	t = t.Add(30 * 24 * time.Hour)

	var keys = make(map[string]toto.Key)

	var metablock = toto.Metablock{
		Signed: toto.Layout{
			Type: "layout",
			Expires:  t.Format("2006-01-02T15:04:05Z"),
			Steps: []toto.Step{},
			Inspect: []toto.Inspection{},
			Keys:  keys,
		},
	}

	var key toto.Key

	key.LoadKey("keys/alice", "rsassa-pss-sha256", []string{"sha256", "sha512"})

	metablock.Sign(key)

	metablock.Dump("root.layout")
}
```

## Building

Download the source, run `make build`.

## CLI

The CLI reference can be found in the autogenerated [docs](doc/in-toto.md).

## Integration with SPIFFE/SPIRE

This implementation of in-toto has been integrated with SPIFFE/SPIRE. The
integration is made possible by
[ITE-7](https://github.com/in-toto/ITE/blob/master/ITE/7/README.adoc), an
enhancement that adds support for X.509 signing to in-toto.

### Running the Demo

To run the demo, pull down the source code, install Go, and run
`make test-verify`. This will use openssl to generate a certificate chain.

To run the demo using SPIRE, pull down the source code, install Go and Docker,
and run `make test-spiffe-verify`.

SPIFFE compliant Leaf certificates are generated with SVIDs corresponding to
functionaries. These certificates are consumed by in-toto to sign link metadata
and the layout policy.

During the in-toto verification process, certificate constraints are checked to
ensure the build step link meta-data was signed with the correct SVID.

### Layout Certificate Constraints

Currently the following constraints supported:

```json
{
  "cert_constraints": [{
    "common_name": "write-code.example.com",
      "dns_names": [
        ""
      ],
      "emails": [
        ""
      ],
      "organizations": [
        "*"
      ],
      "roots": [
        "*"
      ],
      "uris": [
        "spiffe://example.com/write-code"
      ]
  }, {
    "uris": [],
    "common_names": ["Some User"]
  }]
}
```

## Not (yet) supported

This golang implementation was focused on verification on admission controllers
and kubectl plugins. As such, it focused on providing a strong, auditable set
of core functions rather than a broad and (possibly) unstable feature set. In
other words, we believe that the current feature set is stable enough for
production use.

If any of these features are necessary for your use case please let us know and
we will try to provide them as soon as possible. Alternatively we welcome pull
requests with feature additions!

* [GPG keys](https://github.com/in-toto/in-toto-golang/issues/26)


The Best Go Libraries For Zero Trust (5)

OpenZiti

Spiffe-Vault

Spire

Cosign

in-toto