{"id":13774975,"url":"https://github.com/otterize/intents-operator","last_synced_at":"2025-05-11T07:31:34.068Z","repository":{"id":61648779,"uuid":"515188090","full_name":"otterize/intents-operator","owner":"otterize","description":"Manage network policies, AWS, GCP \u0026 Azure IAM policies, Istio Authorization Policies, and Kafka ACLs in a Kubernetes cluster with ease.","archived":false,"fork":false,"pushed_at":"2025-04-29T10:56:37.000Z","size":20759,"stargazers_count":302,"open_issues_count":7,"forks_count":16,"subscribers_count":5,"default_branch":"main","last_synced_at":"2025-05-04T12:15:10.632Z","etag":null,"topics":["acl","auth","authentication","authorization","controller","go","golang","hacktoberfest","ibac","intents","kafka","kubernetes","mtls","networkpolicies","operator","otterize","zero-trust"],"latest_commit_sha":null,"homepage":"","language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/otterize.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2022-07-18T13:06:33.000Z","updated_at":"2025-05-01T13:36:25.000Z","dependencies_parsed_at":"2023-10-01T09:56:18.063Z","dependency_job_id":"7b0cf010-fe86-4e39-ae10-e00491d88d68","html_url":"https://github.com/otterize/intents-operator","commit_stats":{"total_commits":524,"total_committers":19,"mean_commits":27.57894736842105,"dds":0.6545801526717557,"last_synced_commit":"4104fcfa98d57d790f38a8174a21f3b12217a074"},"previous_names":[],"tags_count":136,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/otterize%2Fintents-operator","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/otterize%2Fintents-operator/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/otterize%2Fintents-operator/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/otterize%2Fintents-operator/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/otterize","download_url":"https://codeload.github.com/otterize/intents-operator/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":253533466,"owners_count":21923442,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["acl","auth","authentication","authorization","controller","go","golang","hacktoberfest","ibac","intents","kafka","kubernetes","mtls","networkpolicies","operator","otterize","zero-trust"],"created_at":"2024-08-03T17:01:32.381Z","updated_at":"2025-05-11T07:31:34.049Z","avatar_url":"https://github.com/otterize.png","language":"Go","funding_links":[],"categories":["Tools and Libraries"],"sub_categories":["Security and Compliance"],"readme":"# Otterize intents operator\n\n\u003cimg title=\"Otter Manning Helm\" src=\"./otterhelm.png\" width=200 alt=\"logo\" /\u003e\n\n![build](https://github.com/otterize/intents-operator/actions/workflows/build.yaml/badge.svg)\n[![Go Report Card](https://goreportcard.com/badge/github.com/otterize/intents-operator/src)](https://goreportcard.com/report/github.com/otterize/intents-operator/src)\n[![community](https://img.shields.io/badge/slack-Otterize_Slack-purple.svg?logo=slack)](https://joinslack.otterize.com)\n\n* [About](#about)\n* [Quickstart \u0026 Docs](https://docs.otterize.com/)\n* [How does the intents operator work?](#how-does-the-intents-operator-work)\n  * [Network policies](#network-policies)\n  * [AWS IAM policies](#aws-iam)\n  * [Azure IAM policies](#azure-iam)\n  * [Google Cloud IAM policies](#google-cloud-iam)\n  * [Kafka mTLS \u0026 ACLs](#kafka-mtls--acls)\n  * [Deducing workload identities](#identities)\n* [Bootstrapping](#bootstrapping)\n* [Read more](#read-more)\n* [Development](#development)\n* [Contributing](#contributing)\n* [Slack](#slack)\n\n## About\n\nThe Otterize intents operator is a tool used to easily automate the creation of network policies and Kafka ACLs\nin a Kubernetes cluster using a human-readable format, via a custom resource.\n\nUsers declare each client's intents to access specific servers (represented as the kind `ClientIntents`);\nthe operator automatically labels the relevant pods accordingly,\nand creates the corresponding network policies and Kafka ACLs.\n\nHere is an example of a `ClientIntents` resource enabling traffic from `my-client` to `web-server` and `kafka-server`:\n\n```yaml\napiVersion: k8s.otterize.com/v1alpha3\nkind: ClientIntents\nmetadata:\n  name: intents-sample\nspec:\n  service:\n    name: my-client\n  calls:\n    - name: web-server\n    - name: kafka-server\n      type: kafka\n```\n\n## How does the intents operator work?\n\n### Network policies\n\nThe intents operator automatically creates, updates and deletes network policies, and automatically labels client and server pods,\nto match declarations in client intents files.\nThe policies created are `Ingress`-based, so source pods are labeled with a `can-access-\u003ctarget\u003e=true`\nwhile destination pods are labeled with `has-identity=\u003ctarget\u003e`.\n\nThe example above results in the following network policy being created:\n\n```yaml\nName: access-to-web-server\nSpec:\n  # This label is added to the server by the intents operator\n  PodSelector: intents.otterize.com/server=web-server-default-33a0f0\n  Allowing ingress traffic:\n    To Port: \u003cany\u003e (traffic allowed to all ports)\n    From:\n      # This label is added to the client by the intents operator\n      PodSelector: intents.otterize.com/access-web-server-default-33a0f0=true\n  Policy Types: Ingress\n```\n\nFor more usage example see the [network policy tutorial](https://docs.otterize.com/quick-tutorials/k8s-network-policies).\n\n### AWS IAM\n\nThe intents operator, together with the [credentials operator](https://github.com/otterize/credentials-operator), enables the intent-based declarative management of AWS IAM roles and policies.\n\nTo enable AWS access for a pod, follow these steps:\n\n1. Label a pod to have an AWS role created for it:\n\n    ```yaml\n    metadata:\n     labels:\n      \"credentials-operator.otterize.com/create-aws-role\": \"true\"\n    ```\n\n2. Declare ClientIntents to specify which AWS resources it needs access to:\n\n    ```yaml\n    apiVersion: k8s.otterize.com/v1alpha3\n    kind: ClientIntents\n    metadata:\n      name: server\n    spec:\n      service:\n        name: server\n      calls:\n        - name: arn:aws:s3:::otterize-tutorial-bucket-*/*\n          type: aws\n          awsActions:\n            - \"s3:PutObject\"\n    ```\n\nTry the [AWS IAM tutorial](https://docs.otterize.com/quickstart/access-control/aws-iam-eks) to learn more.\n\n### Azure IAM\n\nThe intents operator, together with the [credentials operator](https://github.com/otterize/credentials-operator), enables the intent-based declarative management of Azure IAM identities and role assignments.\n\nTo enable Azure access for a pod, follow these steps:\n\n1. Label a pod to have an Azure managed identity created for it:\n\n    ```yaml\n    metadata:\n     labels:\n      \"credentials-operator.otterize.com/create-azure-workload-identity\": \"true\"\n    ```\n\n2. Declare ClientIntents to specify which Azure scopes it needs access to:\n\n    ```yaml\n    apiVersion: k8s.otterize.com/v1alpha3\n    kind: ClientIntents\n    metadata:\n      name: server\n    spec:\n      service:\n        name: server\n      calls:\n        # The Azure resource ID that references the resource(s) for the authorization. Subscription \u0026 resource group are automatically appended.\n        - name: \"/providers/Microsoft.Storage/storageAccounts/otterizeazureiamtutorial/blobServices/default/containers/otterizeazureiamtutorialcontainer\"\n          type: azure\n          # one or more Azure roles that will be provided to the specified resources\n          azureRoles:\n            - \"Storage Blob Data Contributor\"\n        - name: \"/providers/Microsoft.KeyVault/vaults/otterizetutorialazureiamkeyvault\"\n          type: azure\n          # Optional - Grant Azure Key Vault data plane access by using Key Vault access policy\n          azureKeyVaultPolicy:\n            certificatePermissions:\n              - \"all\"\n            keyPermissions:\n              - \"all\"\n            secretPermissions:\n              - \"all\"\n            storagePermissions:\n              - \"get\"\n              - \"list\"\n    ```\n\nTry the [Azure IAM tutorial](https://docs.otterize.com/features/azure-iam/tutorials/azure-iam-aks) to learn more.\n\n### Google Cloud IAM\n\nThe intents operator, together with the [credentials operator](https://github.com/otterize/credentials-operator), enables the intent-based declarative management of Google Cloud service accounts and policies.\n\nTo enable Google Cloud access for a pod, follow these steps:\n\n1. Label a pod to have an GCP service account created for it:\n\n    ```yaml\n    metadata:\n     labels:\n      \"credentials-operator.otterize.com/create-gcp-sa\": \"true\"\n    ```\n\n2. Declare ClientIntents to specify which GCP resources it needs access to:\n\n    ```yaml\n    apiVersion: k8s.otterize.com/v1alpha3\n    kind: ClientIntents\n    metadata:\n      name: server\n    spec:\n      service:\n        name: server\n        calls:\n          # The GCP resource name\n          # Wildcards can be used in the end of the resource name to match multiple and nested resources\n          - name: projects/_/buckets/otterize-demo-bucket*\n            type: gcp\n            # one or more GCP Roles that will be provided to the specified resources\n            gcpPermissions:\n              - \"storage.admin\"\n            # Multiple call definitions can be defined for a single service.\n          - name: projects/_/buckets/otterize-read-only-bucket*\n            type: gcp\n            gcpPermissions:\n              - \"storage.objectViewer\"\n    ```\n\nTry the [GCP IAM tutorial](https://docs.otterize.com/features/gcp-iam/tutorials/gcp-iam-gke) to learn more.\n\n### Otterize for PostgreSQL \u0026 MySQL\n\nOtterize automates PostgreSQL \u0026 MySQL access management and secrets for your workloads, all in Kubernetes.\n\nHere is how:\n\n1. Annotate a pod, requesting a user and a password to be provisioned and bound to the pod, using the following annotation:\n\n    ```yaml\n    credentials-operator.otterize.com/user-password-secret-name: booking-service-secret`\n    ```\n\n2. Apply a PostgreSQLServerConfig or a MySQLServerConfig to the cluster, specifying the database name, user, and password.\n\n    ```yaml\n    apiVersion: k8s.otterize.com/v1alpha3\n    kind: PostgreSQLServerConfig\n    metadata:\n      name: bookings\n    spec:\n      address: db.bookings-database.svc.cluster.local:5432\n      credentials:\n        username: admin\n        password: password\n    ```\n\n3. Declare your workload’s ClientIntents, specifying desired permissions.\n\n    ```yaml\n    apiVersion: k8s.otterize.com/v1alpha3\n    kind: ClientIntents\n    metadata:\n      name: booking-service\n      namespace: flight-search\n    spec:\n      service:\n        name: booking-service\n      calls:\n        - name: bookings\n          type: database\n          databaseResources:\n            - databaseName: bookings-db\n              table: users\n              operations:\n                - SELECT\n            - databaseName: bookings-db\n              table: products\n              operations:\n                - ALL\n    ```\n\nOtterize then creates a user and matching grants on the target database.\n\nTry the [Just-in-time PostgreSQL users \u0026 access](https://docs.otterize.com/features/postgresql/tutorials/postgres) or [Just-in-time MySQL users \u0026 access](https://docs.otterize.com/features/mysql/tutorials/mysql) tutorials to learn more.\n\n### Kafka mTLS \u0026 ACLs\n\nThe intents operator automatically creates, updates, and deletes ACLs in Kafka clusters running within your Kubernetes cluster.\nIt works with the [credentials operator](https://github.com/otterize/credentials-operator) to automatically:\n\n* Establish pod service identities.\n* Generate trusted credentials for each client service.\n* Deliver the credentials to the pod's containers within a locally-mounted volume.\n\nWith Kafka, you can also control access to individual topics, like so:\n\n```yaml\napiVersion: k8s.otterize.com/v1alpha3\nkind: ClientIntents\nmetadata:\n  name: kafka-sample\nspec:\n  service:\n    name: my-client\n  calls:\n    - name: kafka-server\n      type: kafka\n      kafkaTopics:\n        - name: orders\n          operations: [ produce ]\n```\n\nRead more about it in the [secure Kafka access tutorial](https://docs.otterize.com/quick-tutorials/k8s-kafka-mtls).\n\n### Istio AuthorizationPolicy\n\nThe intents operator automatically creates, updates and deletes Istio authorization policies, automatically looks up service accounts for client pods and labels server pods, to reflect precisely the client-to-server calls declared in client intents files.\n\nThe intents operator can also be configured to process client intents *without* creating and managing network policies, to provide visibility on what would happen once enforcement via Istio authorization policy is activated. More information can be found in the [shadow vs active enforcement documentation](https://docs.otterize.com/shadow-vs-active-enforcement).\n\nIn the example above, the `my-client` service intends to call the `web-server`. When the CRD is applied through `kubectl apply`, the intents operator labels the `web-server` pod, looks up `my-client`'s service account, and creates an authorization policy for the `web-server` that references the service account for `my-client` and allows calls to the `web-server` from the `my-client`.\n\nThe intents operator uses the resolved identity as the service name, and combines it with the namespace of the pod and hashed to form the value of the label `intents.otterize.com/server`.\nThis label is used as a selector for servers in Istio authorization policies. The same algorithm is used to look up the client from the service name in the client intents, for whom the service account is looked up.\n\nFinally, an Istio authorization policy is created that allows communication between the client's service account and the server. If the service account covers clients other than the one requested, an event is generated on the ClientIntents to warn about this, and this appears as a warning on Otterize Cloud.\n\nRead more about it in the [Istio AuthorizationPolicy tutorial](https://docs.otterize.com/features/istio/tutorials/k8s-istio-authorization-policies).\n\n### Identities\n\nPods in the cluster are dynamically labeled with their owner's identity. If a `ReplicaSet` named `my-client` owns 5 pods\nand a `Deployment` named `my-server` owns 3 pods, and we enable `my-client` \u0026rarr; `my-server` access via `ClientIntents`, all 5\nsource pods would be able to access all 3 target pods.\n\nPod identities can be overridden by setting the value of the custom annotation `intents.otterize.com/service-name`\nto the desired service name. This is useful, for example, for pods without any owner.\n\n## Bootstrapping\n\nTo bootstrap client intents files for the services running in your cluster, you can use the [Otterize network\nmapper](https://github.com/otterize/network-mapper), which automatically detects pod-to-pod calls.\n\n## Read more\n\nThe Otterize intents operator is a part of [Otterize OSS](https://otterize.com/open-source)\nand is an implementation of [intent-based access control](https://otterize.com/ibac).\n\n## Development\n\nRun the `make` command inside `src/operator` directory. Some useful commands are:\n\n* `make build` to compile the go code.\n* `make deploy` to generate Kubernetes Deployment object which deploys the project to your local cluster.\n\nTo create a local Docker image, execute `make docker-build-local`, and deploy it to your local cluster using `make deploy-local`.\nFor utilizing the locally built Docker image on Minikube running on a VM like macOS arm64, use `make minikube-push`.\n\n## Contributing\n\n1. Feel free to fork and open a pull request! Include tests and document your code in [Godoc style](https://go.dev/blog/godoc)\n2. In your pull request, please refer to an existing issue or open a new one.\n3. Changes to Kubernetes objects will make changes to the Helm chart in the [helm-charts repo](https://github.com/otterize/helm-charts),\nwhich is a submodule in this repository, so you'll need to open a PR there as well.\n4. See our [Contributor License Agreement](https://github.com/otterize/cla/).\n\n## Slack\n\nTo join the conversation, ask questions, and engage with other users, join the Otterize Slack!\n\n[![button](https://i.ibb.co/vwRP6xK/Group-3090-2.png)](https://joinslack.otterize.com)\n\n## Usage telemetry\n\nThe operator reports anonymous usage information back to the Otterize team, to help the team understand how the software is used in the community and what aspects users find useful. No personal or organizational identifying information is transmitted in these metrics: they only reflect patterns of usage. You may opt out at any time through a single configuration flag.\n\nTo **disable** sending usage information:\n\n* Via the Otterize OSS Helm chart: `--set global.telemetry.enabled=false`.\n* Via an environment variable: `OTTERIZE_TELEMETRY_ENABLED=false`.\n* If running an operator directly: `--telemetry-enabled=false`.\n\nIf the `telemetry` flag is omitted or set to `true`, telemetry will be enabled: usage information will be reported.\n\nRead more about it in the [Usage telemetry Documentation](https://docs.otterize.com/otterize-oss/usage-telemetry)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fotterize%2Fintents-operator","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fotterize%2Fintents-operator","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fotterize%2Fintents-operator/lists"}