Cloud Native Security
Securing Access to Cloud Resources from K8S
Topics
Identities
Types of Identities that can be used for applications
1.
2.
Methods
The ways to secure a services: good, bad, the ugly.
3.
Extra
Cross Cloud Access through OpenID Connect
# Agenda
# CHAPTER 1
Identities
Also called principals and how to authorize access.
Kubernetes Identities
| Subjects (Identities) |
|---|
| Service Account |
| Users |
| Groups |
A subject or Kubernetes identity is granted permissions through a Role and a RoleBinding or ClusterRoleBinding.
Azure Identities
| Security Principals (Identities) |
|---|
| Service Principal |
| Users |
| Groups |
Azure added managed identities, which is a service principal whose life cycle is managed by Azure. There are two sub-types: user-assigned and system-assigned.
Role Assignment
| Security Principal | who |
| Role Definition | what you can do |
| Scope | where you can do it |
In Azure RBAC, you combine the above elements into a Role Assignment that has Actions and NotActions permissions.
Cloud Identities
| Principals (Identities) |
|---|
| Service Account |
| Google Account (user) |
| Google Group |
Principals are defined referenced using UPN (User Principal Name) [RFC 822] or <name>@<tree-name>. A Google Group is a collection of Google Accounts, often used as a distribution list within Gmail.
Policy Binding
| Identity | who |
| Role | what access |
| which resources |
In Google Cloud IAM, each Project will have a list of bindings that include a role and members (list of identities)
IAM Identities
| Identities |
|---|
| IAM role |
| IAM user |
| IAM user group |
Principals are defined referenced using UPN (User Principal Name) [RFC 822] or <name>@<tree-name>. A Google Group is a collection of Google Accounts, often used as a distribution list within Gmail.
Attach Policy
IAM identities are referenced using an ARN. Permissions are defined in a policy that is attached to an identity. EC2 instances can be associated to a role through an Instance Profile.
| Identity | who |
| Policy | what access |
| Policy | which resources |
# CHAPTER 2
Methods
The methods available for Kubernetes deployed applications across the cloud providers
Methods
Where to secure the service?
1. Node level using cloud identity
2. Service level using credentials
3. Pod level service account
Static Credentials
Why this are bad?
- credential leakage
- privilege escalation
- information disclosure
- non-repudiation
Node Level
Why is this bad?
Violates PoLP (Principal of Least Privilege).
All containers now have access to the cloud resource. Only use this method if read-only access, such as ECR/GCR/ACR container registries.
Service Account
This preferred method.
Authentication will happen through an external provider such as an OIDC (OpenID Connect) provider to grant access and allow the Pod through the service account impersonate the cloud identity and access the resource.
Workload Identity
# IMPLEMENTATIONS
IRSA
# IMPLEMENTATIONS
IAM Role for Service Account
# IMPLEMENTATIONS
AAD Pod Identity
AAD Pod Identity enables K8S applications to use Azure AD to allow access to the cloud resource.
# IMPLEMENTATIONS
Workload Identity
Azure is adding support for Workload Identity for AKS.
# Chapter 3
Extras
Cross Cloud Access and other topics.
Workload Identity
Federated
Access AWS or Azure resource from GKE.
w. other providers
IRSA
Access Google or Azure cloud resource from EKS.
Role trust to federated service that an alternative OpenID provider
# Chapter 3
Extras: Snippets
Snippets
AKS
az identity create --resource-group "${IDENTITY_RESOURCE_GROUP}" --name "${IDENTITY_NAME}"
# fetch identity client id from managed identity created earlier
IDENTITY_CLIENT_ID=$(az identity show --resource-group "${IDENTITY_RESOURCE_GROUP}" \
--name "${IDENTITY_NAME}" --query "clientId" --output tsv)
# fetch DNS id used to grant access to the managed identity
DNS_ID=$(az network dns zone show --name "${AZURE_DNS_ZONE}" \
--resource-group "${AZURE_DNS_ZONE_RESOURCE_GROUP}" --query "id" --output tsv)
az role assignment create --role "DNS Zone Contributor" \
--assignee "${IDENTITY_CLIENT_ID}" --scope "${DNS_ID}"