AKS Secure Baseline - Adding RBAC path (#204)

* AKS Secure Baseline - Addind RBAC path * making readme steps more clear, adding validation step for reader role, reintroducing yaml files for direct Azure AD assignments * Role assignment scope in arm and reader group creation step fixed * Fixed wording in readme, regarding Azure RBAC integration, fixed cluster-stamp deployment file so it decides weather to use Azure AD direct integration or Azure RBAC association, through Role assignments * Added expected result to the aad step * Typo fixed on namespace, added parameter to prod params file, added new AKS service cluster role assignment * fixed line endings * fixed line endings * Update 10-validation.md Co-authored-by: Chad Kittel <chad.kittel@gmail.com> * Update 03-aad.md Co-authored-by: Chad Kittel <chad.kittel@gmail.com> * Update 05-aks-cluster.md Co-authored-by: Chad Kittel <chad.kittel@gmail.com> * Update 03-aad.md Co-authored-by: Chad Kittel <chad.kittel@gmail.com> * Update 03-aad.md Co-authored-by: Chad Kittel <chad.kittel@gmail.com> * Update 03-aad.md Co-authored-by: Chad Kittel <chad.kittel@gmail.com> * added new role to admin group * Update 03-aad.md Co-authored-by: Chad Kittel <chad.kittel@gmail.com> * Update 10-validation.md Co-authored-by: Chad Kittel <chad.kittel@gmail.com> * Update 03-aad.md Co-authored-by: Chad Kittel <chad.kittel@gmail.com> * Update 03-aad.md Co-authored-by: Chad Kittel <chad.kittel@gmail.com> Co-authored-by: Chad Kittel <chad.kittel@gmail.com>
mspnp · Jun 17, 2021 · f2fe15f · f2fe15f
1 parent 34ff19b
commit f2fe15f
Show file tree

Hide file tree

Showing 8 changed files with 250 additions and 143 deletions.
diff --git a/03-aad.md b/03-aad.md
@@ -1,72 +1,90 @@
-# Prep for Azure Active Directory Integration
-
-In the prior step, you [generated the user-facing TLS certificate](./02-ca-certificates.md); now we'll prepare Azure AD for Kubernetes role-based access control (RBAC). This will ensure you have an Azure AD security group(s) and user(s) assigned for group-based Kubernetes control plane access.
-
-## Expected results
-
-Following the steps below you will result in an Azure AD configuration that will be used for Kubernetes control plane (Cluster API) authorization.
-
-| Object                         | Purpose                                                 |
-|--------------------------------|---------------------------------------------------------|
-| A Cluster Admin Security Group | Will be mapped to `cluster-admin` Kubernetes role.      |
-| A Cluster Admin User           | Represents at least one break-glass cluster admin user. |
-| Cluster Admin Group Membership | Association between the Cluster Admin User(s) and the Cluster Admin Security Group. |
-| _Additional Security Groups_   | _Optional._ A security group (and its memberships) for the other built-in and custom Kubernetes roles you plan on using. |
-
-## Steps
-
-> :book: The Contoso Bicycle Azure AD team requires all admin access to AKS clusters be security-group based. This applies to the new Secure AKS cluster that is being built for Application ID a0008 under the BU001 business unit. Kubernetes RBAC will be AAD-backed and access granted based on a user's AAD group membership.
-
-1. Query and save your Azure subscription's tenant id.
-
-   ```bash
-   TENANTID_AZURERBAC=$(az account show --query tenantId -o tsv)
-   ```
-
-1. Playing the role as the Contoso Bicycle Azure AD team, login into the tenant where Kubernetes Cluster API authorization will be associated with.
-
-   ```bash
-   az login -t <Replace-With-ClusterApi-AzureAD-TenantId> --allow-no-subscriptions
-   TENANTID_K8SRBAC=$(az account show --query tenantId -o tsv)
-   ```
-
-1. Create/identify the Azure AD security group that is going to map to the [Kubernetes Cluster Admin](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) role `cluster-admin`.
-
-   If you already have a security group that is appropriate for your cluster's admin service accounts, use that group and skip this step. If using your own group or your Azure AD administrator created one for you to use; you will need to update the group name throughout the reference implementation.
-
-   ```bash
-   export AADOBJECTNAME_GROUP_CLUSTERADMIN=cluster-admins-bu0001a000800
-   export AADOBJECTID_GROUP_CLUSTERADMIN=$(az ad group create --display-name $AADOBJECTNAME_GROUP_CLUSTERADMIN --mail-nickname $AADOBJECTNAME_GROUP_CLUSTERADMIN --description "Principals in this group are cluster admins in the bu0001a000800 cluster." --query objectId -o tsv)
-   ```
-
-1. Create a "break-glass" cluster administrator user for your AKS cluster.
-
-   > :book: The organization knows the value of having a break-glass admin user for their critical infrastructure. The app team requests a cluster admin user and Azure AD Admin team proceeds with the creation of the user in Azure AD.
-
-   ```bash
-   export TENANTDOMAIN_K8SRBAC=$(az ad signed-in-user show --query 'userPrincipalName' -o tsv | cut -d '@' -f 2 | sed 's/\"//')
-   export AADOBJECTNAME_USER_CLUSTERADMIN=bu0001a000800-admin
-   export AADOBJECTID_USER_CLUSTERADMIN=$(az ad user create --display-name=${AADOBJECTNAME_USER_CLUSTERADMIN} --user-principal-name ${AADOBJECTNAME_USER_CLUSTERADMIN}@${TENANTDOMAIN_K8SRBAC} --force-change-password-next-login --password ChangeMebu0001a0008AdminChangeMe --query objectId -o tsv)
-   ```
-
-1. Add the cluster admin user(s) to the cluster admin security group.
-
-   > :book: The recently created break-glass admin user is added to the Kubernetes Cluster Admin group from Azure AD. After this step the Azure AD Admin team will have finished the app team's request.
-
-   ```bash
-   az ad group member add -g $AADOBJECTID_GROUP_CLUSTERADMIN --member-id $AADOBJECTID_USER_CLUSTERADMIN
-   ```
-
-   This object ID will be used later while creating the cluster. This way, once the cluster gets deployed the new group will get the proper Cluster Role bindings in Kubernetes.
-
-1. Set up groups to map into other Kubernetes Roles. _Optional, fork required._
-
-   > :book: The team knows there will be more than just cluster admins that need group-managed access to the cluster. Out of the box, Kubernetes has other roles like _admin_, _edit_, and _view_ which can also be mapped to Azure AD Groups for use both at namespace and at the cluster level.
-
-   In the [`cluster-rbac.yaml` file](./cluster-manifests/cluster-rbac.yaml) and the various namespaced [`rbac.yaml files`](./cluster-manifests/cluster-baseline-settings/rbac.yaml), you can uncomment what you wish and replace the `<replace-with-an-aad-group-object-id...>` placeholders with corresponding new or existing AD groups that map to their purpose for this cluster or namespace. You do not need to perform this action for this walk through; they are only here for your reference.
-
-   :bulb: Alternatively/Additionally, you can make some of these group associations to [Azure RBAC roles](https://docs.microsoft.com/azure/aks/manage-azure-rbac). At the time of this writing, this feature is still in _preview_. This reference implementation has not been validated with that feature.
-
-### Next step
-
-:arrow_forward: [Deploy the hub-spoke network topology](./04-networking.md)
+# Prep for Azure Active Directory Integration
+
+In the prior step, you [generated the user-facing TLS certificate](./02-ca-certificates.md); now we'll prepare Azure AD for Kubernetes role-based access control (RBAC). This will ensure you have an Azure AD security group(s) and user(s) assigned for group-based Kubernetes control plane access.
+
+## Expected results
+
+Following the steps below you will result in an Azure AD configuration that will be used for Kubernetes control plane (Cluster API) authorization.
+
+| Object                             | Purpose                                                 |
+|------------------------------------|---------------------------------------------------------|
+| A Cluster Admin Security Group     | Will be mapped to `cluster-admin` Kubernetes role.      |
+| A Cluster Admin User               | Represents at least one break-glass cluster admin user. |
+| Cluster Admin Group Membership     | Association between the Cluster Admin User(s) and the Cluster Admin Security Group. |
+| A Namespace Reader Security Group  | Represents users that will have read-only access to a specific namespace in the cluster. |
+| _Additional Security Groups_       | _Optional._ A security group (and its memberships) for the other built-in and custom Kubernetes roles you plan on using. |
+
+## Steps
+
+> :book: The Contoso Bicycle Azure AD team requires all admin access to AKS clusters be security-group based. This applies to the new AKS cluster that is being built for Application ID a0008 under the BU0001 business unit. Kubernetes RBAC will be AAD-backed and access granted based on users' AAD group membership(s).
+
+1. Query and save your Azure subscription's tenant id.
+
+   ```bash
+   TENANTID_AZURERBAC=$(az account show --query tenantId -o tsv)
+   ```
+
+1. Playing the role as the Contoso Bicycle Azure AD team, login into the tenant where Kubernetes Cluster API authorization will be associated with.
+
+   ```bash
+   az login -t <Replace-With-ClusterApi-AzureAD-TenantId> --allow-no-subscriptions
+   TENANTID_K8SRBAC=$(az account show --query tenantId -o tsv)
+   ```
+
+1. Create/identify the Azure AD security group that is going to map to the [Kubernetes Cluster Admin](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) role `cluster-admin`.
+
+   If you already have a security group that is appropriate for your cluster's admin service accounts, use that group and skip this step. If using your own group or your Azure AD administrator created one for you to use; you will need to update the group name and ID throughout the reference implementation.
+
+   ```bash
+   export AADOBJECTID_GROUP_CLUSTERADMIN=$(az ad group create --display-name 'cluster-admins-bu0001a000800' --mail-nickname 'cluster-admins-bu0001a000800' --description "Principals in this group are cluster admins in the bu0001a000800 cluster." --query objectId -o tsv)
+   ```
+
+   This Azure AD group object ID will be used later while creating the cluster. This way, once the cluster gets deployed the new group will get the proper Cluster Role bindings in Kubernetes.
+
+1. Create a "break-glass" cluster administrator user for your AKS cluster.
+
+   > :book: The organization knows the value of having a break-glass admin user for their critical infrastructure. The app team requests a cluster admin user and Azure AD Admin team proceeds with the creation of the user in Azure AD.
+
+   ```bash
+   export TENANTDOMAIN_K8SRBAC=$(az ad signed-in-user show --query 'userPrincipalName' -o tsv | cut -d '@' -f 2 | sed 's/\"//')
+   export AADOBJECTNAME_USER_CLUSTERADMIN=bu0001a000800-admin
+   export AADOBJECTID_USER_CLUSTERADMIN=$(az ad user create --display-name=${AADOBJECTNAME_USER_CLUSTERADMIN} --user-principal-name ${AADOBJECTNAME_USER_CLUSTERADMIN}@${TENANTDOMAIN_K8SRBAC} --force-change-password-next-login --password ChangeMebu0001a0008AdminChangeMe --query objectId -o tsv)
+   ```
+
+1. Add the cluster admin user(s) to the cluster admin security group.
+
+   > :book: The recently created break-glass admin user is added to the Kubernetes Cluster Admin group from Azure AD. After this step the Azure AD Admin team will have finished the app team's request.
+
+   ```bash
+   az ad group member add -g $AADOBJECTID_GROUP_CLUSTERADMIN --member-id $AADOBJECTID_USER_CLUSTERADMIN
+   ```
+
+1. Create/identify the Azure AD security group that is going to be a namespace reader.
+
+   ```bash
+   export AADOBJECTID_GROUP_A0008_READER=$(az ad group create --display-name 'cluster-ns-a0008-readers-bu0001a000800' --mail-nickname 'cluster-ns-a0008-readers-bu0001a000800' --description "Principals in this group are readers of namespace a0008 in the bu0001a000800 cluster." --query objectId -o tsv)
+   ```
+
+## Kubernetes RBAC backing store
+
+AKS supports backing Kubernetes with Azure AD in two different modalities. One is direct association between Azure AD and Kubernetes `ClusterRoleBindings`/`RoleBindings` in the cluster. This is possible no matter if the Azure AD tenant you wish to use to back your Kubernetes RBAC is the same or different than the Tenant backing your Azure resources. If however the tenant that is backing your Azure resources (Azure RBAC source) is the same tenant you plan on using to back your Kubernetes RBAC, then instead you can add a layer of indirection between Azure AD and your cluster by using Azure RBAC instead of direct cluster `RoleBinding` manipulation.  When performing this walkthrough, you may have had no choice but to associate the cluster with another tenant (due to the elevated permissions necessary in Azure AD to manage groups and users); but when you take this to production be sure you're using Azure RBAC as your Kubernetes RBAC backing store if the tenants are the same. Both cases still leverage integrated authentication between Azure AD and AKS, Azure RBAC simply elevates this control to Azure RBAC instead of direct yaml-based management within the cluster which usually will align better with your organization's governance strategy.
+
+### Azure RBAC _[Preferred]_
+
+If you are using a single tenant for this walkthrough, the cluster deployment step later will take care of the necessary role assignments for the groups created above.  Specifically, in the above steps, you created the Azure AD security group `cluster-ns-a0008-readers-bu0001a000800` that is going to be a namespace reader in namespace `a0008` and the Azure AD security group `cluster-admins-bu0001a000800` is is going to contain cluster admins. Those group Object IDs will be associated to the 'Azure Kubernetes Service RBAC Reader' and 'Azure Kubernetes Service RBAC Cluster Admin' RBAC role respectively, scoped to their proper level within the cluster.
+
+Using Azure RBAC as your authorization approach is ultimately preferred as it allows for the unified management and access control across Azure Resources, AKS, and Kubernetes resources.  At the time of this writing there are four [Azure RBAC roles](https://docs.microsoft.com/azure/aks/manage-azure-rbac#create-role-assignments-for-users-to-access-cluster) that represent typical cluster access patterns.
+
+### Direct Kubernetes RBAC management _[Alternative]_
+
+If you instead wish to not use Azure RBAC as your Kubernetes RBAC authorization mechanism, either due to the intentional use of disparate Azure AD tenants or another business justifications, you can then manage these RBAC assignments via direct `ClusterRoleBinding`/`RoleBinding` associations. This method is also useful when the four Azure RBAC roles are not granular enough for your desired permission model.
+
+1. Set up additional Kubernetes RBAC associations. _Optional, fork required._
+
+   > :book:  The team knows there will be more than just cluster admins that need group-managed access to the cluster. Out of the box, Kubernetes has other roles like _admin_, _edit_, and _view_ which can also be mapped to Azure AD Groups for use both at namespace and at the cluster level. Likewise custom roles can be created which need to be mapped to Azure AD Groups.
+
+   In the [`cluster-rbac.yaml` file](./cluster-manifests/cluster-rbac.yaml) and the various namespaced [`rbac.yaml files`](./cluster-manifests/cluster-baseline-settings/rbac.yaml), you can uncomment what you wish and replace the `<replace-with-an-aad-group-object-id...>` placeholders with corresponding new or existing Azure AD groups that map to their purpose for this cluster or namespace. **You do not need to perform this action for this walkthrough**; they are only here for your reference.
+
+### Next step
+
+:arrow_forward: [Deploy the hub-spoke network topology](./04-networking.md)
diff --git a/05-aks-cluster.md b/05-aks-cluster.md
@@ -30,7 +30,7 @@ Now that the [hub-spoke network is provisioned](./04-networking.md), the next st
 
    ```bash
    # [This takes about 15 minutes.]
-   az deployment group create -g rg-bu0001a0008 -f cluster-stamp.json -p targetVnetResourceId=${RESOURCEID_VNET_CLUSTERSPOKE} clusterAdminAadGroupObjectId=${AADOBJECTID_GROUP_CLUSTERADMIN} k8sControlPlaneAuthorizationTenantId=${TENANTID_K8SRBAC} appGatewayListenerCertificate=${APP_GATEWAY_LISTENER_CERTIFICATE} aksIngressControllerCertificate=${AKS_INGRESS_CONTROLLER_CERTIFICATE_BASE64}
+   az deployment group create -g rg-bu0001a0008 -f cluster-stamp.json -p targetVnetResourceId=${RESOURCEID_VNET_CLUSTERSPOKE} clusterAdminAadGroupObjectId=${AADOBJECTID_GROUP_CLUSTERADMIN} a0008NamespaceReaderAadGroupObjectId=${AADOBJECTID_GROUP_A0008_READER} k8sControlPlaneAuthorizationTenantId=${TENANTID_K8SRBAC} appGatewayListenerCertificate=${APP_GATEWAY_LISTENER_CERTIFICATE} aksIngressControllerCertificate=${AKS_INGRESS_CONTROLLER_CERTIFICATE_BASE64}
    ```
 
    > Alteratively, you could have updated the [`azuredeploy.parameters.prod.json`](./azuredeploy.parameters.prod.json) file and deployed as above, using `-p "@azuredeploy.parameters.prod.json"` instead of providing the individual key-value pairs.

diff --git a/10-validation.md b/10-validation.md
@@ -27,6 +27,16 @@ This section will help you to validate the workload is exposed correctly and res
 
    > :bulb: A TLS warning will be present due to using a self-signed certificate.
 
+## Validate reader access to the a0008 namespace. _Optional._
+
+When setting up [Azure AD security groups](./03-aad.md) you created a group to be used as a "reader" for the namespace a0008. If you want to experience this RBAC example, you'll want to add a user to that group.
+
+If Azure RBAC is your cluster's Kubernetes RBAC backing store, then that is all that is needed.
+
+If instead Kubernetes RBAC is backed directly by Azure AD, then you'll need to ensure that you've updated and applied the [`rbac.yaml`](./cluster-manifests/a0008/rbac.yaml) according to the instructions found at the end of the [Azure AD configuration page](./03-aad.md).
+
+No matter which backing store you use, the user assigned to the group will then be able to `az aks get-credentials` to the cluster and you can validate that user is limited to a _read only_ view of the a0008 namespace.
+
 ## Validate Web Application Firewall functionality
 
 Your workload is placed behind a Web Application Firewall (WAF), which has rules designed to stop intentionally malicious activity. You can test this by triggering one of the built-in rules with a request that looks malicious.

diff --git a/azuredeploy.parameters.prod.json b/azuredeploy.parameters.prod.json
@@ -14,6 +14,9 @@
     "clusterAdminAadGroupObjectId": {
       "value": "[guid--security-group-objectid-that-will-become-cluster-admin]"
     },
+    "a0008NamespaceReaderAadGroupObjectId": {
+      "value": "[guid--security-group-objectid-that-will-become-namespace-a0008-reader]"
+    },
     "k8sControlPlaneAuthorizationTenantId": {
       "value": "[guid--your-cluster-APIs-authorization-tenant-ID]"
     },

diff --git a/cluster-manifests/a0008/rbac.yaml b/cluster-manifests/a0008/rbac.yaml
@@ -1,3 +1,6 @@
+# This file is exclusively to be used when you are using Azure AD direct assignment for Kubertnetes RBAC 
+# and NOT when you are using Azure RBAC as your Kubernetes RBAC backing store.
+#
 #  Map k8s user facing namespace roles to AAD groups: https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles
 #apiVersion: rbac.authorization.k8s.io/v1
 #kind: RoleBinding

diff --git a/cluster-manifests/cluster-baseline-settings/rbac.yaml b/cluster-manifests/cluster-baseline-settings/rbac.yaml
@@ -1,39 +1,42 @@
-#  Map k8s user facing namespace roles to AAD groups: https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles
-#apiVersion: rbac.authorization.k8s.io/v1
-#kind: RoleBinding
-#metadata:
-#  name: namespace-admin
-#  namespace: cluster-baseline-settings
-#roleRef:
-#  apiGroup: rbac.authorization.k8s.io
-#  kind: ClusterRole
-#  name: admin
-#subjects:
-#  - kind: Group
-#    name: <replace-with-an-aad-group-object-id-for-this-namespace-role-binding>
-#---
-#apiVersion: rbac.authorization.k8s.io/v1
-#kind: RoleBinding
-#metadata:
-#  name: a0008-edit
-#  namespace: cluster-baseline-settings
-#roleRef:
-#  apiGroup: rbac.authorization.k8s.io
-#  kind: ClusterRole
-#  name: namespace-editer
-#subjects:
-#  - kind: Group
-#    name: <replace-with-an-aad-group-object-id-for-this-namespace-role-binding>
-#---
-#apiVersion: rbac.authorization.k8s.io/v1
-#kind: RoleBinding
-#metadata:
-#  name: namespace-viewer
-#  namespace: cluster-baseline-settings
-#roleRef:
-#  apiGroup: rbac.authorization.k8s.io
-#  kind: ClusterRole
-#  name: view
-#subjects:
-#  - kind: Group
-#    name: <replace-with-an-aad-group-object-id-for-this-namespace-role-binding>
+# This file is exclusively to be used when you are using Azure AD direct assignment for Kubertnetes RBAC 
+# and NOT when you are using Azure RBAC as your Kubernetes RBAC backing store.
+#
+#  Map k8s user facing namespace roles to AAD groups: https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles
+#apiVersion: rbac.authorization.k8s.io/v1
+#kind: RoleBinding
+#metadata:
+#  name: namespace-admin
+#  namespace: cluster-baseline-settings
+#roleRef:
+#  apiGroup: rbac.authorization.k8s.io
+#  kind: ClusterRole
+#  name: admin
+#subjects:
+#  - kind: Group
+#    name: <replace-with-an-aad-group-object-id-for-this-namespace-role-binding>
+#---
+#apiVersion: rbac.authorization.k8s.io/v1
+#kind: RoleBinding
+#metadata:
+#  name: a0008-edit
+#  namespace: cluster-baseline-settings
+#roleRef:
+#  apiGroup: rbac.authorization.k8s.io
+#  kind: ClusterRole
+#  name: namespace-editer
+#subjects:
+#  - kind: Group
+#    name: <replace-with-an-aad-group-object-id-for-this-namespace-role-binding>
+#---
+#apiVersion: rbac.authorization.k8s.io/v1
+#kind: RoleBinding
+#metadata:
+#  name: namespace-viewer
+#  namespace: cluster-baseline-settings
+#roleRef:
+#  apiGroup: rbac.authorization.k8s.io
+#  kind: ClusterRole
+#  name: view
+#subjects:
+#  - kind: Group
+#    name: <replace-with-an-aad-group-object-id-for-this-namespace-role-binding>