IBAC: Intent-based access control
The declarative way to authorization
Secure access is important.
Ensure appropriate use of shared infrastructure and services.- Prevent security incidents with a zero-trust architecture.
- Implement controls to meet compliance needs.
- Minimize the blast radius of mistakes.
Secure access mechanisms are hard.
- ACLs: create and maintain per client/server.
- Certificates & tokens: issue, distribute, and renew.
- Network policies: configure and maintain.
- 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?
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
- “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.
- The information lives in the client code repo so it’s local, consistent, and approved.
- Server permissions are derived from client intents.
IBAC means access is more secure, not only easier
- Yes, because it was reviewed and approved when the code was reviewed and approved.
- Yes, because permissions are reduced to the minimum needed for the approved intents.
- Yes, because they’re configured automatically using best practices.
- Yes, because stronger mechanisms can now be used as they don’t cause friction.
So what is an intents file?
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
- “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.
- The information lives in the client code repo so it’s local, consistent, and approved.
- Server permissions are derived from client intents.
IBAC means access is more secure, not only easier
- Yes, because it was reviewed and approved when the code was reviewed and approved.
- Yes, because permissions are reduced to the minimum needed for the approved intents.
- Yes, because they’re configured automatically using best practices.
- Yes, because stronger mechanisms can now be used as they don’t cause friction.
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.