Giter VIP home page Giter VIP logo

helm-charts's Introduction

OpenFGA

Go Reference GitHub release (latest SemVer) Docker Pulls Codecov Go Report CII Best Practices Join our community Twitter FOSSA Status Artifact HUB OpenSSF Scorecard SLSA 3

A high-performance and flexible authorization/permission engine built for developers and inspired by Google Zanzibar.

OpenFGA is designed to make it easy for developers to model their application permissions and add and integrate fine-grained authorization into their applications.

It allows in-memory data storage for quick development, as well as pluggable database modules. It currently supports PostgreSQL 14 and MySQL 8.

It offers an HTTP API and a gRPC API. It has SDKs for Java, Node.js/JavaScript, GoLang, Python and .NET. Look in our Community section for third-party SDKs and tools. It can also be used as a library (see example).

Getting Started

The following section aims to help you get started quickly. Please look at our official documentation for in-depth information.

Setup and Installation

ℹī¸ The following sections setup an OpenFGA server using the default configuration values. These are for rapid development and not for a production environment. Data written to an OpenFGA instance using the default configuration with the memory storage engine will not persist after the service is stopped.

For more information on how to configure the OpenFGA server, please take a look at our official documentation on Running in Production.

Docker

OpenFGA is available on Dockerhub, so you can quickly start it using the in-memory datastore by running the following commands:

docker pull openfga/openfga
docker run -p 8080:8080 -p 3000:3000 openfga/openfga run

Tip

The OPENFGA_HTTP_ADDR environment variable can used to configure the address at which the playground expects the OpenFGA server to be. For example, docker run -e OPENFGA_PLAYGROUND_ENABLED=true -e OPENFGA_HTTP_ADDR=0.0.0.0:4000 -p 4000:4000 -p 3000:3000 openfga/openfga run will start the OpenFGA server on port 4000, and configure the playground too.

Docker Compose

docker-compose.yaml provides an example of how to launch OpenFGA with Postgres using docker compose.

  1. First, either clone this repo or curl the docker-compose.yaml file with the following command:

    curl -LO https://openfga.dev/docker-compose.yaml
  2. Then, run the following command:

    docker compose up

Package Managers

If you are a Homebrew user, you can install OpenFGA with the following command:

brew install openfga

Pre-compiled Binaries

Download your platform's latest release and extract it. Then run the binary with the command:

./openfga run

Building from Source

There are two recommended options for building OpenFGA from source code:

Building from source with go install

Make sure you have Go 1.20 or later installed. See the Go downloads page.

You can install from source using Go modules:

  1. First, make sure $GOBIN is on your shell $PATH:

    export PATH=$PATH:$(go env GOBIN)
  2. Then use the install command:

    go install github.com/openfga/openfga/cmd/openfga
  3. Run the server with:

    ./openfga run

Building from source with go build

Alternatively you can build OpenFGA by cloning the project from this Github repo, and then building it with the go build command:

  1. Clone the repo to a local directory, and navigate to that directory:

    git clone https://github.com/openfga/openfga.git && cd openfga
  2. Then use the build command:

    go build -o ./openfga ./cmd/openfga
  3. Run the server with:

    ./openfga run

Verifying the Installation

Now that you have Set up and Installed OpenFGA, you can test your installation by creating an OpenFGA Store.

curl -X POST 'localhost:8080/stores' \
--header 'Content-Type: application/json' \
--data-raw '{
    "name": "openfga-demo"
}'

If everything is running correctly, you should get a response with information about the newly created store, for example:

{
  "id": "01G3EMTKQRKJ93PFVDA1SJHWD2",
  "name": "openfga-demo",
  "created_at": "2022-05-19T17:11:12.888680Z",
  "updated_at": "2022-05-19T17:11:12.888680Z"
}

Playground

The Playground facilitates rapid development by allowing you to visualize and model your application's authorization model(s) and manage relationship tuples with a locally running OpenFGA instance.

To run OpenFGA with the Playground disabled, provide the --playground-enabled=false flag.

./openfga run --playground-enabled=false

Once OpenFGA is running, by default, the Playground can be accessed at http://localhost:3000/playground.

