Fine-grained identity and access management control from Kubernetes to OCI NoSQL Tables
Dario Vega
Product Manager @Oracle ?? OSS | noSQL | inMemory | OCI | cloud-native | serverless | Architecture | Development
Oracle NoSQL Database Cloud Service uses Oracle Cloud Infrastructure Identity and Access Management, which enables you to create user accounts and control access to cloud resources. You can give users permission to inspect, read, use, or manage NoSQL tables for Oracle NoSQL. Authentication methods are available for API key-based, Token-based Authentication, Instance Principal, and Resource Principal. The Oracle NoSQL Database SDKs allow you to provide the credentials for an application using any of these authentication methods.
Oracle NoSQL Database Cloud service has three different resource types: nosql-tables, nosql-rows, and nosql-indexes. It also has one aggregate resource called nosql-family. Policies are created that allow a group to work in specific ways with resources, such as nosql-tables in a particular compartment. All NoSQL tables belong to a defined compartment.
In Kubernetes, a workload is an application running on a Kubernetes cluster. A workload can be one application component running inside a single pod or several components running inside a set of pods that work together—all the pods in the workload run in the same namespace.
When applications require access to OCI resources, Workload Identity enables you to write OCI IAM policies scoped to the Kubernetes service account associated with application pods. This feature allows the applications running inside these pods to directly access the OCI API based on the permissions provided by the policies. The OCI Audit service also automatically tracks all Kubernetes workloads' API calls from your cluster.
With Workload Identity, you no longer need to store credentials as secrets in your Kubernetes cluster or rely on OCI dynamic groups for worker node policy-driven access to OCI resources and, more specifically, access to your NoSQL Tables.
We are excited to announce the support for OKE Workload Identity in all our NoSQL SDKs.
To grant all the pods in workload access to OCI resources
1) Configure your Kubernetes cluster
kubectl create namespace <namespace-name>
kubectl create serviceaccount <service-account-name> --namespace <namespace-name>
2) Define an IAM policy to grant the workload resource access to other OCI resources.
领英推荐
Allow any-user to manage nosql-family in compartment <compartment-name>
where all {
request.principal.type = 'workload',
request.principal.namespace = '<namespace-name>',
request.principal.service_account = '<service-account-name>',
request.principal.cluster_id = 'ocid1.cluster.oc1.___________________________'i
}
3) Download and configure the appropriate NoSQL SDK for the language in which the application is written.
4) Update the application's deployment spec (filename.yaml) to specify that every pod in the workload is to use the service account.
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
serviceAccountName: <service-account-name>
automountServiceAccountToken: true
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
5) Deploy the application :
kubectl create -f <filename.yaml>
Customer use case and benefits
Imagine that you have a containerized application that needs to access application data in your Oracle NOSQL Tables, and your Security team requires that you follow the principle of least privilege to access cloud resources from your Kubernetes cluster without storing secrets.
So that you know, your current solution uses instance principals. Instance principals enable worker nodes to be authorized actors (or principals) to perform actions on your Oracle NoSQL Tables. Using instance principals, you can isolate workloads across node pools with different OCI dynamic groups so that pods in each node pool have minimal privileges. However, this solution forces you to distribute pods to specific worker nodes to ensure that the least privileged access to the NoSQL tables is restricted to authorized pods.
With Workload Identity, you can now specify access at the pod level, enabling you to run pods on any worker node in your cluster. This means you need fewer worker nodes, decreasing your Kubernetes cluster's total cost of ownership (TCO). But remember that you can continue using node pools to Optimize your workload and adapt to Changes.