🤯 Gradually deploy network policies without risk of downtime.Learn how

IBAC: Intent-based access control

The declarative way to authorization

  • Secure access is important.

    • Thick Right Arrow
      Ensure appropriate use of shared infrastructure and services.
    • Thick Right Arrow
      Prevent security incidents with a zero-trust architecture.
    • Thick Right Arrow
      Implement controls to meet compliance needs.
    • Thick Right Arrow
      Minimize the blast radius of mistakes.
  • Secure access mechanisms are hard.

    • Thick Right Arrow
      ACLs: create and maintain per client/server.
    • Thick Right Arrow
      Certificates & tokens: issue, distribute, and renew.
    • Thick Right Arrow
      Network policies: configure and maintain.
    • Thick Right Arrow
      Access tickets: open, validate, and implement.

Can secure access mechanisms be made easier? Or… can they just disappear?

If developers just declare what their code intends to access, then an automated system can configure security controls to allow this access, while blocking any unintended access.

So what is an intents file?
Otterize Intent File Demo

Just as Kubernetes YAML manifests describe the target state needed, in IBAC you use YAML intents files to declare what services your code intends to access.

The orchestrator configures the existing access controls to allow this access, and only this access. No need to manually configure access controls, generate certificates, deploy tokens, or open access tickets.

IBAC is a client-oriented approach to access control
Otterize IBAC workflow flow chart
  • Thick Right Arrow
    “Who needs access” is always driven by the client: the client’s developers know what services they intend to call when they write the code.
  • Thick Right Arrow
    The information lives in the client code repo so it’s local, consistent, and approved.
  • Thick Right Arrow
    Server permissions are derived from client intents.
IBAC means access is more secure, not only easier
Float question in white background and black rounded shadow
  • Thick Right Arrow
    Yes, because it was reviewed and approved when the code was reviewed and approved.
  • Thick Right Arrow
    Yes, because permissions are reduced to the minimum needed for the approved intents.
Float question in white background and black rounded shadow number 2
  • Thick Right Arrow
    Yes, because they’re configured automatically using best practices.
  • Thick Right Arrow
    Yes, because stronger mechanisms can now be used as they don’t cause friction.
Otterize security model

The advantages of IBAC

  • 1

    IBAC is shift-left for access control: putting the power in the hands of devs, early in the code lifecycle, when it’s being built or changed.

  • 2

    Devs don’t need to wrestle with access controls, and they don’t need to be experts at security.

  • 3

    Platform engineers can implement access control mechanisms and integrate with Otterize to automate best-practice secure access.

Any more questions?