In the event that a port other than the default port is required, the --playground-port flag can be set to change it. For example,

./openfga run --playground-enabled --playground-port 3001

Profiler (pprof)

Profiling through pprof can be enabled on the OpenFGA server by providing the --profiler-enabled flag.

./openfga run --profiler-enabled

This will start serving profiling data on port 3001. You can see that data by visiting http://localhost:3001/debug/pprof.

If you need to serve the profiler on a different address, you can do so by specifying the --profiler-addr flag. For example,

./openfga run --profiler-enabled --profiler-addr :3002

Once the OpenFGA server is running, in another window you can run the following command to generate a compressed CPU profile:

go tool pprof -proto -seconds 60 http://localhost:3001/debug/pprof/profile
# will collect data for 60 seconds and generate a file like pprof.samples.cpu.001.pb.gz

That file can be analyzed visually by running the following command and then visiting http://localhost:8084:

go tool pprof -http=localhost:8084 pprof.samples.cpu.001.pb.gz

Next Steps

Take a look at examples of how to:

Don't hesitate to browse the official Documentation, API Reference.

Limitations

MySQL Storage engine

The MySQL storage engine has a lower length limit for some properties of a tuple compared with other storage backends. For more information see the docs.

OpenFGA's MySQL Storage Adapter was contributed to OpenFGA by @twintag. Thanks!

Production Readiness

The core OpenFGA service has been in use by Okta FGA in production since December 2021.

OpenFGA's Memory Storage Adapter was built for development purposes only and is not recommended for a production environment, because it is not designed for scalable queries and has no support for persistence.

You can learn about more organizations using OpenFGA in production here. If your organization is using OpenFGA in production please consider adding it to the list.

The OpenFGA team will do its best to address all production issues with high priority.

Contributing

See CONTRIBUTING.

Community Meetings

We hold a monthly meeting to interact with the community, collaborate and receive/provide feedback. You can find more details, including the time, our agenda, and the meeting minutes here.

helm-charts's People

Contributors

aaguiarz avatar aaronschweig avatar adamstrawson avatar adriantam avatar alee792 avatar almeynman avatar baurmatt avatar booniepepper avatar dependabot[bot] avatar jakereps avatar jliedy avatar jon-whit avatar jpadilla avatar karaimin avatar marlenekoh avatar miparnisari avatar nkreiger avatar pedroarvela avatar rhamzeh avatar willvedd avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

helm-charts's Issues

Migration job and deployment use the same service account

While the migration job probably needs schema update permissions, it seems like the OpenFGA deployment would only need data select, insert, update and delete permissions.

We'd like to be able to use separate ServiceAccounts and database URIs for the migration job and the deployment; we're using AWS with IAM RDS authentication (Postgres), so we'd want to be able to set PGPASSFILE and define the ServiceAccount externally to line up with the assumed IAM role.

Release charts workflow is failing

Recent commits merged to main are failing. For example: https://github.com/openfga/helm-charts/actions/runs/6741732905/job/18326738225

Successfully packaged chart in /home/runner/work/helm-charts/helm-charts/charts/openfga and saved it to: .cr-release-packages/openfga-0.1.30.tgz
Releasing charts...
Using config file:  .github/cr.yaml
Error: error creating GitHub release openfga-0.1.30: POST https://api.github.com/repos/openfga/helm-charts/releases: 422 Validation Failed [{Resource:Release Field:tag_name Code:already_exists Message:}]

Allow migration job setup without requiring embedded database

Sometimes our PostgreSQL instance is already provided, we do not need to enable the sub-chart in this case. Unfortunately that disables the migration job and the init container that waits for the job to finish.

Currently we literally recreate the job and init container as it is in the chart. It would be great if we could just enable the migration for a database that already exists.

Playground Not Disabled When Setting playground.enabled: false

I am trying to install OpenFGA on my kubernetes cluster, having oidc as my authentication method.

My values file snippet is as follows:

...
authn:
  method: oidc
  oidc:
    audience: xxxxx
    issuer: https://login.microsoftonline.com/xxxxxx/v2.0

playground:
  enabled: false
...

I am receiving this error message from the container logs
panic: the playground only supports authn methods 'none' and 'preshared'

