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.

Sign up for GitHub

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

Support for WorkloadIdentity #32

Merged
merged 1 commit into from
Nov 14, 2023
+20 −1
Merged

Support for WorkloadIdentity #32

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
21 changes: 20 additions & 1 deletion GettingStarted.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,6 +10,7 @@ The native ingress controller itself is lightweight process and pushes all the r
* [Principal Credential Setup](#principal-credential-setup)
+ [Instance Principal](#instance-principal)
+ [User Principal](#user-principal)
+ [Workload Identity](#workload-identity)
+ [Access Policies](#access-policies)
* [Cert Manager](#cert-manager)
* [Deployment](#deployment)
Expand Down Expand Up @@ -59,9 +60,10 @@ Policy documentation for setting up security rules for load balancer:
For native ingress controller to access other dependent services and perform operations, we need to configure it with a principal credential.
We can grant permissions to this principal which will be inherited by native ingress controller.

Two types of principal that are supported:
Different types of principal that are supported:
* [Instance Principal](#instance-principal)
* [User Principal](#user-principal)
* [Workload Identity](#workload-identity)

#### Instance Principal
This is the default authentication type. It uses the instance identity where the controller is deployed on (worker node).
Expand Down Expand Up @@ -102,6 +104,23 @@ If the deployment is done via manifest templates update deployment container arg
- --v=4
```

#### Workload Identity
For workload identity, we have to use [Enhanced Clusters](https://confluence.oci.oraclecorp.com/display/OKE/Enhanced+Clusters), and follow the public documentation to setup policies - [Doc](https://docs.oracle.com/en-us/iaas/Content/ContEng/Tasks/contenggrantingworkloadaccesstoresources.htm)

We have added the support to enable this via the authType flag as follows:
```
authType: workloadIdentity
```
Also, internally we would need to update the resource principal version and region according to your deployment resource.
These can be passed as env variables under [deployment.yaml](helm/oci-native-ingress-controller/templates/deployment.yaml)
```
env:
- name: OCI_RESOURCE_PRINCIPAL_VERSION
value: "2.2"
- name: OCI_RESOURCE_PRINCIPAL_REGION
value: "us-ashburn-1"
```

#### Access Policies
Access to the resource should be explicitly granted using Policies for engaging ingress controller:
```
Expand Down
Loading