[!NOTE] It is advised to familiarize yourself with the terms and concepts used in the OpenTDF platform.
On macOS, these can be installed with brew
brew install buf go
go install github.com/cosmtrek/air@latest
brew install golangci-lint
brew install grpcurl
brew install openssl
There are two primary audiences for this project. Consumers and Contributors
Consuming Consumers of the OpenTDF platform should begin their journey here.
Contributing To contribute to the OpenTDF platform, you'll need bit more set setup and should start here.
The OpenTDF service is the main entry point for the OpenTDF platform. See service documentation for more information.
[!WARNING] This quickstart guide is intended for development and testing purposes only. The OpenTDF platform team does not provide recommendations for production deployments.
To get started with the OpenTDF platform make sure you are running the same Go version found in the go.mod
file.
https://github.com/opentdf/platform/blob/main/service/go.mod#L3
Generate development keys/certs for the platform infrastructure.
./.github/scripts/init-temp-keys.sh
Start the required infrastructure with compose-spec.
# Note this might be `podman compose` on some systems
docker compose -f docker-compose.yaml up
Copy the development configuration file from the example and update it with your own values (if necessary, not common).
cp opentdf-dev.yaml opentdf.yaml
Provision keycloak with the default configuration.
go run ./service provision keycloak
Run the OpenTDF platform service.
go run ./service start
This section is focused on the development of the OpenTDF platform.
Libraries ./lib
are shared libraries that are used across the OpenTDF platform. These libraries are used to provide
common functionality between the various sub-modules of the platform monorepo. Specifically, these libraries are shared
between the services and the SDKs.
Services ./services
are the core building blocks of the OpenTDF platform. Generally, each service is one or more gRPC services that
are scoped to a namespace. The essence of the service is that it takes a modular binary architecture approach enabling
multiple deployment models.
SDKs ./sdk
are the contracts which the platform uses to ensure that developers and services can interact with the
platform. The SDKs contain a native Go SDK and generated Go service SDKs. A full list of SDKs can be found at
github.com/opentdf.
Within this repo, todefine a new, distinct go module,
for example to provide shared functionality between several existing modules,
or to define new and unique functionality
follow these steps.
For this example, we will call our new module lib/foo
.
mkdir -p lib/foo
cd lib/foo
go mod init github.com/opentdf/platform/lib/foo
go work use .
In this folder, create your go code as usual.
A README is recommended to assist with orientation to use of your package. Remember, this will be published to https://pkg.go.dev/ as part of the module documentation.
Make sure to add a LICENSE file to your module to support automated license checks. Feel free to copy the existing (BSD-clear) LICENSE file for most new modules.
Add your module to the MODS
variable:
MODS=protocol/go sdk . examples lib/foo
If required If your project does not generate a built artifact,
add a phony binary target to the .PHONY
declaration.
.PHONY: ...existing phony targets... lib/foo/foo
Add your build target to the build
phony target.
build: ...existing targets... lib/foo/foo
Add your build target and rule
lib/foo/foo: $(shell find lib/foo)
(cd lib/foo && go build ./...)
Add any required COPY
directives to ./Dockerfile
:
COPY lib/foo/ lib/foo/
go.mod
directory to the .github/workflows/checks.yaml
's go
job's matrix.strategry.directory
line.license
job in the checks
workflow as well, especially if you declare any dependencies.vuln-check
and lint
.Common terms used in the OpenTDF platform.
Service is the core service of the OpenTDF platform as well as the sub-services that make up the platform. The main service follows a modular binary architecture, while the sub-services are gRPC services with HTTP gateways.
Policy is the set of rules that govern access to the platform.
OIDC is the OpenID Connect protocol used solely for authentication within the OpenTDF platform.
Attribute Based Access Control (ABAC) is the policy-based access control model used within the OpenTDF platform.
Entities are the main actors within the OpenTDF platform. These include people and systems.
SDKs are the contracts which the platform uses to ensure that developers and services can interact with the platform.