I suppose what is going on in the background is that the flag for disabling the playground is not propagated, and instead it picks up the default enabled flag.

Any help would be appreciated.

Chart bools rendered into environment values need to be stringified

When setting an enabled boolean (grpc.tls.enabled) that is forwarded to an environment variable Helm fails to render the chart. The chart requires a boolean for these but the spec for environment variables requires all the keys/values to be strings.

There may be others, but the variables I had issues with are:

  • grpc.tls.enabled
  • http.tls.enabled

wait-for-migration initContainer does not abide by securityContext

{{- if and (has .Values.datastore.engine (list "postgres" "mysql")) .Values.datastore.applyMigrations }}
initContainers:
- name: wait-for-migration
image: groundnuty/k8s-wait-for:v1.6
args: ["job", '{{ include "openfga.fullname" . }}-migrate']
{{- end }}

The wait-for-migration container does not use the securityContext from the Helm values, which means a PodSecurityContext with runAsNonRoot: true will always fail.

allow pulling datastore uri from kubernetes secret

For postgres or mysql datastore, chart needs full db uri along with username and password. Considering gitOps we would not want to expose DB password in the git repo.

There should be a provision to reference datastore uri from a kubernets secret. Something like

replicaCount: 3
datastore: 
  engine: postgres
  refUriSecret: openfga-db-secret 

openfga-db-secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: openfga-db-secret
  namespace: openfga
type: Opaque
data:
  OPENFGA_DATASTORE_URI: dGVzdA==

Allow configuration of additional ingresses for gRPC

The current templates only allow for a single ingress keyed off of service.port, which defaults to the HTTP server. Practically, this means that ingress cannot be enabled for both HTTP and gRPC. The templates could be modified to create multiple ingress objects, and potentially allow for the injection of different backends for different rules.

Generate release notes in GitHub releases or CHANGELOG

Currently there is no easy way to determine what each release of the chart has changed.

GitHub should be able to autogenerate the release notes from PRs and issues; even when using automated releases.

Alternatively, a CHANGELOG would at least provide a way to track changes (although more manually).

How to configure some of the newer OpenFGA env variables using this Helm chart?

OpenFGA released a few new ENV Variables in the latest releases, for example OPENFGA_MAX_CONCURRENT_READS_FOR_LIST_OBJECTS or OPENFGA_CHECK_QUERY_CACHE_ENABLED.

This helm chart allows to pull never versions of OpenFGA by setting the image.tag=.... However, I couldn't find a way how to set the newer env variables (I ended up using kubectl to manually set it on the deployment as a temporary workaround).

Would it make sense to introduce a new Helm value that allows setting any env variable in the OpenFGA containers? This would help a lot when one is experimenting with newer features that are not yet integrated into the Helm chart. Or would it be possible to release new Helm chart versions alongside new OpenFGA versions?

feat: add tls support to openfga chart

The openfga chart does not yet officially support TLS. If a developer wants to helm install the chart with TLS support, there isn't a good way to bootstrap the TLS certs for the chart install.

We may be able to add support by using the native functions built into Helm:
https://helm.sh/docs/chart_template_guide/function_list/#gensignedcert
https://helm.sh/docs/chart_template_guide/function_list/#genca

or we could add a chat dependency on cert-manager, which is a great tool to manage certifications and is widely used across the CNCF landscape.

Following readme instructions won't launch OpenFGA pods successfully

I just followed the readme instructions on installing OpenFGA with Postgres.
https://github.com/openfga/helm-charts/blob/main/charts/openfga/README.md

helm install openfga openfga/openfga
--set datastore.engine=postgres
--set datastore.uri="postgres://postgres:[email protected]:5432/postgres?sslmode=disable"
--set postgres.enabled=true
--set postgresql.auth.postgresPassword=password
--set postgresql.auth.database=postgres

The OpenFGA pods will never be launched correctly:
openfga-6b576ddc7f-4b4fc 0/1 CrashLoopBackOff 5 (47s ago) 8m59s
openfga-6b576ddc7f-7vvl6 0/1 CrashLoopBackOff 5 (82s ago) 8m59s
openfga-6b576ddc7f-8nq92 0/1 CrashLoopBackOff 5 (85s ago) 8m59s

