diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index b7b84b29..db53107c 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -4,31 +4,7 @@ on: - pull_request jobs: - format: - runs-on: ubuntu-latest - permissions: - contents: write - - steps: - - uses: actions/checkout@v3 - - - name: Setup Node.js - uses: actions/setup-node@v3 - with: - cache: yarn - - - name: Install Dependencies - run: yarn --frozen-lockfile - - - name: Format - run: yarn format - - - uses: stefanzweifel/git-auto-commit-action@v4 - with: - commit_message: "chore: format code" - lint: - needs: format runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 diff --git a/.vale/styles/Flipt/spelling-exceptions.txt b/.vale/styles/Flipt/spelling-exceptions.txt index eea16814..4aade6b9 100644 --- a/.vale/styles/Flipt/spelling-exceptions.txt +++ b/.vale/styles/Flipt/spelling-exceptions.txt @@ -50,6 +50,7 @@ oci oidc okta onboarding +OPA's otlp passwordless performant @@ -64,6 +65,7 @@ protoc Quicksort redis regexes +rego reverst rollout rollouts @@ -74,6 +76,7 @@ sdks semver Splunk sqlite +toolset tracecontext Turso unary diff --git a/authentication/overview.mdx b/authentication/overview.mdx index 402fcf97..266b16f6 100644 --- a/authentication/overview.mdx +++ b/authentication/overview.mdx @@ -3,16 +3,16 @@ title: Overview description: This document describes how to enable and use authentication with Flipt. --- -Flipt supports the ability to secure its core API routes. +Flipt supports the ability to secure its core API routes with authentication. Flipt authentication is **disabled** (not required) by default. -Head to the [Configuration: Authentication](/configuration/authentication) section to enable it. +Head to the [Configuration: Authentication](/configuration/authentication) section to learn how to enable it. -Once enabled, all routes beneath the following API prefixes will require a [client token](#client-tokens) to authenticate requests: +Once enabled, all routes beneath the following API prefixes will require a [client token](#client-tokens) or [JWT](#json-web-tokens) to authenticate requests: - `/api/v1/` - `/auth/v1/` @@ -27,6 +27,7 @@ The following URLs aren't protected by authentication: - `/health` They're currently unprotected to support backward compatibility. + We're exploring ways to support protecting these endpoints going forward. For now, we recommend excluding these API prefixes from your load-balancer. @@ -34,7 +35,8 @@ For now, we recommend excluding these API prefixes from your load-balancer. Apart from `/auth/v1/` itself, the rest of the top-level API prefixes can be optionally excluded from authentication. Allowing for sections, such as the evaluations API, to be publicly accessible while still protecting the management and metadata APIs. -Checkout the [Configuration: Authentication Exclusions](/configuration/authentication#exclusions) documentation for details. + +See the [Configuration: Authentication Exclusions](/configuration/authentication#exclusions) documentation for details. ## Client Tokens @@ -57,10 +59,3 @@ Flipt can also authenticate requests using externally created and signed [JSON W To enable JWT authentication, you will need to configure Flipt with the public key used to verify the JWT signature. See the [Configuration: JWT Authentication](/configuration/authentication#json-web-token) documentation for details. - -## Authorization - -Currently, Flipt only supports authentication without any extended authorization capabilities. -Authorization is something we're actively exploring and we will update this section as we settle on a design. - -We would appreciate your input into designing authorization. Head over to [our Discord](https://flipt.io/discord) and let us know what you need from Flipt. diff --git a/authorization/overview.mdx b/authorization/overview.mdx new file mode 100644 index 00000000..972cbc88 --- /dev/null +++ b/authorization/overview.mdx @@ -0,0 +1,294 @@ +--- +title: Overview +description: This document describes how to enable and use authorization with Flipt. +--- + +Flipt supports the ability to secure its core API routes with authorization. + + +Flipt authorization is **experimental** and **disabled** (not required) by default. + +To enable authorization, you must set the `experimental.authorization.enabled` configuration option to `true` in your Flipt [configuration file](/configuration/overview#configuration-file). + +See the [experimental](/configuration/experimental) section for more information on how to enable experimental features. + + + +Once enabled, all routes beneath the Management API prefix will require a [policy](#policies) to be evaluated before the request is allowed to proceed. The policy must evaluate to `allowed == true` for the request to be allowed. + +- `/api/v1/` + +## Open Policy Agent (OPA) + +[Open Policy Agent (OPA)](https://www.openpolicyagent.org/) is a general-purpose policy engine that can be used to configure and enforce authorization policies. OPA provides a unified toolset and framework for policy across the cloud native stack. Open Policy Agent is a [CNCF](https://www.cncf.io/) project and is used by many organizations to enforce policies across their cloud-native environments. + +Flipt embeds OPA to evaluate policies that determine whether a request should be allowed or denied. This means that no additional infrastructure or services are required to use OPA with Flipt. + + + Check out our [Role-Based Access Control with Keycloak + guide](/guides/operation/authorization/rbac-with-keycloak) for an example on + how to configure and use role-based access control (RBAC) with Flipt and + Keycloak using OPA. + + +## Policies + +Flipt uses OPA to enforce authorization policies for the Management API. The policies are defined in a `policy.rego` file located in the Flipt configuration directory by default. The path to this file can be customized as described in the [Configuration: Authorization](/configuration/authorization) section. + +Part of the power of OPA is that it's extremely flexible as it allows you to define fine-grained policies tailored to your exact needs. + +Here's an example of a simple policy that checks whether custom claims provided at authentication time include a key `roles` containing a value `admin`: + +```rego policy.rego +package flipt.authz.v1 + +import rego.v1 + +default allow = false + +allow if { + claims := json.unmarshal(input.authentication.metadata["io.flipt.auth.claims"]) + "admin" in claims.roles +} +``` + +You can find more information on how to write Rego policies in the [OPA documentation](https://www.openpolicyagent.org/docs/latest/policy-language/). + + + OPA has a rich set of built-in functions that can be used to write complex + policies. They also provide a [Rego + Playground](https://play.openpolicyagent.org/) where you can test your + policies before deploying them. + + +It's up to you to define the policies that make sense for your organization. During policy evaluation, Flipt will pass the incoming request context to OPA, which will then evaluate the policy against that context. + +The context provided to OPA includes the following fields: + +- `input.authentication`: The authentication information for the request. These are specific to each authentication provider/method and can include things like the user's roles, email, etc. +- `input.request`: The incoming request details, such as the `namespace`, `resource`, and `verb`. + +### Authentication Information + +Flipt provides the raw authentication information to OPA for evaluation. This information is specific to the authentication method used to authenticate the request. + +For example, if you're using the [OIDC authentication method](/authentication/methods#openid-connect), the `input.authentication.metadata` field may contain the user's name and email as well as custom claims assigned to the user. + +Here is an example of the `input.authentication.metadata` field for a request authenticated using an example OIDC provider: + +```json +{ + "io.flipt.auth.email": "user@email.com", + "io.flipt.auth.name": "John Doe" + "io.flipt.auth.claims": { + "roles": ["admin", "viewer"] + } +} +``` + + + The `io.flipt.auth.claims` field is a JSON object that contains custom claims + provided by the authentication provider. Each authentication provider may + provide different claims, so it's up to you to map these claims as needed in + your policies. + + +The following fields are available in the `input.authentication` field: + +- `metadata`: A map of authentication metadata provided by the authentication method. This can include the user's email, name, roles, etc. + - `io.flipt.auth.email`: The user's email address. + - `io.flipt.auth.name`: The user's name. + - `io.flipt.auth.claims`: A map of **all** claims provided by the authentication method. This can include the user's roles, groups, etc. These claims are marshaled into a JSON string before being passed to OPA for evaluation. + +#### Mapping Identity + +Each authentication method configurable within Flipt will provide different information depending on the identity. It's up to you to combine identity information (`authentication`) with the requested resource (`request`) to make an authorization decision whether or not the request should be allowed (`allow`). + +Some authentication methods provide user details such as roles directly, while others may provide a user ID or email that you can use to look up roles in your own system. Many authentication providers support adding custom claims to the JWT token, which can be used to provide additional information about the user. + +For example, [Okta](https://www.okta.com/) allows you to add custom claims using their groups feature. An example JWT token with custom claims generated by Okta might look like this: + +```json +{ + "sub": "00uixa271s6x7qt8I0h7", + "ver": 1, + "iss": "https://{yourOktaDomain}", + "aud": "0oaoiuhhch8VRtBnC0h7", + "iat": 1574201516, + "exp": 1574205116, + "jti": "ID.ewMNfSvcpuqyS93OgVeCN3F2LseqROkyYjz7DNb9yhs", + "amr": ["pwd", "mfa", "kba"], + "idp": "00oixa26ycdNcX0VT0h7", + "nonce": "UBGW", + "auth_time": 1574201433, + "groups": ["Everyone", "IT"] +} +``` + +In this example, the `groups` claim is used to provide the user's organizational groups. You can then write a policy that checks for the presence of specific groups to determine whether the user should be allowed to access a particular resource. + +```rego policy.rego +package flipt.authz.v1 + +import rego.v1 + +default allow = false + +allow if { + claims := json.unmarshal(input.authentication.metadata["io.flipt.auth.claims"]) + "IT" in claims.groups +} +``` + + +The Rego builtin [`json.unmarshal`](https://www.openpolicyagent.org/docs/latest/policy-reference/#builtin-encoding-jsonunmarshal) function is used to convert the `groups` claim from a string to a JSON object that can be queried in the policy. + +Flipt encodes the raw authentication claims as a JSON string to pass them to OPA for evaluation. + + + +Further documentation on how to configure custom claims and groups in Okta can be found in the [Okta Developer documentation](https://developer.okta.com/docs/guides/customize-tokens-returned-from-okta/main/). + +Roles or groups are not a requirement for writing policies. You can write policies that check for any information provided by the authentication method, such as the user's email, id, name, etc. + + + Flipt has no notion of users or roles internally, it simply passes the raw + authentication information along with other request metadata to OPA for + evaluation. + + +### Request Information + +The `input.request` field contains information about the incoming request. This includes the `namespace`, `resource`, and `verb` of the request. + +- `namespace`: The [namespace](/concepts#namespaces) in Flipt of the resource being accessed. If no namespace is provided, the default namespace is used, or it is not applicable as the resource is not namespace scoped (e.g. authentication) + +- `resource`: The resource being accessed. This can be one of: + + - `namespace`: Access to [namespace](/concepts#namespaces) resources (e.g., listing or creating namespaces). + - `flag`: Access to [flag](/concepts#flags) resources and sub-resources (e.g., listing or creating flags, variants, rules or rollouts). + - `segment`: Access to [segment](/concepts#segments) resources and sub-resources (e.g., listing or creating segments, constraints or distributions). + - `authentication`: Access to authentication resources (e.g., listing or creating client tokens). + +- `subject`: The (optional) nested subject of the request. This can be one of: + + - `namespace`: Access to [namespace](/concepts#namespaces) resources. + - `flag`: Access to [flag](/concepts#flags) resources. + - `variant`: Access to flag [variant](/concepts#variant-flags) resources. + - `rule`: Access to flag [rule](/concepts#rules) resources. + - `rollout`: Access to flag [rollout](/concepts#rollouts) resources. + - `segment`: Access to [segment](/concepts#segments) resources. + - `constraint`: Access to segment [constraint](/concepts#constraints) resources. + - `distribution`: Access to segment [distribution](/concepts#distributions) resources. + - `token`: Access to client token resources. + +- `verb`: The action being performed on the resource. This can be one of: + - `create`: Access to create resources. + - `read`: Access to list or read resources. + - `update`: Access to update resources. + - `delete`: Access to delete resources. + +Here's an example of the `input.request` field for a request to list flags in the default namespace: + +```json +{ + "namespace": "default", + "resource": "flag", + "subject": "flag", + "verb": "read" +} +``` + +Here is an example policy that allows a user to list flags in the default namespace: + +```rego policy.rego +package flipt.authz.v1 + +import rego.v1 + +default allow = false + +allow if { + input.request.namespace == "default" + input.request.resource == "flag" + input.request.verb == "read" +} +``` + +Combining the above policy with the user information policy from the previous example, you can create a policy that allows users with the `IT` group to delete flags in the default namespace: + +```rego policy.rego +package flipt.authz.v1 + +import rego.v1 + +default allow = false + +allow if { + claims := json.unmarshal(input.authentication.metadata["io.flipt.auth.claims"]) + "IT" in claims.groups + input.request.namespace == "default" + input.request.resource == "flag" + input.request.verb == "delete" +} +``` + +## External Data + +OPA policies can also use external data sources to make decisions. This can be useful when you need to make decisions based on data that is not available in the request context. + +For example, if your authentication method does not provide user roles, you could use an external data source to map user IDs to roles. + +Here is an example policy that uses an external data source to check if the user has the `admin` role: + +```rego policy.rego +package flipt.authz.v1 + +import rego.v1 + +default allow = false + +allow if { + role := data.roles[input.authentication.metadata["io.flipt.auth.name"]] + role == "admin" +} +``` + +And here is an example of the external data source that maps user IDs to roles: + +```json data.json +{ + "roles": { + "user1": "admin", + "user2": "viewer" + } +} +``` + +Flipt allows you to define external data sources in the configuration file. You can find more information on how to configure external data sources in the [Configuration: Authorization](/configuration/authorization) section. + +The combination of OPA's flexible policy language and the ability to use external data sources makes it possible to define complex authorization policies that can adapt to your organization's needs. + +## Authoring Policies + +While the examples provided in this document are simple, you can write policies that are as complex as you need. OPA provides a rich set of built-in functions that can be used to write complex policies. + + + Check out our [Role-Based Access Control with Keycloak + guide](/guides/operation/authorization/rbac-with-keycloak) for an example on + how to configure and use role-based access control (RBAC) with Flipt and + Keycloak using OPA. + + +Learning how to write policies in Rego can be challenging at first, but OPA provides extensive documentation on the [Rego Language](https://www.openpolicyagent.org/docs/latest/policy-language/) as well as a [Rego Playground](https://play.openpolicyagent.org/) where you can test your policies before deploying them. + +OPA also provides a testing framework that you can use to write unit tests for your policies. This can help ensure that your policies are working as expected before deploying them to production. + +Here are some resources to help you get started with writing and testing policies: + +- [Rego Language Reference](https://www.openpolicyagent.org/docs/latest/policy-language/) +- [Rego Playground](https://play.openpolicyagent.org/) +- [Policy Testing](https://www.openpolicyagent.org/docs/latest/policy-testing/) +- [Policy Performance](https://www.openpolicyagent.org/docs/latest/policy-performance/) + +If you have any questions or need help writing policies for Flipt, feel free to reach out to us in our [Discord](https://flipt.io/discord) community. diff --git a/cloud/guides/getting-started.mdx b/cloud/guides/getting-started.mdx index 970e2367..e6042180 100644 --- a/cloud/guides/getting-started.mdx +++ b/cloud/guides/getting-started.mdx @@ -15,7 +15,7 @@ Before you get started with Flipt Hybrid Cloud, you need to have the following: 1. An active Flipt Hybrid Cloud account. If you don't have an account yet, [sign up here](https://tally.so/r/mV0zWM) and we'll get you set up. 2. The Flipt CLI installed on your local machine. You can install the CLI by following the instructions in the [Flipt CLI documentation](/cli/overview). -3. Enable the `cloud` experimental feature in the Flipt configuration file. You can enable the `cloud` feature by adding the following configuration to your `flipt.yaml` file: +3. Enable the `cloud` [experimental feature](/configuration/experimental) in the Flipt configuration file. You can enable the `cloud` feature by adding the following configuration to your `flipt.yaml` file: ```yaml experimental: diff --git a/cloud/guides/production.mdx b/cloud/guides/production.mdx index 3a7a059c..24d30e78 100644 --- a/cloud/guides/production.mdx +++ b/cloud/guides/production.mdx @@ -15,7 +15,7 @@ Before you get started with Flipt Hybrid Cloud, you need to have the following: 1. An active Flipt Hybrid Cloud account. If you don't have an account yet, [sign up here](https://tally.so/r/mV0zWM) and we'll get you set up. 2. Completed the [Getting Started](/cloud/guides/getting-started) guide to setup your local Flipt instance and authenticate with the Flipt CLI. -3. Enable the `cloud` experimental feature in the Flipt configuration file. You can enable the `cloud` feature by adding the following configuration to your `flipt.yaml` file: +3. Enable the `cloud` [experimental feature](/configuration/experimental) in the Flipt configuration file. You can enable the `cloud` feature by adding the following configuration to your `flipt.yaml` file: ```yaml experimental: diff --git a/configuration/authentication.mdx b/configuration/authentication.mdx index 7d7c688a..acc41886 100644 --- a/configuration/authentication.mdx +++ b/configuration/authentication.mdx @@ -113,7 +113,7 @@ Further explanation for using this method can be found in the [Authentication: S The `OIDC` method is a `session compatible` authentication method. - Read our [Login with Google](/guides/login-with-google) guide for a more + Read our [Login with Google](/guides/operation/authentication/login-with-google) guide for a more in-depth walk-through setting up an OIDC provider. @@ -218,7 +218,7 @@ To enable this, you must set the [`use_pkce`](/configuration/overview#authentica #### Example: OIDC With Google - Checkout our [Login with Google](/guides/login-with-google) guide for an + Checkout our [Login with Google](/guides/operation/authentication/login-with-google) guide for an in-depth look into configuring Google as an OIDC provider. @@ -276,7 +276,7 @@ Other providers have similar mechanisms for attenuating who can leverage this au - Read our [Login with Github](/guides/login-with-github) guide for a more + Read our [Login with Github](/guides/operation/authentication/login-with-github) guide for a more in-depth walk-through. @@ -295,7 +295,7 @@ authentication: - user:email ``` -!["GitHub Login"](../images/guides/login-with-github/login-with-github.png) +!["GitHub Login"](../images/guides/operation/authentication/login-with-github/login-with-github.png) #### Allowed Organizations diff --git a/configuration/authorization.mdx b/configuration/authorization.mdx new file mode 100644 index 00000000..5b9388b0 --- /dev/null +++ b/configuration/authorization.mdx @@ -0,0 +1,123 @@ +--- +title: Authorization +description: This document describes how to configure Flipt's authorization mechanisms. +--- + + +Flipt authorization is **experimental** and **disabled** (not required) by default. + +To enable authorization, you must set the `experimental.authorization.enabled` configuration option to `true` in your Flipt [configuration file](/configuration/overview#configuration-file). + +Once authorization has been set to `required: true` all management API routes will require a valid authentication session as well. + +The UI will require a session-compatible authentication method (e.g. [OIDC](/authentication/methods#openid-connect)) to be enabled. + + + +Flipt supports the ability to secure its core API routes by setting the `required` field to `true` on the `authorization` configuration object. + +```yaml config.yaml +authorization: + required: true + +# required while authorization is still experimental +experimental: + authorization: + enabled: true +``` + +When authorization is set to `required`, the API will ensure valid credentials are present on all management API requests. + +See the [Authorization: Overview](/authorization/overview) documentation for more details on Flipt's API authorization handling. + +## Policies + +Flipt uses [Open Policy Agent (OPA)](https://www.openpolicyagent.org/) to enforce authorization policies. OPA is a general-purpose policy engine that can be used to enforce policies across the stack. + +### Local + +Currently, Flipt only supports local policy files. These policy files must be valid [Rego](https://www.openpolicyagent.org/docs/latest/policy-language/) files. + + + In the future we plan to support other policy source backends such as git, + object store, and others. If you have a specific use case, please get in touch! + + +You can specify the path to the policy file in the `policy` object in the `authorization` configuration object. + +```yaml +authorization: + required: true + policy: + backend: local + local: + path: "policy.rego" +``` + +The policy **must** have the following package declaration: + +```rego policy.rego +package flipt.authz.v1 +``` + +You can learn more about policies in our [Authorization: Overview](/authorization/overview#policies) documentation. + +### Polling Interval + +Flipt will poll the policy file for changes at a regular interval. By default, Flipt will poll the policy file every 5 minutes. You can adjust this interval by setting the `poll_interval` field in the `policy` object. + +```yaml +authorization: + required: true + policy: + backend: local + local: + path: "policy.rego" + poll_interval: "1m" +``` + +## External Data + +In addition to policies that can be used to enforce authorization rules, Flipt also provides a way to pass external data to the policy evaluation. + +This can be done by setting the `data` object in the `authorization` configuration object. + +### Local + +Currently, Flipt only supports local data objects. These data objects **must be valid JSON objects**. + + + In the future we plan to support other data source backends such as git, + object store, and others. If you have a specific use case, please get in touch! + + +You can specify the path to the data file in the `data` object in the `authorization` configuration object. + +```yaml +authorization: + required: true + policy: + backend: local + local: + path: "policy.rego" + data: + backend: local + local: + path: "data.json" +``` + +You can learn more about using data with policies in our [Authorization: Overview](/authorization/overview#external-data) documentation. + +### Polling Interval + +Like policies, Flipt will poll data files for changes at a regular interval. By default, Flipt will poll the data file every 30 seconds. You can adjust this interval by setting the `poll_interval` field in the `data` object. + +```yaml +authorization: + required: true + data: + backend: local + local: + path: "data.json" + poll_interval: "1m" +``` diff --git a/configuration/experimental.mdx b/configuration/experimental.mdx new file mode 100644 index 00000000..c82f19eb --- /dev/null +++ b/configuration/experimental.mdx @@ -0,0 +1,91 @@ +--- +title: Experimental +description: This document describes our current experimental features and how to enable them. +--- + +## Introduction + +From time to time, we may introduce new features that are not yet ready for general availability. These features are considered experimental and may change or be removed in future releases. We encourage you to try these features and provide feedback to help us improve them. + +## Enabling Experimental Features + +These features are disabled by default. To enable them, you can set the `experimental.{feature}.enabled` configuration option to `true` in your Flipt [configuration file](/configuration/overview#configuration-file). + +For example to enable the `foo` experimental feature: + +```yaml config.yaml +experimental: + foo: + enabled: true +``` + + + You can also enable experimental features using [environment + variables](/overview#environment-variables). For example, to enable the `foo` + experimental feature, you can set the `FLIPT_EXPERIMENTAL_FOO_ENABLED` + environment variable to `true`. + + +## Current Experimental Features + +The following is a list of our current experimental features and a brief description of each. + + + Make sure you have the [latest + version](https://github.com/flipt-io/flipt/releases/latest) of the Flipt CLI + installed on your local machine. + + +### Cloud + +Introduced in `v1.42.0`. + +[Flipt Hybrid Cloud](cloud/overview) enables you to continue to use Flipt's feature management capabilities while keeping your feature data on-premises but still benefiting from our cloud-based management console. + +With Flipt Hybrid Cloud you get the following benefits: + +- [Managed Authentication](/cloud/features/authentication): Securely authenticate your users with Flipt's managed authentication service, which supports email/password, magic link, social login, and SSO with popular providers. +- [User Management](/cloud/features/user-management): Manage your users and teams with Flipt's user management service, which supports roles, permissions, and role-based access control. +- [Hosted Audit Logs](/cloud/features/audit-logs): Keep track of changes to your feature data with Flipt's hosted audit logs service, which provides a detailed history of all changes made to your feature data with 30 days of retention by default (custom retention periods are available). + +To enable the Flipt Hybrid Cloud experimental feature, set the `experimental.cloud.enabled` configuration option to `true`. + +```yaml config.yaml +experimental: + cloud: + enabled: true +``` + + + You must have a valid Flipt Hybrid Cloud subscription to use this feature. To + learn more about Flipt Hybrid Cloud and request access, please fill out our + [contact form](https://tally.so/r/mV0zWM). + + +### Authorization + +Introduced in `v1.43.0`. + +[Flipt Authorization](/authorization/overview) enables you to control access to your feature data with fine-grained permissions and infinite flexibility. + +Our authorization system leverages Open Policy Agent (OPA), which gives you the power to define custom policies that control who can access your feature data and what actions they can perform. + +To enable the Flipt Authorization experimental feature, set the `experimental.authorization.enabled` configuration option to `true`. + +```yaml config.yaml +experimental: + authorization: + enabled: true +``` + +To learn more about Flipt Authorization, see the [Authorization](/authorization/overview) documentation. + +## Deprecations + +Once an experimental feature is promoted to a stable feature or is removed, it will move to a deprecated status. Depending on the feature, you may need to take action to migrate to the new stable feature or remove the deprecated feature from your configuration. + +If an enabled experimental feature has been deprecated, you will see a warning message in the CLI output when you start the Flipt server, such as: + +```bash +Warning: 'experimental.filesystem_storage' has been deprecated and will be removed in a future release. +``` diff --git a/configuration/overview.mdx b/configuration/overview.mdx index 01d74882..ec63b6cf 100644 --- a/configuration/overview.mdx +++ b/configuration/overview.mdx @@ -221,6 +221,18 @@ export FLIPT_CORS_ALLOWED_ORIGINS="http://localhost:3000 http://localhost:3001" | authentication.methods.jwt.validate_claims.audiences | The audience claim (list) to validate on JWT tokens | | v1.35.0 | | authentication.methods.jwt.validate_claims.subject | The subject claim to validate on JWT tokens | | v1.41.0 | +### Authorization + +| Property | Description | Default | Since | +| ---------------------------------- | ------------------------------------------------------ | ------- | ------- | +| authorization.required | Enable or disable authorization validation on requests | false | v1.43.0 | +| authorization.policy.backend | The backend to use for authorization policies (local) | local | v1.43.0 | +| authorization.policy.local.path | Path to the local policy file | | v1.43.0 | +| authorization.policy.poll_interval | Interval to poll the policy file for changes | 5m | v1.43.0 | +| authorization.data.backend | The backend to use for authorization data (local) | local | v1.43.0 | +| authorization.data.local.path | Path to the local data file | | v1.43.0 | +| authorization.data.poll_interval | Interval to poll the data file for changes | 30s | v1.43.0 | + ### Database | Property | Description | Default | Since | @@ -424,10 +436,10 @@ From time to time, Flipt may introduce new features that are not considered full We put experimental features behind a configuration setting that can be enabled in the configuration file. To enable experimental features, set the `experimental.{feature}.enabled` configuration option to `true`. -Example: To enable the experimental cloud feature, add the following to your configuration file: - ```yaml experimental: - cloud: + foo: enabled: true ``` + +See the [Experimental](/configuration/experimental) documentation for more information on the current experimental features and how to enable them. diff --git a/guides/login-with-github.mdx b/guides/operation/authentication/login-with-github.mdx similarity index 96% rename from guides/login-with-github.mdx rename to guides/operation/authentication/login-with-github.mdx index 5fa37345..0e4ea3a9 100644 --- a/guides/login-with-github.mdx +++ b/guides/operation/authentication/login-with-github.mdx @@ -3,7 +3,7 @@ title: Login with GitHub description: Configuring Flipt to enable login with GitHub via OAuth 2.0 --- -If you've read the [Login With Google guide](/guides/login-with-google), you would have learned that Flipt supports many methods of authentication for users to control who has access to Flipt. +If you've read the [Login With Google guide](/guides/operation/authentication/login-with-google), you would have learned that Flipt supports many methods of authentication for users to control who has access to Flipt. Alongside the support for generic OIDC login, Flipt has launched support for login with GitHub in version [v1.26.0](https://github.com/flipt-io/flipt/releases/tag/v1.26.0), through their OAuth 2.0 flow. This guide will serve as a walk-through on how to set this flow up for users of Flipt in your organization. @@ -117,7 +117,7 @@ Click on the green `Authorize {username}` button to allow completion of the OAut After completion of the flow you should be taken to the normal Flipt homepage and start using Flipt normally as before. If you have a profile picture on GitHub, it should show in the top right corner. -![Flipt Homepage](/images/guides/login-with-github/flipt-homepage.png) +![Flipt Dashboard](/images/guides/login-with-github/flipt-homepage.png) This guide shows the basics of getting Flipt running with GitHub OAuth 2.0 authentication in a development setting using `ngrok`. diff --git a/guides/login-with-google.mdx b/guides/operation/authentication/login-with-google.mdx similarity index 96% rename from guides/login-with-google.mdx rename to guides/operation/authentication/login-with-google.mdx index 8b5119bb..b4575b36 100644 --- a/guides/login-with-google.mdx +++ b/guides/operation/authentication/login-with-google.mdx @@ -3,7 +3,7 @@ title: Login with Google description: Configuring Flipt to enable login with Google via OIDC --- -![Flipt UI presenting login with google button](/images/guides/login-with-google/login-with-google.png) +![Flipt UI presenting login with Google button](/images/guides/login-with-google/login-with-google.png) In a production environment it's often important to control who has access to your systems and feature flagging is no different. Flipt ships with built-in mechanisms and configuration for service-to-Flipt and user-to-Flipt authentication. @@ -46,17 +46,7 @@ It also gives Flipt the option to obtain and present user profile pictures and e For the purpose of this guide, we will start by configuring and running Flipt with a minimal configuration file. -### 1. Create a New Directory - -Creating a new directory is an optional step, however, we suggest you create a blank directory in which to experiment with Flipt. - -```sh -mkdir ~/flipt-with-google - -cd ~/flipt-with-google -``` - -### 2. Define a Flipt `config.yml` +### 1. Define a Flipt `config.yml` We're going to create a configuration file named `config.yml` in the current directory. This file will tell Flipt to increase its logging level to the maximum to aid in debugging. @@ -74,7 +64,7 @@ authentication: required: true ``` -### 3. Run Flipt as a Docker container +### 2. Run Flipt as a Docker container In this step, we run Flipt and mount our local `config.yml` file into the running container. @@ -91,7 +81,7 @@ docker run -it --rm \ flipt/flipt:latest --config /config.yml ``` -### 4. Navigate to the Flipt UI +### 3. Navigate to the Flipt UI Once you visit Flipt's UI, you should be greeted by a message stating that there are no login providers configured. As mentioned before, once authentication is required, a session-compatible method is needed to enable login. @@ -190,7 +180,7 @@ we can begin configuring Flipt to leverage it. ### 1. Add `google` provider to `config.yml` -Open your `config.yml` we created in the [beginning of the guide](#2-define-a-flipt-config-yml). +Open your `config.yml` we created in the [beginning of the guide](#1-define-a-flipt-config-yml). Now we're going to update your configuration with the details we obtained from Google. The configuration below does the following for Flipt: diff --git a/guides/operation/authentication/login-with-keycloak.mdx b/guides/operation/authentication/login-with-keycloak.mdx new file mode 100644 index 00000000..e0803f46 --- /dev/null +++ b/guides/operation/authentication/login-with-keycloak.mdx @@ -0,0 +1,188 @@ +--- +title: Login with Keycloak +description: Configuring Flipt to enable login with Keycloak via OIDC +--- + +![Flipt UI presenting login with Keycloak button](/images/guides/login-with-keycloak/login-with-keycloak.png) + +If you've read the [Login With Google guide](/guides/operation/authentication/login-with-google), you would have learned that Flipt supports many methods of authentication for users to control who has access to Flipt. + +[Keycloak](https://www.keycloak.org/) is an open-source identity and access management solution that supports OpenID Connect (OIDC). This guide will serve as a walk-through on how to set up Keycloak for authentication of users of Flipt in your organization. + +## What You'll Learn + +In this guide, you will learn how to configure Keycloak as an OIDC provider for Flipt. + +By the end of this guide, we will have: + +- ⚙️ Setup Keycloak by creating a realm, user, and client +- 🔒 Configured Keycloak as an OIDC provider for Flipt + +## Prerequisites + +For this guide you're going to need the following: + +- [Docker](https://www.docker.com/) +- Read the [Login With Google guide](/guides/operation/authentication/login-with-google) + +## Setting Up Keycloak + +To set up Keycloak for authentication, you will need to create a new realm, client, and user. + + + This section of the guide is a simplified version of the [Keycloak: Getting + Started Docker + Guide](https://www.keycloak.org/getting-started/getting-started-docker). + + +### Step 1: Start Keycloak + +Start Keycloak using Docker: + +```bash +docker run -p 8080:8080 -e KEYCLOAK_ADMIN=admin -e KEYCLOAK_ADMIN_PASSWORD=admin quay.io/keycloak/keycloak:24.0.4 start-dev +``` + +### Step 2: Access Keycloak + +Access Keycloak at [http://localhost:8080](http://localhost:8080) and log in with the admin credentials (`admin`/`admin`). + +### Step 3: Create a Realm + +Create a new realm called `flipt`: + +1. Click on `Keycloak` in the top-left corner. +1. Click on the `Create realm` button. +1. Enter `flipt` as the realm name. +1. Click on the `Create` button. + +![Keycloak create realm form](/images/guides/login-with-keycloak/create-keycloak-realm.png) + +### Step 4: Create a User + +Create a new user called `user`: + +1. Click on the `Users` tab. +1. Click on the `Create new user` button. +1. Fill in the user details and click on the `Create` button. +1. Set the user's password by clicking on the `Credentials` tab and click `Set Password`. +1. Enter a password and confirm the password. +1. Toggle `Temporary` to `OFF` so that the user does not need to change their password on the first login. +1. Click `Save`. + +![Keycloak create user](/images/guides/login-with-keycloak/create-keycloak-user.png) + +### Step 5: Create a Client + +Create a new client called `flipt`: + +1. Click on the `Clients` tab. +1. Click on the `Create Client` button. +1. Ensure `OpenID Connect` is selected as the client type. +1. Enter `flipt` as the client ID and click on `Next`. +1. Ensure the `Standard flow` and `Direct access grants` are enabled and click on `Next`. +1. Set the `Valid Redirect URIs` to `http://localhost:8081/auth/vl/method/oidc/keycloak/callback`. +1. Set the `Web Origins` to `http://localhost:8081`. +1. Click on `Save`. + +![Keycloak create client](/images/guides/login-with-keycloak/create-keycloak-client.png) + +### Step 6: Copy Client ID and Secret + +1. From the `flipt` client, click on the `Credentials` tab. +1. The client ID will be displayed at the top of the page (e.g., `flipt`). Copy this value and save it for later. +1. Click on the copy icon next to the `Client Secret` field to copy the client secret. Save this value for later. + +### Step 7: Get Required URLs + +1. In another browser tab, paste the following URL into the address bar: + +``` +http://localhost:8080/auth/realms/flipt/.well-known/openid-configuration +``` + +2. Copy the `issuer` URL from the JSON response. This will be used as the `issuer_url` in the Flipt configuration. + +![Keycloak OIDC configuration](/images/guides/login-with-keycloak/keycloak-oidc-configuration.png) + +## Running Flipt + +Now that we've an OIDC client configured in our Keycloak instance, we can begin configuring Flipt to leverage it. + +### 1. Define a Flipt `config.yml` + +We're going to create a configuration file named `config.yml` in the current directory. +This file will tell Flipt to increase its logging level to the maximum to aid in debugging. We will also set the HTTP port to `8081` to avoid conflicts with Keycloak. + +It will also set authentication as `required = true`. +This is needed to ensure that Flipt enforces its APIs and must be provided with a credential of some sort to gain access. + +```yaml config.yml +version: "1.0" + +log: + level: DEBUG + +server: + http_port: 8081 + +authentication: + required: true +``` + +### 2. Add `keycloak` provider to `config.yml` + +In your `config.yml` file, add the following configuration in the `authentication` section to enable the OIDC method and configure the Keycloak provider: + +```yaml config.yml +authentication: + required: true + session: + domain: localhost:8081 + methods: + oidc: + enabled: true + providers: + keycloak: + issuer_url: "< issuer URL from Keycloak >" + client_id: "< client ID from Keycloak (e.g., `flipt`) >" + client_secret: "< client secret from Keycloak >" + redirect_address: "http://localhost:8081" +``` + +The session domain is required for session-compatible authentication methods. It's used by Flipt as the domain for storing authentication cookies. + +Note that we've enabled the `oidc` method, and it has a section called `providers`. Each key beneath the `providers` section is unique and can be whatever you want. However, the name is important as it effects the `redirect_url` generated for the particular provider. + +Each provider section has a consistent structure. You're required to provide the `issuer_url`, `client_id`, `client_secret` and `redirect_address`. + +The `scopes` section is optional, and allows Flipt the opportunity to obtain additional details on the authenticating caller (e.g. email and profile picture). + +### 3. Start Flipt + +You can now start your Flipt instance using the following command: + +```sh +docker run -it --rm \ + -p 8080:8080 \ + -v "$(pwd)/config.yml:/config.yml" \ + flipt/flipt:latest --config /config.yml +``` + +Once Flipt has started you can to navigate your browser to the [UI](http://localhost:8081) and attempt a login with Keycloak. + +When you click `Login with Keycloak` you should be navigated away to your Keycloak instance to complete the authentication flow. + +![Keycloak login screen](/images/guides/login-with-keycloak/keycloak-login.png) + +Once you successfully authenticate with the username/password you created earlier, you should return to Flipt and be logged into. + +![Flipt dashboard](/images/guides/login-with-keycloak/flipt-dashboard.png) + +## Conclusion + +🎉 Congratulations, you've successfully run Flipt and enabled login with Keycloak as the OIDC provider. + +Many of the same production considerations from the [Login With Google guide](/guides/operation/authentication/login-with-google) apply here. You should follow the same steps to secure your Flipt instance and ensure that only authorized users can access it. + +Next, you might want to consider enabling authorization and setting up policies to control who can access what in Flipt. You can learn more about this in the [Role-Based Access Control with Keycloak guide](/guides/operation/authorization/rbac-with-keycloak). diff --git a/guides/operation/authorization/rbac-with-keycloak.mdx b/guides/operation/authorization/rbac-with-keycloak.mdx new file mode 100644 index 00000000..693bfeb2 --- /dev/null +++ b/guides/operation/authorization/rbac-with-keycloak.mdx @@ -0,0 +1,196 @@ +--- +title: Role-Based Access Control with Keycloak +description: Configure and use role-based access control (RBAC) with Flipt, Keycloak, and OPA. +--- + +As described in the [Authorization Overview](/authorization/overview), Flipt supports the ability to secure its core API routes with authorization in a flexible and extensible way. + +This guide will cover how to configure and use role-based access control (RBAC) with Flipt with a Rego policy configured for an imaginary organization using Keycloak for authentication. + + + Role-based access control (RBAC) is not a feature of Flipt itself but rather a + pattern that can be implemented using Flipt's authorization system via OPA. + + +## What You'll Learn + +- 🔒 How to set up Keycloak for authorization +- 🔑 How to create a Rego policy for RBAC with Flipt +- ⚙️ How to configure Flipt to use the policy for authorization + +## Prerequisites + +For this guide, you will need: + +- [Docker](https://www.docker.com/) +- Follow the [Login with Keycloak guide](/guides/operation/authentication/login-with-keycloak) to set up Keycloak for authentication + +## Setting Up Keycloak + +To set up Keycloak for authorization, you'll first need to create a new realm, client, and user. + +### Step 1: Follow the Login with Keycloak Guide + +Follow the [Login with Keycloak guide](/guides/operation/authentication/login-with-keycloak) to set up Keycloak for authentication. + +This guide will walk you through setting up Keycloak and creating a realm, client, and user that you will use for this guide. + +![Flipt UI presenting login with Keycloak button](/images/guides/login-with-keycloak/login-with-keycloak.png) + +### Step 2: Create a Realm Role + +1. Click on the `Realm Roles` tab. +1. Click `Create Role`. +1. Enter `developer` as the role name and description and click `Save`. + +![Create Role](/images/guides/rbac-with-keycloak/create-keycloak-role.png) + +### Step 3: Assign the Role to a User + +1. Click on the `Users` tab. +1. Click on the `user` user. +1. Click on the `Role Mappings` tab. +1. Click `Assign Role`. +1. Select the `developer` role and click `Assign`. + +![Assign Role](/images/guides/rbac-with-keycloak/assign-keycloak-role.png) + +### Step 4: Map Client Scopes + +Map the `roles` scope to the `flipt` client: + +1. Click on the `Clients Scopes` tab. +1. Click on `roles` in the list of client scopes. +1. Click on the `Mappers` tab. +1. Click on `realm roles` in the list of mappers. + +![Map Client Scopes](/images/guides/rbac-with-keycloak/map-client-scopes.png) + +5. Set the `Token Claim Name` field to something short like `roles`. +6. Set the `Claim JSON Type` field to `String`. +7. Toggle on `Add to ID token`. +8. Click `Save`. + +![Customize Role Mapper](/images/guides/rbac-with-keycloak/customize-role-mapper.png) + +## Configuring RBAC in Flipt + +To configure RBAC with Flipt, you will need to define a Rego policy that enforces the roles and permissions for your organization. + +Here's an example of a simple policy that checks whether a user has the `developer` role: + +```rego policy.rego +package flipt.authz.v1 + +import rego.v1 + +default allow := false + +allow if { + claims := json.unmarshal(input.authentication.metadata["io.flipt.auth.claims"]) + "developer" in claims.roles +} +``` + +In this example, the policy checks if the user has the `developer` role. If the user has the `developer` role, the policy will allow the request. Otherwise, the request will be denied. + +The `authentication` input is provided by Flipt to OPA and contains the authentication information for the request. This information is specific to the authentication method used to authenticate the request. + +More complex policies can be defined to enforce fine-grained access control based on your organization's requirements. For example, you could define policies that check for specific roles and permissions for different resources or actions. + +An example policy that allows users with the `developer` role to have full access to the Management API and users with the `viewer` role to have read-only access might look like this: + +```rego policy.rego +package flipt.authz.v1 + +import rego.v1 + +default allow := false + +allow if { + claims := json.unmarshal(input.authentication.metadata["io.flipt.auth.claims"]) + "developer" in claims.roles +} + +allow if { + claims := json.unmarshal(input.authentication.metadata["io.flipt.auth.claims"]) + "viewer" in claims.roles + input.request.verb = "read" +} +``` + +### Step 1: Write the Rego Policy + +1. Create a new file called `policy.rego` with the following content: + +```rego policy.rego +package flipt.authz.v1 + +import rego.v1 + +default allow := false + +allow if { + claims := json.unmarshal(input.authentication.metadata["io.flipt.auth.claims"]) + "developer" in claims.roles +} +``` + +### Step 2: Configure Flipt to Use the Policy + +Update the `flipt.yaml` configuration file from the [Login with Keycloak guide](/guides/operation/authentication/login-with-keycloak) to enable authorization and specify the path to the Rego policy file: + +```yaml flipt.yaml +authentication: + required: true + session: + domain: localhost:8081 + methods: + oidc: + enabled: true + providers: + keycloak: + issuer_url: "< issuer URL from Keycloak >" + client_id: "< client ID from Keycloak (e.g., `flipt`) >" + client_secret: "< client secret from Keycloak >" + redirect_address: "http://localhost:8081" + +authorization: + required: true + policy: + backend: local + local: + path: "policy.rego" +``` + +### Step 3: Run Flipt + +You can now start your Flipt instance using the following command: + +```sh +docker run -it --rm \ + -p 8080:8080 \ + -v "$(pwd)/config.yml:/config.yml" \ + -v "$(pwd)/policy.rego:/policy.rego" \ + flipt/flipt:latest --config /config.yml +``` + +## Testing the Policy + +To test the policy, login to Flipt using the user you created in Keycloak. If the user has the `developer` role, they should be able to access the Flipt Management API. + +You can create a new user in Keycloak that does not have the `developer` role to test that the policy is working as expected. + +If the user does not have the `developer` role, they should receive an error message in the UI or API response. + +![Unauthorized Access](/images/guides/rbac-with-keycloak/unauthorized.png) + +## Conclusion + +In this guide, you learned how to configure and use role-based access control (RBAC) with Flipt using a Rego policy and Keycloak for authentication. + +By defining a Rego policy that enforces the roles and permissions for your organization, you can secure your Flipt instance and control access to your feature data with fine-grained permissions and infinite flexibility. + +For more information on Flipt's authorization system and how to configure and use it, see the [Authorization Overview](/authorization/overview). + +In the future we plan to provide more examples and best practices for using Flipt's authorization system with different authentication providers and use cases. If you have any feedback or suggestions for how we can improve this guide, please let us know! diff --git a/guides/deploy-to-flyio.mdx b/guides/operation/deployment/deploy-to-flyio.mdx similarity index 100% rename from guides/deploy-to-flyio.mdx rename to guides/operation/deployment/deploy-to-flyio.mdx diff --git a/guides/deploy-to-kubernetes.mdx b/guides/operation/deployment/deploy-to-kubernetes.mdx similarity index 100% rename from guides/deploy-to-kubernetes.mdx rename to guides/operation/deployment/deploy-to-kubernetes.mdx diff --git a/guides/get-going-with-gitops.mdx b/guides/user/get-going-with-gitops.mdx similarity index 100% rename from guides/get-going-with-gitops.mdx rename to guides/user/get-going-with-gitops.mdx diff --git a/guides/using-references.mdx b/guides/user/using-references.mdx similarity index 100% rename from guides/using-references.mdx rename to guides/user/using-references.mdx diff --git a/images/guides/login-with-github/flipt-homepage.png b/images/guides/login-with-github/flipt-dashboard.png similarity index 100% rename from images/guides/login-with-github/flipt-homepage.png rename to images/guides/login-with-github/flipt-dashboard.png diff --git a/images/guides/login-with-keycloak/create-keycloak-client.png b/images/guides/login-with-keycloak/create-keycloak-client.png new file mode 100644 index 00000000..d5450a5a Binary files /dev/null and b/images/guides/login-with-keycloak/create-keycloak-client.png differ diff --git a/images/guides/login-with-keycloak/create-keycloak-realm.png b/images/guides/login-with-keycloak/create-keycloak-realm.png new file mode 100644 index 00000000..d69f6191 Binary files /dev/null and b/images/guides/login-with-keycloak/create-keycloak-realm.png differ diff --git a/images/guides/login-with-keycloak/create-keycloak-user.png b/images/guides/login-with-keycloak/create-keycloak-user.png new file mode 100644 index 00000000..c8f6920a Binary files /dev/null and b/images/guides/login-with-keycloak/create-keycloak-user.png differ diff --git a/images/guides/login-with-keycloak/flipt-dashboard.png b/images/guides/login-with-keycloak/flipt-dashboard.png new file mode 100644 index 00000000..c6a27866 Binary files /dev/null and b/images/guides/login-with-keycloak/flipt-dashboard.png differ diff --git a/images/guides/login-with-keycloak/keycloak-login.png b/images/guides/login-with-keycloak/keycloak-login.png new file mode 100644 index 00000000..dadb6f18 Binary files /dev/null and b/images/guides/login-with-keycloak/keycloak-login.png differ diff --git a/images/guides/login-with-keycloak/keycloak-oidc-configuration.png b/images/guides/login-with-keycloak/keycloak-oidc-configuration.png new file mode 100644 index 00000000..a4c15961 Binary files /dev/null and b/images/guides/login-with-keycloak/keycloak-oidc-configuration.png differ diff --git a/images/guides/login-with-keycloak/login-with-keycloak.png b/images/guides/login-with-keycloak/login-with-keycloak.png new file mode 100644 index 00000000..b22e621b Binary files /dev/null and b/images/guides/login-with-keycloak/login-with-keycloak.png differ diff --git a/images/guides/rbac-with-keycloak/assign-keycloak-role.png b/images/guides/rbac-with-keycloak/assign-keycloak-role.png new file mode 100644 index 00000000..c9d46616 Binary files /dev/null and b/images/guides/rbac-with-keycloak/assign-keycloak-role.png differ diff --git a/images/guides/rbac-with-keycloak/create-keycloak-role.png b/images/guides/rbac-with-keycloak/create-keycloak-role.png new file mode 100644 index 00000000..c617a9b9 Binary files /dev/null and b/images/guides/rbac-with-keycloak/create-keycloak-role.png differ diff --git a/images/guides/rbac-with-keycloak/customize-role-mapper.png b/images/guides/rbac-with-keycloak/customize-role-mapper.png new file mode 100644 index 00000000..f004d633 Binary files /dev/null and b/images/guides/rbac-with-keycloak/customize-role-mapper.png differ diff --git a/images/guides/rbac-with-keycloak/map-client-scopes.png b/images/guides/rbac-with-keycloak/map-client-scopes.png new file mode 100644 index 00000000..f5db6118 Binary files /dev/null and b/images/guides/rbac-with-keycloak/map-client-scopes.png differ diff --git a/images/guides/rbac-with-keycloak/unauthorized.png b/images/guides/rbac-with-keycloak/unauthorized.png new file mode 100644 index 00000000..5cd3c584 Binary files /dev/null and b/images/guides/rbac-with-keycloak/unauthorized.png differ diff --git a/mint.json b/mint.json index dd4912d2..fe6b10bb 100644 --- a/mint.json +++ b/mint.json @@ -131,17 +131,34 @@ { "group": "User Guides", "pages": [ - "guides/get-going-with-gitops", - "guides/using-references" + "guides/user/get-going-with-gitops", + "guides/user/using-references" ] }, { "group": "Operations Guides", "pages": [ - "guides/deploy-to-flyio", - "guides/deploy-to-kubernetes", - "guides/login-with-google", - "guides/login-with-github" + { + "group": "Deployment", + "pages": [ + "guides/operation/deployment/deploy-to-flyio", + "guides/operation/deployment/deploy-to-kubernetes" + ] + }, + { + "group": "Authentication", + "pages": [ + "guides/operation/authentication/login-with-google", + "guides/operation/authentication/login-with-github", + "guides/operation/authentication/login-with-keycloak" + ] + }, + { + "group": "Authorization", + "pages": [ + "guides/operation/authorization/rbac-with-keycloak" + ] + } ] }, { @@ -158,10 +175,6 @@ "group": "Configuration", "pages": [ "configuration/overview", - "configuration/authentication", - "configuration/observability", - "configuration/storage", - "configuration/telemetry", "configuration/analytics", { "group": "Auditing", @@ -169,7 +182,13 @@ "configuration/auditing/overview", "configuration/auditing/webhooks" ] - } + }, + "configuration/authentication", + "configuration/authorization", + "configuration/observability", + "configuration/storage", + "configuration/telemetry", + "configuration/experimental" ] }, { @@ -221,6 +240,12 @@ "authentication/using-jwts" ] }, + { + "group": "Authorization", + "pages": [ + "authorization/overview" + ] + }, { "group": "Operations", "pages": [ @@ -385,6 +410,30 @@ { "source": "/managed/hybrid", "destination": "/cloud/overview" + }, + { + "source":"/guides/get-going-with-gitops", + "destination": "/guides/user/get-going-with-gitops" + }, + { + "source": "/guides/using-references", + "destination": "/guides/user/using-references" + }, + { + "source": "/guides/deploy-to-flyio", + "destination": "/guides/operation/deployment/deploy-to-flyio" + }, + { + "source": "/guides/deploy-to-kubernetes", + "destination": "/guides/operation/deployment/deploy-to-kubernetes" + }, + { + "source": "/guides/login-with-google", + "destination": "/guides/operation/authentication/login-with-google" + }, + { + "source": "/guides/login-with-github", + "destination": "/guides/operation/authentication/login-with-github" } ], "footerSocials": {