Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add AWS IAM on EKS tutorial #175

Merged
merged 3 commits into from
Nov 19, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 5 additions & 19 deletions docs/intent-based-access-control/README.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -3,30 +3,17 @@ sidebar_position: 7
title: 'IBAC: Intent-based access control'
---

At Otterize, we believe service-to-service access control should become not only *easy* but actually *transparent* to service developers. We believe that access should not only be self-serve — that it should happen without needing to go through any extra steps beyond what developers are already doing. And we believe that access control enforcement should be completely decoupled from the functional development of the software: that as the organization improves its security and compliance posture, developers should not need to revisit their working code.
At Otterize, we believe workload IAM should become not only *easy* but actually *transparent* to developers. We believe that access should not only be self-serve — that it should happen without needing to go through any extra steps beyond what developers are already doing. And we believe that access control enforcement should be completely decoupled from the functional development of the software: that as the organization improves its security and compliance posture, developers should not need to revisit their working code.

These are the principles of **intent-based access control (IBAC)**, a modern, declarative approach to granting access automatically, responsibly, and scalably. **The developer simply declares, in a *client intents file* alongside their code, what other services the code intends to call.** If the code passes review, so does its intents file, and access is granted automatically to make those calls, regardless of the type of call, the target infrastructure and location, and the enforcement mechanism. Credentials for declared access are automatically managed and supplied to the developer for use in their code, if needed. Any undeclared access is automatically blocked.
These are the principles of **intent-based access control (IBAC)**, a modern, declarative approach to granting access automatically, responsibly, and scalably. **The developer simply declares, in a `ClientIntents` custom resource alongside their code, what other services the code intends to call.** If the code passes review, so does its intents, and access is granted automatically to make those calls, regardless of the type of call, the target infrastructure and location, and the enforcement mechanism. Credentials for declared access are automatically managed and supplied to the service for use in their code, if needed. Any undeclared access is automatically blocked.

Here is an example of the client intents file for the `checkoutservice`.
It declares that it will call the `emailservice`, the `orderservice`, and the `ecomm-events` Kafka service.
It also provides more granular information for some of the calls:
```yaml
{@include: ../../static/resources/example-intents.yaml}
```

<details>
<summary>Intents file as a Kubernetes resource file</summary>
<div>

Here is the same intents file, now formatted as a Kubernetes custom resource file,
so it can be applied directly via `kubectl apply`:

It also provides more granular information for some of the calls, which you can optionally specify, like `HTTPResources`:
```yaml
{@include: ../../static/resources/example-intents-resource.yaml}
```

</div>
</details>

Intent-based access control realizes shift-left for access control. The necessary access is defined by the developer themselves declaring, when the code is created, what calls will be made. Nobody knows better than them what their code needs. And those declarations, living in source control as client intents files along with the code, stay in sync with the code — as opposed to access permissions that live elsewhere, e.g. on a server, where they’re likely to get stale rapidly. Intents are approved along with the code: if it makes sense to approve the code that makes the calls, it should make sense to approve access to what’s being called.

Expand Down Expand Up @@ -72,8 +59,7 @@ To implement IBAC across heterogeneous environments, IBAC must also solve for th

### IBAC and security

Security controls that don't get implemented don't help. By building service-to-service access
control concerns into the building of the software &mdash; capturing the intent at design time,
Security controls that don't get implemented don't help. By shifting-left the access controls - &mdash; capturing the intent at design time,
*streamlining* for developers the access to secured services, integrating access reviews into existing
code review processes, and automating access control configuration at deploy time &mdash; IBAC drives adoption
of security controls and a zero-trust architecture within the engineering team.
Expand All @@ -86,7 +72,7 @@ It captures and makes explicit the *intents* of developers and their the code,
enables processes for acting on those intents to allow or deny access,
and makes explicit the enforcement that's actually put in place.
One org might decide that it's best to automatically approve all intents once they undergo code review and apply
them to a staging environment so they can be tested, but require explicit secops approval on any new intent before
them to a staging environment so they can be tested, but require explicit SecOps approval on any new intent before
it's applied to production. Another org might decide to require approvals only on some servers (i.e. intents targeted
at those servers), and to track them by filing issues against the server teams' ticketing system.
And a third org might decide to enforce access controls on certain servers in staging to make sure intents are declared,
Expand Down
6 changes: 3 additions & 3 deletions docs/quickstart/access-control/aws-eks-cni-mini.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -51,9 +51,9 @@ addons:
- name: kube-proxy

managedNodeGroups:
- name: x86-al2-on-demand
- name: small-on-demand
amiFamily: AmazonLinux2
instanceTypes: [ "m6i.xlarge", "m6a.xlarge" ]
instanceTypes: [ "t3.large" ]
minSize: 0
desiredCapacity: 2
maxSize: 6
Expand All @@ -66,7 +66,7 @@ managedNodeGroups:
team: "eks"
```
Then run the following command to create your AWS cluster:
Then run the following command to create your AWS cluster. [Don't have eksctl? Install it now.](https://eksctl.io/installation/)
```shell
eksctl create cluster -f cluster-config.yaml
Expand Down
Loading
Loading