Is the Helm Chart well maintained? I also encountered issues in other scenarios/cases. Appreciate any guidance!

[openfga] Allow specifying custom annotations in all manifests

There are several use cases where custom annotations are required. For example, we are currently adding automatic database credential rotation in our deploy using Reloader, as well as scraping only some (but not all) of the Prometheus metrics using Datadog. Both of these require custom annotations both in the deployments and pods of the release.

Currently, only ingresses and pods support custom annotations. Instead of adding support for each specific annotation that might be useful, the proposal is to add support for defining annotations that can be added to all resources or to the pods specifically, allowing any of these use cases to be solved the same way.

OpenFGA returns unexpected errors randomly

I am using OpenFGA's HTTP API to perform authorization checks. I encounter a weird issue: some authorization check(s) may "randomly" receive error responses, instead of "true" or "false". This could happen in all of the following three scenarios:

  • Scenario 1: Use OpenFGA along with the integrated Postgres database that is launched with the official Helm chart. The OpenFGA server along with the integrated Postgres database server is launched as follows:
helm install openfga openfga/openfga \
--set datastore.engine=postgres \
--set datastore.uri="postgres://postgres:[email protected]:5432/postgres?sslmode=disable" \
--set postgres.enabled=true \
--set postgresql.auth.postgresPassword=password \
--set postgresql.auth.database=postgres

The error responses are quite random. Sometimes, I get 1; sometimes I get 3; sometimes, I don't get any error response!! The error message is as follows:

{
  "code": "deadline_exceeded",
  "message": "context deadline exceeded"
}

Also, it seems that having replicaCount=1 makes the issue almost impossible to happen. Having replicaCount=3 (the default value) or replicaCount=5 makes the issue more likely to happen.

  • Scenario 2: Use OpenFGA with an independent Postgres database. The independent Postgres database server is launched as follows:
helm install dlpostgres \
    	--set auth.postgresPassword=password \
    	oci://registry-1.docker.io/bitnamicharts/postgresql

The OpenFGA server is launched as follows, using the official Helm chart:

helm install openfga openfga/openfga \
  		--set replicaCount=1 \
		--set log.level=error \
  		--set datastore.engine=postgres \
  		--set datastore.uri="postgres://postgres:[email protected]:5432/postgres?sslmode=disable"

In general, in Scenario 2, the issue is more likely to happen compared to Scenario 1. Even with replicaCount=1, it is still very possible for the issue to happen. Usually, 3 or 5 out of 5000 authorization checks may receive error responses.

  • Scenario 3: Use OpenFGA along with Azure Postgres database server. I created the Azure Postgres database server first, and then launch the OpenFGA server using the official Helm chart as follows:
helm install openfga openfga/openfga \
  		--set replicaCount=1 \
		--set log.level=error \
  		--set datastore.engine=postgres \
  		--set datastore.uri="CONNECTION_STRING_FROM_AZURE_POSTGRES_DATABASE_SERVER"

The issue is even more likely to happen compared to Scenario 1 and Scenario 2. About 100 or even more checks will receive error responses, compared to just a couple in Scenario 1 or 2.

Note that I was using the same model and data for the testings in all scenarios. The authorization checks that receive error responses are different in different runs. Thus, I don't think it's the issue with my model or data.

Besides, when I use an unofficial OpenFGA Helm chart here:
https://github.com/AlexandreBrg/openfga-helm
to do testings in Scenario 2 and Scenario 3, I never have the same issue. I.e., the unofficial OpenFGA Helm chart works correctly all the time!
Could someone help look into this issue?

Upgrading openfga helm chart ends in failure due to migration job

After installing openfga, running helm upgrade fails due to the chart template trying to update a job.

Error: UPGRADE FAILED: cannot patch "openfga-migrate" with kind Job: Job.batch "openfga-migrate" is invalid: [spec.template.metadata.labels[controller-uid]: Required value: must be 'redacted', spec.template.metadata.labels[job-name]: Required value: must be 'openfga-migrate', spec.template.metadata.labels: Invalid value: map[string]string(nil): `selector` does not match template `labels`, spec.template: Invalid value: core.PodTemplateSpec{ObjectMeta:v1.ObjectMeta{Name:"", GenerateName:"", Namespace:"", SelfLink:"", UID:"", ResourceVersion:"", Generation:0, CreationTimestamp:time.Date(1, time.January, 1, 0, 0, 0, 0, time.UTC), DeletionTimestamp:<nil>, DeletionGracePeriodSeconds:(*int64)(nil), Labels:map[string]string(nil), Annotations:map[string]string(nil), OwnerReferences:[]v1.OwnerReference(nil), Finalizers:[]string(nil), ManagedFields:[]v1.ManagedFieldsEntry(nil)}, Spec:core.PodSpec{Volumes:[]core.Volume(nil), InitContainers:[]core.Container(nil), Containers:[]core.Container{core.Container{Name:"migrate-database", Image:"openfga/openfga:v1.3.1", Command:[]string(nil), Args:[]string{"migrate"}, WorkingDir:"", Ports:[]core.ContainerPort(nil), EnvFrom:[]core.EnvFromSource(nil), Env:[]core.EnvVar{core.EnvVar{Name:"OPENFGA_DATASTORE_ENGINE", Value:"postgres", ValueFrom:(*core.EnvVarSource)(nil)}, core.EnvVar{Name:"OPENFGA_DATASTORE_URI", Value:"redacted", ValueFrom:(*core.EnvVarSource)(nil)}}, Resources:core.ResourceRequirements{Limits:core.ResourceList(nil), Requests:core.ResourceList(nil)}, VolumeMounts:[]core.VolumeMount(nil), VolumeDevices:[]core.VolumeDevice(nil), LivenessProbe:(*core.Probe)(nil), ReadinessProbe:(*core.Probe)(nil), StartupProbe:(*core.Probe)(nil), Lifecycle:(*core.Lifecycle)(nil), TerminationMessagePath:"/dev/termination-log", TerminationMessagePolicy:"File", ImagePullPolicy:"IfNotPresent", SecurityContext:(*core.SecurityContext)(0xc0b2d8d9e0), Stdin:false, StdinOnce:false, TTY:false}}, EphemeralContainers:[]core.EphemeralContainer(nil), RestartPolicy:"Never", TerminationGracePeriodSeconds:(*int64)(0xc06db168c8), ActiveDeadlineSeconds:(*int64)(nil), DNSPolicy:"ClusterFirst", NodeSelector:map[string]string(nil), ServiceAccountName:"openfga", AutomountServiceAccountToken:(*bool)(nil), NodeName:"", SecurityContext:(*core.PodSecurityContext)(0xc08afaddd0), ImagePullSecrets:[]core.LocalObjectReference(nil), Hostname:"", Subdomain:"", SetHostnameAsFQDN:(*bool)(nil), Affinity:(*core.Affinity)(nil), SchedulerName:"default-scheduler", Tolerations:[]core.Toleration(nil), HostAliases:[]core.HostAlias(nil), PriorityClassName:"", Priority:(*int32)(nil), PreemptionPolicy:(*core.PreemptionPolicy)(nil), DNSConfig:(*core.PodDNSConfig)(nil), ReadinessGates:[]core.PodReadinessGate(nil), RuntimeClassName:(*string)(nil), Overhead:core.ResourceList(nil), EnableServiceLinks:(*bool)(nil), TopologySpreadConstraints:[]core.TopologySpreadConstraint(nil), OS:(*core.PodOS)(nil)}}: field is immutable]

As far as I'm aware, jobs like this are immutable. You can use hooks to have a job delete itself after a successful run: https://helm.sh/docs/topics/charts_hooks/

I'll have a pull request completed momentarily to have this added.

Cannot define `experimentals` in Helm Chart

I noticed this when I tried to use the new experimental feature of v1.3.1.

The Helm chart value schema for experimentals currently defines an array as valid input format. However, the deployment.yaml does not convert the array into a string as it would be required for env variables.

This results in Helm errors:
Error in helm: decoding Deployment "openfga": json: cannot unmarshal array into Go struct field EnvVar.spec.template.spec.containers.env.value of type string

I think it should be used like this instead:
value: "{{ join "," .Values.experimentals }}"

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤ī¸ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.