docs: update invalid URLs in website (#832)
Signed-off-by: Ernest Wong <chuwon@microsoft.com>
This commit is contained in:
Ernest Wong
GitHub
Родитель
55ba979cd4
Коммит
0091ec9f3b
341
README.md
341
README.md
|
|
@ -5,326 +5,15 @@
|
|||
[](https://godoc.org/github.com/Azure/aad-pod-identity)
|
||||
[](https://goreportcard.com/report/github.com/Azure/aad-pod-identity)
|
||||
|
||||
AAD Pod Identity enables Kubernetes applications to access cloud resources securely with [Azure Active Directory] (AAD).
|
||||
AAD Pod Identity enables Kubernetes applications to access cloud resources securely with [Azure Active Directory](https://azure.microsoft.com/en-us/services/active-directory/).
|
||||
|
||||
Using Kubernetes primitives, administrators configure identities and bindings to match pods. Then without any code modifications, your containerized applications can leverage any resource in the cloud that depends on AAD as an identity provider.
|
||||
|
||||
----
|
||||
|
||||
## Contents
|
||||
|
||||
- [AAD Pod Identity](#aad-pod-identity)
|
||||
- [Contents](#contents)
|
||||
- [v1.6.0 Breaking Change](#v160-breaking-change)
|
||||
- [`AzureIdentity`](#azureidentity)
|
||||
- [`AzureIdentityBinding`](#azureidentitybinding)
|
||||
- [`AzurePodIdentityException`](#azurepodidentityexception)
|
||||
- [Getting Started](#getting-started)
|
||||
- [Components](#components)
|
||||
- [Managed Identity Controller](#managed-identity-controller)
|
||||
- [Node Managed Identity](#node-managed-identity)
|
||||
- [Role Assignment](#role-assignment)
|
||||
- [Demo](#demo)
|
||||
- [1. Deploy aad-pod-identity](#1-deploy-aad-pod-identity)
|
||||
- [2. Create an identity on Azure](#2-create-an-identity-on-azure)
|
||||
- [3. Deploy `AzureIdentity`](#3-deploy-azureidentity)
|
||||
- [4. (Optional) Match pods in the namespace](#4-optional-match-pods-in-the-namespace)
|
||||
- [5. Deploy `AzureIdentityBinding`](#5-deploy-azureidentitybinding)
|
||||
- [6. Deployment and Validation](#6-deployment-and-validation)
|
||||
- [Uninstall Notes](#uninstall-notes)
|
||||
- [What To Do Next?](#what-to-do-next)
|
||||
- [Code of Conduct](#code-of-conduct)
|
||||
- [Support](#support)
|
||||
|
||||
## v1.6.0 Breaking Change
|
||||
|
||||
With https://github.com/Azure/aad-pod-identity/pull/398, the [client-go](https://github.com/kubernetes/client-go) library is upgraded to v0.17.2, where CRD [fields are now case sensitive](https://github.com/kubernetes/kubernetes/issues/64612). If you are upgrading MIC and NMI from v1.x.x to v1.6.0, MIC v1.6.0+ will upgrade the fields of existing `AzureIdentity` and `AzureIdentityBinding` on startup to the new format to ensure backward compatibility. A configmap called `aad-pod-identity-config` is created to record and confirm the successful type upgrade.
|
||||
|
||||
However, for future `AzureIdentity` and `AzureIdentityBinding` created using v1.6.0+, the following fields need to be changed:
|
||||
|
||||
### `AzureIdentity`
|
||||
|
||||
| < 1.6.0 | >= 1.6.0 |
|
||||
| ---------------- | ---------------- |
|
||||
| `ClientID` | `clientID` |
|
||||
| `ClientPassword` | `clientPassword` |
|
||||
| `ResourceID` | `resourceID` |
|
||||
| `TenantID` | `tenantID` |
|
||||
|
||||
### `AzureIdentityBinding`
|
||||
|
||||
| < 1.6.0 | >= 1.6.0 |
|
||||
| --------------- | --------------- |
|
||||
| `AzureIdentity` | `azureIdentity` |
|
||||
| `Selector` | `selector` |
|
||||
|
||||
### `AzurePodIdentityException`
|
||||
|
||||
| < 1.6.0 | >= 1.6.0 |
|
||||
| ----------- | ----------- |
|
||||
| `PodLabels` | `podLabels` |
|
||||
|
||||
## Getting Started
|
||||
|
||||
It is recommended to get familiar with the AAD Pod Identity ecosystem before diving into the demo. It consists of the Managed Identity Controller (MIC) deployment, the Node Managed Identity (NMI) DaemonSet, and several standard and custom resources.
|
||||
Get familiar with the [core components](https://azure.github.io/aad-pod-identity/docs/getting-started/components/) and setup the correct [role assignments](https://azure.github.io/aad-pod-identity/docs/getting-started/role-assignment/) on Azure.
|
||||
|
||||
## Components
|
||||
|
||||
AAD Pod Identity has two components: the [Managed Identity Controller] (MIC) and the [Node Managed Identity] (NMI).
|
||||
|
||||
### Managed Identity Controller
|
||||
|
||||
The Managed Identity Controller (MIC) is a Kubernetes [custom resource] that watches for changes to pods, `AzureIdentity` and `AzureIdentityBindings` through the Kubernetes API server. When it detects a relevant change, the MIC adds or deletes `AzureAssignedIdentity` as needed.
|
||||
|
||||
Specifically, when a pod is scheduled, the MIC assigns the identity on Azure to the underlying VM/VMSS during the creation phase. When the pod is deleted, it removes the identity from the underlying VM/VMSS on Azure. The MIC takes similar actions when `AzureIdentity` or `AzureIdentityBinding` are created or deleted.
|
||||
|
||||
### Node Managed Identity
|
||||
|
||||
The authorization request to fetch a Service Principal Token from an MSI endpoint is sent to Azure Instance Metadata Service (IMDS) endpoint (169.254.169.254), which is redirected to the NMI pod. The redirection is accomplished by adding iptable rules to redirect all non-host traffic with IMDS endpoint on port 80 as destination to the NMI endpoint. The NMI server identifies the pod based on the remote address of the request and then queries Kubernetes (through MIC) for a matching Azure identity. NMI then makes an Azure Active Directory Authentication Library ([ADAL]) request to get the token for the client ID and returns it as a response. If the request had client ID as part of the query, it is validated against the admin-configured client ID.
|
||||
|
||||
Here is an example cURL command that will fetch an access token to access ARM within a pod identified by an AAD-Pod-Identity selector:
|
||||
|
||||
```bash
|
||||
curl 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https%3A%2F%2Fmanagement.azure.com%2F' -H Metadata:true -s
|
||||
```
|
||||
|
||||
For different ways to acquire an access token within a pod, please refer to this [documentation](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/how-to-use-vm-token).
|
||||
|
||||
Similarly, a host can make an authorization request to fetch Service Principal Token for a resource directly from the NMI host endpoint (http://127.0.0.1:2579/host/token/). The request must include the pod namespace `podns` and the pod name `podname` in the request header and the resource endpoint of the resource requesting the token. The NMI server identifies the pod based on the `podns` and `podname` in the request header and then queries k8s (through MIC) for a matching azure identity. Then NMI makes an ADAL request to get a token for the resource in the request, returning the `token` and the `clientid` as a response.
|
||||
|
||||
Here is an example cURL command:
|
||||
|
||||
```bash
|
||||
curl http://127.0.0.1:2579/host/token/?resource=https://vault.azure.net -H "podname: nginx-flex-kv-int" -H "podns: default"
|
||||
```
|
||||
|
||||
For more information, please refer to the [design documentation](./docs/design/concept.md).
|
||||
|
||||
## Role Assignment
|
||||
|
||||
Your cluster will need the correct role assignment configuration to perform Azure-related operations such as assigning and un-assigning the identity on the underlying VM/VMSS. You can run the following commands to help you set up the appropriate role assignments for your cluster identity before deploying aad-pod-identity (assuming you are running an AKS cluster):
|
||||
|
||||
```bash
|
||||
export SUBSCRIPTION_ID="<SubscriptionID>"
|
||||
export RESOURCE_GROUP="<AKSResourceGroup>"
|
||||
export CLUSTER_NAME="<AKSClusterName>"
|
||||
export CLUSTER_LOCATION="<AKSClusterLocation>"
|
||||
|
||||
# if you are planning to deploy your user-assigned identities in a separate resource group
|
||||
export IDENTITY_RESOURCE_GROUP="<IdentityResourceGroup>"
|
||||
|
||||
./hack/role-assignment.sh
|
||||
```
|
||||
|
||||
> Note: `<AKSResourceGroup>` is where your AKS cluster is deployed to.
|
||||
|
||||
For more details, please refer to the [role assignment](./docs/readmes/README.role-assignment.md) documentation.
|
||||
|
||||
## Demo
|
||||
|
||||
You will need [Azure CLI] installed and a Kubernetes cluster running on Azure, either managed by [AKS] or provisioned with [AKS Engine].
|
||||
|
||||
Run the following commands to set Azure-related environment variables and login to Azure via `az login`:
|
||||
|
||||
```bash
|
||||
export SUBSCRIPTION_ID="<SubscriptionID>"
|
||||
export RESOURCE_GROUP="<AKSResourceGroup>"
|
||||
export CLUSTER_NAME="<AKSClusterName>"
|
||||
export CLUSTER_LOCATION="<AKSClusterLocation>"
|
||||
|
||||
export IDENTITY_RESOURCE_GROUP="MC_${RESOURCE_GROUP}_${CLUSTER_NAME}_${CLUSTER_LOCATION}"
|
||||
export IDENTITY_NAME="demo"
|
||||
|
||||
# login as a user and set the appropriate subscription ID
|
||||
az login
|
||||
az account set -s "${SUBSCRIPTION_ID}"
|
||||
```
|
||||
|
||||
> For AKS clusters, there are two resource groups that you need to be aware of - the resource group where you deploy your AKS cluster to (denoted by the environment variable `RESOURCE_GROUP`), and the cluster resource group (`MC_<AKSResourceGroup>_<AKSClusterName>_<AKSClusterLocation>`). The latter contains all of the infrastructure resources associated with the cluster like VM/VMSS and VNet. Depending on where you deploy your user-assigned identities, you might need additional role assignments. Please refer to [Role Assignment](#role-assignment) for more information. For this demo, it is recommended to deploy the demo identity to your cluster resource group (the one with `MC_` prefix).
|
||||
|
||||
### 1. Deploy aad-pod-identity
|
||||
|
||||
Deploy `aad-pod-identity` components to an RBAC-enabled cluster:
|
||||
|
||||
```bash
|
||||
kubectl apply -f https://raw.githubusercontent.com/Azure/aad-pod-identity/master/deploy/infra/deployment-rbac.yaml
|
||||
|
||||
# For AKS clusters, deploy the MIC and AKS add-on exception by running -
|
||||
kubectl apply -f https://raw.githubusercontent.com/Azure/aad-pod-identity/master/deploy/infra/mic-exception.yaml
|
||||
```
|
||||
|
||||
Deploy `aad-pod-identity` components to a non-RBAC cluster:
|
||||
|
||||
```bash
|
||||
kubectl apply -f https://raw.githubusercontent.com/Azure/aad-pod-identity/master/deploy/infra/deployment.yaml
|
||||
|
||||
# For AKS clusters, deploy the MIC and AKS add-on exception by running -
|
||||
kubectl apply -f https://raw.githubusercontent.com/Azure/aad-pod-identity/master/deploy/infra/mic-exception.yaml
|
||||
```
|
||||
|
||||
Deploy `aad-pod-identity` using [Helm 3](https://v3.helm.sh/):
|
||||
|
||||
```bash
|
||||
helm repo add aad-pod-identity https://raw.githubusercontent.com/Azure/aad-pod-identity/master/charts
|
||||
helm install aad-pod-identity aad-pod-identity/aad-pod-identity
|
||||
```
|
||||
|
||||
For a list of overwritable values when installing with Helm, please refer to [this section](https://github.com/Azure/aad-pod-identity/tree/master/charts/aad-pod-identity#configuration).
|
||||
|
||||
> Important: For AKS clusters with limited [egress-traffic], Please install pod-identity in `kube-system` namespace using the [helm charts].
|
||||
|
||||
```bash
|
||||
helm install aad-pod-identity aad-pod-identity/aad-pod-identity --namespace=kube-system
|
||||
```
|
||||
|
||||
### 2. Create an identity on Azure
|
||||
|
||||
Create an identity on Azure and store the client ID and resource ID of the identity as environment variables:
|
||||
|
||||
```bash
|
||||
az identity create -g ${IDENTITY_RESOURCE_GROUP} -n ${IDENTITY_NAME}
|
||||
export IDENTITY_CLIENT_ID="$(az identity show -g ${IDENTITY_RESOURCE_GROUP} -n ${IDENTITY_NAME} --query clientId -otsv)"
|
||||
export IDENTITY_RESOURCE_ID="$(az identity show -g ${IDENTITY_RESOURCE_GROUP} -n ${IDENTITY_NAME} --query id -otsv)"
|
||||
```
|
||||
|
||||
Assign the role "Reader" to the identity so it has read access to the resource group. At the same time, store the identity assignment ID as an environment variable.
|
||||
|
||||
```bash
|
||||
export IDENTITY_ASSIGNMENT_ID="$(az role assignment create --role Reader --assignee ${IDENTITY_CLIENT_ID} --scope /subscriptions/${SUBSCRIPTION_ID}/resourceGroups/${IDENTITY_RESOURCE_GROUP} --query id -otsv)"
|
||||
```
|
||||
|
||||
### 3. Deploy `AzureIdentity`
|
||||
|
||||
Create an `AzureIdentity` in your cluster that references the identity you created above:
|
||||
|
||||
```bash
|
||||
cat <<EOF | kubectl apply -f -
|
||||
apiVersion: "aadpodidentity.k8s.io/v1"
|
||||
kind: AzureIdentity
|
||||
metadata:
|
||||
name: ${IDENTITY_NAME}
|
||||
spec:
|
||||
type: 0
|
||||
resourceID: ${IDENTITY_RESOURCE_ID}
|
||||
clientID: ${IDENTITY_CLIENT_ID}
|
||||
EOF
|
||||
```
|
||||
|
||||
> Set `type: 0` for user-assigned MSI, `type: 1` for Service Principal with client secret, or `type: 2` for Service Principal with certificate. For more information, see [here](https://github.com/Azure/aad-pod-identity/tree/master/deploy/demo).
|
||||
|
||||
### 4. (Optional) Match pods in the namespace
|
||||
|
||||
For matching pods in the namespace, please refer to the [namespaced documentation](docs/readmes/README.namespaced.md).
|
||||
|
||||
### 5. Deploy `AzureIdentityBinding`
|
||||
|
||||
Create an `AzureIdentityBinding` that reference the `AzureIdentity` you created above:
|
||||
|
||||
```bash
|
||||
cat <<EOF | kubectl apply -f -
|
||||
apiVersion: "aadpodidentity.k8s.io/v1"
|
||||
kind: AzureIdentityBinding
|
||||
metadata:
|
||||
name: ${IDENTITY_NAME}-binding
|
||||
spec:
|
||||
azureIdentity: ${IDENTITY_NAME}
|
||||
selector: ${IDENTITY_NAME}
|
||||
EOF
|
||||
```
|
||||
|
||||
### 6. Deployment and Validation
|
||||
|
||||
For a pod to match an identity binding, it needs a [label] with the key `aadpodidbinding` whose value is that of the `selector:` field in the `AzureIdentityBinding`. Deploy a pod that validates the functionality:
|
||||
|
||||
```bash
|
||||
cat << EOF | kubectl apply -f -
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: demo
|
||||
labels:
|
||||
aadpodidbinding: $IDENTITY_NAME
|
||||
spec:
|
||||
containers:
|
||||
- name: demo
|
||||
image: mcr.microsoft.com/oss/azure/aad-pod-identity/demo:v1.6.3
|
||||
args:
|
||||
- --subscriptionid=${SUBSCRIPTION_ID}
|
||||
- --clientid=${IDENTITY_CLIENT_ID}
|
||||
- --resourcegroup=${IDENTITY_RESOURCE_GROUP}
|
||||
env:
|
||||
- name: MY_POD_NAME
|
||||
valueFrom:
|
||||
fieldRef:
|
||||
fieldPath: metadata.name
|
||||
- name: MY_POD_NAMESPACE
|
||||
valueFrom:
|
||||
fieldRef:
|
||||
fieldPath: metadata.namespace
|
||||
- name: MY_POD_IP
|
||||
valueFrom:
|
||||
fieldRef:
|
||||
fieldPath: status.podIP
|
||||
nodeSelector:
|
||||
kubernetes.io/os: linux
|
||||
EOF
|
||||
```
|
||||
|
||||
> `mcr.microsoft.com/oss/azure/aad-pod-identity/demo` is an image that demostrates the use of AAD pod identity. The source code can be found [here](./cmd/demo/main.go).
|
||||
|
||||
To verify that the pod is indeed using the identity correctly:
|
||||
|
||||
```bash
|
||||
kubectl logs demo
|
||||
```
|
||||
|
||||
If successful, the log output would be similar to the following output:
|
||||
|
||||
```log
|
||||
...
|
||||
successfully doARMOperations vm count 1
|
||||
successfully acquired a token using the MSI, msiEndpoint(http://169.254.169.254/metadata/identity/oauth2/token)
|
||||
successfully acquired a token, userAssignedID MSI, msiEndpoint(http://169.254.169.254/metadata/identity/oauth2/token) clientID(xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)
|
||||
successfully made GET on instance metadata
|
||||
...
|
||||
```
|
||||
|
||||
Once you are done with the demo, clean up your resources:
|
||||
|
||||
```bash
|
||||
kubectl delete pod demo
|
||||
kubectl delete azureidentity ${IDENTITY_NAME}
|
||||
kubectl delete azureidentitybinding ${IDENTITY_NAME}-binding
|
||||
az role assignment delete --id ${IDENTITY_ASSIGNMENT_ID}
|
||||
az identity delete -g ${IDENTITY_RESOURCE_GROUP} -n ${IDENTITY_NAME}
|
||||
```
|
||||
|
||||
## Uninstall Notes
|
||||
|
||||
The NMI pods modify the nodes' [iptables] to intercept calls to IMDS endpoint within a node. This allows NMI to insert identities assigned to a pod before executing the request on behalf of the caller.
|
||||
|
||||
These iptables entries will be cleaned up when the pod-identity pods are uninstalled. However, if the pods are terminated for unexpected reasons, the iptables entries can be removed with these commands on the node:
|
||||
|
||||
```bash
|
||||
# remove the custom chain reference
|
||||
iptables -t nat -D PREROUTING -j aad-metadata
|
||||
|
||||
# flush the custom chain
|
||||
iptables -t nat -F aad-metadata
|
||||
|
||||
# remove the custom chain
|
||||
iptables -t nat -X aad-metadata
|
||||
```
|
||||
|
||||
## What To Do Next?
|
||||
|
||||
* [Additional readings](docs/readmes/README.md)
|
||||
* Dive deeper into AAD Pod Identity by following the detailed [Tutorial].
|
||||
* Learn more about the design of AAD Pod Identity:
|
||||
- [Concept]
|
||||
- [Block Diagram]
|
||||
* Learn how to debug this project at the [Debugging] wiki page.
|
||||
* Join us by [Contributing] to AAD Pod Identity.
|
||||
Try our [walkthrough](https://azure.github.io/aad-pod-identity/docs/demo/standard_walkthrough/) to get a better understanding of the application workflow.
|
||||
|
||||
## Code of Conduct
|
||||
|
||||
|
|
@ -333,27 +22,3 @@ This project has adopted the [Microsoft Open Source Code of Conduct](https://ope
|
|||
## Support
|
||||
|
||||
aad-pod-identity is an open source project that is [**not** covered by the Microsoft Azure support policy](https://support.microsoft.com/en-us/help/2941892/support-for-linux-and-open-source-technology-in-azure). [Please search open issues here](https://github.com/Azure/aad-pod-identity/issues), and if your issue isn't already represented please [open a new one](https://github.com/Azure/aad-pod-identity/issues/new/choose). The project maintainers will respond to the best of their abilities.
|
||||
|
||||
|
||||
[ADAL]: https://docs.microsoft.com/azure/active-directory/develop/active-directory-authentication-libraries
|
||||
[AKS]: https://azure.microsoft.com/services/kubernetes-service/
|
||||
[AKS Docs]: https://docs.microsoft.com/azure/aks/kubernetes-service-principal
|
||||
[AKS Engine]: https://github.com/Azure/aks-engine
|
||||
[annotation]: https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/
|
||||
[Azure Active Directory]: https://azure.microsoft.com/services/active-directory/
|
||||
[Azure CLI]: https://docs.microsoft.com/cli/azure/install-azure-cli?view=azure-cli-latest
|
||||
[Block Diagram]: docs/design/concept.png
|
||||
[Components]: #components
|
||||
[Concept]: docs/design/concept.md
|
||||
[Contributing]: CONTRIBUTING.md
|
||||
[credentials stored in the cluster]: https://docs.microsoft.com/azure/aks/kubernetes-service-principal
|
||||
[custom resource]: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/
|
||||
[Debugging]: https://github.com/Azure/aad-pod-identity/wiki/Debugging
|
||||
[iptables]: https://en.wikipedia.org/wiki/Iptables
|
||||
[label]: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/
|
||||
[Managed Identity Controller]: #managed-identity-controller
|
||||
[Node Managed Identity]: #node-managed-identity
|
||||
[Prerequisites]: #prerequisites
|
||||
[Tutorial]: docs/tutorial/README.md
|
||||
[helm charts]: https://github.com/Azure/aad-pod-identity/tree/master/charts/aad-pod-identity
|
||||
[egress-traffic]: https://docs.microsoft.com/en-us/azure/aks/limit-egress-traffic
|
||||
|
|
|
|||
|
|
@ -1,136 +0,0 @@
|
|||
# Kubernetes Applications With Azure Active Directory Identities
|
||||
|
||||
## Abstract
|
||||
|
||||
## AAD and Kubernetes
|
||||
|
||||
The relationship between kubernetes and AAD is covered in three main areas:
|
||||
|
||||
1. **Cluster Identity**: The identity used by the cloud provider running in various kubernetes components to perform operations against Azure, typically against Azure's resource group where the cluster lives. This identity is set during the cluster bring up process. This is not included in the scope of this proposal.
|
||||
|
||||
2. **User Identity**: What enables user/operator to authenticate against AAD using AAD before using `kubectl` commands. This is not included in the scope of this proposal.
|
||||
|
||||
3. **Application Identities**: Identities that are used by applications running on kubernetes to access any resources that uses AAD as identity provider. These resources can be ARM, Applications running on the same cluster, on azure, or anywhere else. Managing, assigning these identities is the scope of this document.
|
||||
|
||||
> This proposal does not cover how application can be configured to use AAD as identity/authentication provider.
|
||||
|
||||
## Use cases
|
||||
|
||||
1. kubernetes applications depending on other applications that use AAD as an identity provider. These applications include Azure 1st party services (such as ARM, Azure sql or Azure storage) or user applications running on Azure (including same cluster) and or on premises.
|
||||
|
||||
> Azure 1st party services are all moving to use AAD as the primary identity provider.
|
||||
|
||||
2. Delegating authorization to user familiar tools such as AAD group memberships.
|
||||
|
||||
3. Enable identity rotation without application interruption.
|
||||
|
||||
> Example: rotating a service principal password/cert without having to edit secrets assigned directly to applications.
|
||||
|
||||
4. Provide a framework to enable time-boxed identity assignment. Manually triggered or automated. The same framework can be used for (jit sudo style access with automation tools).
|
||||
|
||||
> Example: a front end application can have access to centralized data store between midnight and 1 AM during business days only.
|
||||
|
||||
## Guiding Principles
|
||||
|
||||
1. Favor little to no change to how users currently write applications against various editions of [ADAL](https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-authentication-libraries). Favor committing changes to SDKs and don't ask users to change applications that are written for Kubernetes.
|
||||
|
||||
2. Favor little to no change in the way users create kubernetes application specs (favor declarative approach). This enables users to focus their development and debugging experience in code they wrote, not code imposed on them.
|
||||
|
||||
> Example: favor annotation and labels over side-cars (even dynamically injected).
|
||||
|
||||
3. Prep for SPIFFE work currently in progress by the wider community.
|
||||
|
||||
4. Separate identities from `identity assignment` applications enables users to swap identities used by the applications.
|
||||
|
||||
## Processes
|
||||
|
||||
### AAD Identity Management and Assignment (within cluster)
|
||||
|
||||
- Cluster operators create instances of `crd:azureIdentity`. Each instance is a kubernetes object representing Azure AAD identity that can be EMSI or service principal (with password).
|
||||
|
||||
- Cluster operators create instances of `crd:azureIdentityBinding`. Each instance represents binding between `pod` and `crd:azureIdentity`. The binding initially will use (one of)
|
||||
1. Selectors
|
||||
2. Explicit assignment to applications (?)
|
||||
3. Weight (used in case of a single pod matched by multiple identities)
|
||||
|
||||
At later phases, the binding will use:
|
||||
|
||||
1. Expiration time (static: bind until Jan 1/1/2019. Dynamic: for 10 mins).
|
||||
2. ...?
|
||||
|
||||
> All identity bindings actions are logged as `events` to `crd:azureIdentity`. Allowing clusters operators to track how the system assigned identities to various apps.
|
||||
|
||||
- A Controller will run to create `crd:azureAssignedIdentity` based on `crd:azureIdentityBinding` linking `pod` with `crd:azureIdentity`.
|
||||
|
||||
### Acquiring Tokens
|
||||
|
||||
> for reference please read [Azure VM Managed Service Identity (MSI)](https://docs.microsoft.com/en-us/azure/active-directory/managed-service-identity/how-to-use-vm-token) and [Assign a Managed Service Identity](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/howto-assign-access-portal)
|
||||
|
||||
1. Kubernetes applications (pods) will default to use MSI endpoint.
|
||||
2. All traffic to MSI endpoint is routed via `iptables` to a daemon-set that will use `sourceIp` to identify pod, then find an appropriate `crd:azureIdentityBinding`. The daemon-set mimics all the REST api offered by MSI endpoint. All tokens are presented to pods on MSI endpoint irrespective of the identity used to back this request (EMSI or service principal).
|
||||
|
||||
> As SPIFFE becomes more mature pod identity assertion is expected to use SPIFFE pod identity.
|
||||
|
||||
3. All token issuance will be logged as events attached to `crd:azureIdentityBinding` for audit purposes.
|
||||
|
||||
## Controllers
|
||||
|
||||
A single `azureIdentityController` controller is use to:
|
||||
|
||||
1. Create instances of `azureAssignedIdentity` as a result of `crd:azureIdentityBinding` matching.
|
||||
2. Assign EMSI to nodes where pods are scheduled to run. Assignment are logged to `crd:azureIdentity` as events.
|
||||
|
||||
> The controller can later expose an endpoint for analysis where operators can request analysis of identities, pod assignment.
|
||||
|
||||
## RBAC
|
||||
<<POD/azureAssignedIdentity>> ??
|
||||
|
||||
## Api
|
||||
|
||||
### azureIdentity
|
||||
|
||||
A custom resource definition object that represents either
|
||||
|
||||
1. Explicit Managed Service Identity (EMSI).
|
||||
2. Service Principal.
|
||||
|
||||
```yaml
|
||||
<<Object details>>
|
||||
type: <EMSI/Principal>
|
||||
secretRef: <Principal Password>
|
||||
```
|
||||
|
||||
> Identities are created separately by azure cli. ARM RBAC and data plane specific role assignment is done on each service, application or resource.
|
||||
|
||||
### azureIdentityBinding
|
||||
|
||||
A custom resource definition object used to describe `azureIdentity` is assigned to pod.
|
||||
|
||||
```yaml
|
||||
<<object details>>
|
||||
azureIdentityRef: xxx
|
||||
type: <Explicit/Selector>
|
||||
weight: ??
|
||||
timeBox: <<future time box details>>
|
||||
```
|
||||
|
||||
### azureAssignedIdentity
|
||||
|
||||
A custom resource definition object. Each instance represents linking `pod` to `azureIdentity`
|
||||
|
||||
```yaml
|
||||
<<object details>>
|
||||
azureIdentityRef: xxx
|
||||
podRef: xxx
|
||||
```
|
||||
|
||||
## Plan
|
||||
|
||||
### Phase 1
|
||||
|
||||
1. Api, controller and daemon set (excluding time boxed assignment).
|
||||
|
||||
### Phase 2
|
||||
|
||||
1. Time box assignment
|
||||
2. SPIFFE integration
|
||||
Двоичные данные
docs/design/concept.vsdx
Двоичные данные
docs/design/concept.vsdx
Двоичный файл не отображается.
|
|
@ -1,59 +0,0 @@
|
|||
# Disable aad-pod-identity for a specific pod/application
|
||||
> Available from 1.5 release
|
||||
|
||||
NMI pods modify the nodes' iptables to intercept calls to Azure Instance Metadata endpoint. This means any request that's made to the Metadata endpoint will be intercepted by NMI even if the pod doesn't use aad-pod-identity. `AzurePodIdentityException` CRD can be configured to inform aad-pod-identity that any requests to metadata endpoint originating from a pod that matches labels defined in CRD should be proxied without any processing in NMI. NMI will proxy the request to the metdata endpoint and return the token back as is without any validation.
|
||||
|
||||
1. Create the `AzurePodIdentityException` with the same label that will be defined in the pod -
|
||||
|
||||
```yaml
|
||||
apiVersion: "aadpodidentity.k8s.io/v1"
|
||||
kind: AzurePodIdentityException
|
||||
metadata:
|
||||
name: test-exception
|
||||
spec:
|
||||
podLabels:
|
||||
foo: bar
|
||||
app: custom
|
||||
```
|
||||
|
||||
Use the [sample template](../../examples/azurepodidentityexception.yaml), replace the podLabels with a list of desired values and then create the resource on the cluster:
|
||||
|
||||
```shell
|
||||
kubectl apply -f examples/aadpodidentityexception.yaml
|
||||
```
|
||||
|
||||
When creating application pods that will not be using aad-pod-identity for calls to Azure Instance Metadata endpoint, include at least one of the labels in `spec.template.metadata.labels`.
|
||||
|
||||
Example pod with same label as above defined in the spec -
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: sample
|
||||
labels:
|
||||
app: sample
|
||||
spec:
|
||||
replicas: 2
|
||||
selector:
|
||||
matchLabels:
|
||||
app: sample
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: sample
|
||||
foo: bar <------- Label defined in exception CRD included in deployment
|
||||
spec:
|
||||
[...]
|
||||
```
|
||||
|
||||
To verify the pods have the right label that match the ones defined in the exception crd -
|
||||
```shell
|
||||
kubectl get pods --show-labels
|
||||
NAME READY STATUS RESTARTS AGE LABELS
|
||||
sample-td 1/1 Running 0 16s app=sample,foo=bar
|
||||
```
|
||||
|
||||
**NOTE**
|
||||
- `AzurePodIdentityException` is per namespace. This means if the same label needs to be used in multiple namespaces to except pods, a CRD resource needs to be created in each namespace.
|
||||
- All the labels defined in the exception CRD doesn't need to be defined in the deployment/pod spec. A single match is enough for the pod to be excepted.
|
||||
|
|
@ -1,210 +0,0 @@
|
|||
# Best Practices
|
||||
|
||||
This document highlights the best practices when using aad-pod-identity.
|
||||
|
||||
## Retry on token retrieval
|
||||
|
||||
aad-pod-identity retrieves access tokens on behalf of your workload by intercepting token requests to the Instance Metadata Service (IMDS) endpoint (169.254.169.254). However, it does not perform any sort of token caching. We believe that either the users or the SDK that your application is using is responsible for token management.
|
||||
|
||||
Note that there is a brief window between when your application started running and the identity gets assigned to the underlying node. If your application tried to retrieve an access token during that period, it might fail. The following table describes the duration that you could expect to wait based on your cluster's node type:
|
||||
|
||||
| Node Type | Identity Assignment Duration |
|
||||
|---------------------------|------------------------------|
|
||||
| Virtual Machine | 10 - 20 seconds |
|
||||
| Virtual Machine Scale Set | 40 - 60 seconds |
|
||||
|
||||
> Note: the delay only occurs when the user-assigned identity is not assigned to the underlying node on Azure. Subsequent token requests will not incur this delay after identity assignment.
|
||||
|
||||
By default, when fetching an access token, NMI performs 16 retries with 5 seconds in between each retry to check whether the `AzureIdentity` assigned to your pod has been successfully assigned to the underlying node on Azure. It will return an error if it is still not assigned after `16 retries x 5 seconds = 80 seconds`. Also, your workload might encounter an error if it times out before NMI finishes this operation. You can adjust the number of retries and the delay in between each retry via the NMI flags `--retry-attempts-for-created` and `--find-identity-retry-interval`.
|
||||
|
||||
Additional retry logic is also implemented internally in most of Azure's SDKs to prevent your application from erroring out. For example, [azure-sdk-for-go](https://github.com/Azure/azure-sdk-for-go) by default performs five retries with exponential backoff when fetching an access token from IMDS.
|
||||
|
||||
Alternatively, you could set up a simple init container to probe for successful identity assignment by MIC and prevent applications from starting prematurely. Here is an example init-container with Azure CLI.
|
||||
|
||||
```yaml
|
||||
...
|
||||
initContainers:
|
||||
- name: init
|
||||
image: mcr.microsoft.com/azure-cli
|
||||
command:
|
||||
- sh
|
||||
- -c
|
||||
- az login --identity --debug
|
||||
...
|
||||
```
|
||||
|
||||
## A pod using multiple AzureIdentities
|
||||
|
||||
In some scenarios, you might want to assign multiple `AzureIdentities` to a workload. Here is an example of how to achieve that:
|
||||
|
||||
### AzureIdentities
|
||||
|
||||
```yaml
|
||||
apiVersion: aadpodidentity.k8s.io/v1
|
||||
kind: AzureIdentity
|
||||
metadata:
|
||||
name: az-id-1
|
||||
spec:
|
||||
type: 0
|
||||
resourceID: <ResourceID of az-id-1>
|
||||
clientID: <ClientID of az-id-1>
|
||||
```
|
||||
|
||||
```yaml
|
||||
apiVersion: aadpodidentity.k8s.io/v1
|
||||
kind: AzureIdentity
|
||||
metadata:
|
||||
name: az-id-2
|
||||
spec:
|
||||
type: 0
|
||||
resourceID: <ResourceID of az-id-2>
|
||||
clientID: <ClientID of az-id-2>
|
||||
```
|
||||
|
||||
### AzureIdentityBinding
|
||||
|
||||
```yaml
|
||||
apiVersion: aadpodidentity.k8s.io/v1
|
||||
kind: AzureIdentityBinding
|
||||
metadata:
|
||||
name: az-id-1-binding
|
||||
spec:
|
||||
azureIdentity: az-id-1
|
||||
selector: az-id-combined
|
||||
```
|
||||
|
||||
```yaml
|
||||
apiVersion: aadpodidentity.k8s.io/v1
|
||||
kind: AzureIdentityBinding
|
||||
metadata:
|
||||
name: az-id-2-binding
|
||||
spec:
|
||||
azureIdentity: az-id-2
|
||||
selector: az-id-combined
|
||||
```
|
||||
|
||||
### Pod
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: demo
|
||||
labels:
|
||||
aadpodidbinding: az-id-combined
|
||||
...
|
||||
```
|
||||
|
||||
## Pods using unauthorized AzureIdentities
|
||||
|
||||
By default, aad-pod-identity matches pods with `AzureIdentities` across all namespaces. That means that a malicious pod could assign itself an unauthorized pod identity label and acquire a token with that particular `AzureIdentity`. This scenario can be mitigated by performing the following:
|
||||
|
||||
- Deploy aad-pod-identity with [namespaced mode](README.namespaced.md). This will restrict pods from binding with `AzureIdentities` across different namespaces. Note that `AzureIdentities` and `AzureIdentityBindings` must be deployed to the same namespace as your workload when using namespaced mode.
|
||||
|
||||
- Set up Kubernetes-native RBAC to restrict access and creation of `AzureIdentities` across sensitive namespaces.
|
||||
|
||||
- Set up RBAC on Azure to restrict access and creation of user-assigned identities.
|
||||
|
||||
## Using aad-pod-identity in different Kubernetes workloads
|
||||
|
||||
### [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: azure-cli
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
name: azure-cli
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
name: azure-cli
|
||||
aadpodidbinding: <selector defined in AzureIdentityBinding>
|
||||
spec:
|
||||
containers:
|
||||
- name: azure-cli
|
||||
image: mcr.microsoft.com/azure-cli
|
||||
command:
|
||||
- sh
|
||||
- -c
|
||||
- az login --identity --debug
|
||||
```
|
||||
|
||||
### [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/)
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: DaemonSet
|
||||
metadata:
|
||||
name: azure-cli
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
name: azure-cli
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
name: azure-cli
|
||||
aadpodidbinding: <selector defined in AzureIdentityBinding>
|
||||
spec:
|
||||
containers:
|
||||
- name: azure-cli
|
||||
image: mcr.microsoft.com/azure-cli
|
||||
command:
|
||||
- sh
|
||||
- -c
|
||||
- az login --identity --debug
|
||||
```
|
||||
|
||||
### [Job](https://kubernetes.io/docs/concepts/workloads/controllers/job/)
|
||||
|
||||
```yaml
|
||||
apiVersion: batch/v1
|
||||
kind: Job
|
||||
metadata:
|
||||
name: azure-cli
|
||||
spec:
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
aadpodidbinding: <selector defined in AzureIdentityBinding>
|
||||
spec:
|
||||
containers:
|
||||
- name: azure-cli
|
||||
image: mcr.microsoft.com/azure-cli
|
||||
command:
|
||||
- sh
|
||||
- -c
|
||||
- az login --identity --debug
|
||||
restartPolicy: Never
|
||||
backoffLimit: 4
|
||||
```
|
||||
|
||||
### [CronJob](https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/)
|
||||
|
||||
```yaml
|
||||
apiVersion: batch/v1beta1
|
||||
kind: CronJob
|
||||
metadata:
|
||||
name: azure-cli
|
||||
spec:
|
||||
schedule: "*/1 * * * *"
|
||||
jobTemplate:
|
||||
spec:
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
aadpodidbinding: <selector defined in AzureIdentityBinding>
|
||||
spec:
|
||||
containers:
|
||||
- name: azure-cli
|
||||
image: mcr.microsoft.com/azure-cli
|
||||
command:
|
||||
- sh
|
||||
- -c
|
||||
- az login --identity --debug
|
||||
restartPolicy: OnFailure
|
||||
```
|
||||
|
|
@ -1,59 +0,0 @@
|
|||
## Feature flags
|
||||
|
||||
## Enable Scale Features flag
|
||||
> Available from 1.5.3 release
|
||||
|
||||
Aad-pod-identity adds labels to AzureAssignedIdentities which denote the nodename, podname and podnamespace.
|
||||
When the optional parameter `enabledScaleFeatures` is set to 'true', the NMI watches for AzureAssignedIdentities will do a label based filtering on
|
||||
the nodename label. This approach is taken because currently K8s does not support field selectors in CRD watches. This reduces the load which
|
||||
NMIs add on API server. When this flag is enabled, NMI will no longer work for AzureAssignedIdentities which were created before 1.5.3-rc5, since
|
||||
they don't have the labels. Hence please note that this flag renders your setup incompatible with releases before 1.5.3-rc5.
|
||||
|
||||
## Batch Create Delete flag
|
||||
> Available from 1.5.3 release
|
||||
|
||||
MIC groups operations based on nodes/VMSS during the given cycle. With `createDeleteBatch` parameter we can
|
||||
tune the number of operations (CREATE/DELETE/UPDATE) to the API server which are performed in parallel in the context of a
|
||||
node/VMSS.
|
||||
|
||||
## Client QPS flag
|
||||
> Available from 1.5.3 release
|
||||
|
||||
Aad-pod-identity has a new flag clientQps which can be used to control the total number of client operations performed per second
|
||||
to the API server by MIC.
|
||||
|
||||
## Block Instance Metadata flag
|
||||
|
||||
The Azure Metadata API includes endpoints under `/metadata/instance` which
|
||||
provide information about the virtual machine. You can see examples of this
|
||||
endpoint in [the Azure documentation](https://docs.microsoft.com/en-us/azure/virtual-machines/linux/instance-metadata-service#retrieving-all-metadata-for-an-instance).
|
||||
|
||||
Some of the information returned by this endpoint may be considered sensitive
|
||||
or secret. The response includes information on the operating system and image,
|
||||
tags, resource IDs, network, and VM custom data.
|
||||
|
||||
This information is legitimately useful for many use cases, but also presents a
|
||||
risk. If an attacker can exploit a vulnerability that allows them to read from
|
||||
this endpoint, they may be able to access sensitive information even if the
|
||||
vulnerable Pod does not use Managed Identity.
|
||||
|
||||
The `blockInstanceMetadata` flag for NMI will intercept any requests to this
|
||||
endpoint from Pods which are not using host networking and return an HTTP 403
|
||||
Forbidden response. This flag is disabled by default to maximize compatibility.
|
||||
Users are encouraged to determine if this option is relevant and beneficial for
|
||||
their use cases.
|
||||
|
||||
## ImmutableUserMSIs flag
|
||||
> Available from 1.5.4 release
|
||||
|
||||
Aad-pod-identity has a new flag `immutable-user-msis` which can be used to prevent deletion of specified identities from VM/VMSS.
|
||||
The list is comma separated. Example: 00000000-0000-0000-0000-000000000000,11111111-1111-1111-1111-111111111111
|
||||
|
||||
## Metadata header required flag
|
||||
> Available from 1.6.0 release
|
||||
|
||||
When you query the Instance Metadata Service, you must provide the header `Metadata: true` to ensure the request was not unintentionally redirected. You can see examples of this header in [the Azure documentation](https://docs.microsoft.com/en-us/azure/virtual-machines/linux/instance-metadata-service#using-headers).
|
||||
|
||||
This is critical especially when you [acquire an access token](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/how-to-use-vm-token#get-a-token-using-http) as a mitigation against Server Side Request Forgery (SSRF) attack.
|
||||
|
||||
The `metadataHeaderRequired` flag for NMI will block all requests without Metadata header and return an HTTP 400 response. This flag is disabled by default for compatibility, but recommended for users to enable this feature.
|
||||
|
|
@ -1,38 +0,0 @@
|
|||
# Known Issues
|
||||
|
||||
This section lists the major known issues with aad-pod-identity. For a complete list of issues, please check our [GitHub issues page](https://github.com/Azure/aad-pod-identity/issues) or [file a new issue](https://github.com/Azure/aad-pod-identity/issues/new?assignees=&labels=bug&template=bug_report.md&title=) if your issue is not listed.
|
||||
|
||||
- NMI pods not yet running during a cluster autoscaling event
|
||||
- User-assigned managed identity deleted and recreated with the same name in Azure
|
||||
|
||||
## NMI pods not yet running during a cluster autoscaling event
|
||||
|
||||
NMI redirects Instance Metadata Service (IMDS) requests to itself by setting up iptables rules after it starts running on the node. During cluster scale up, there **might** be a scenario where the `kube-scheduler` schedules the workload pod before the NMI pod on the new nodes. In such a scenario, the token request will be directly sent to IMDS instead of being intercepted by NMI. What this means is that the workload pod that runs before the NMI pod on the node can access identities that it doesn't have access to.
|
||||
|
||||
There is currently no solution in Kubernetes where a node can be set to `NoSchedule` until critical addons have been deployed to the cluster. There was a KEP for this particular enhancement - [kubernetes/enhancements#1003](https://github.com/kubernetes/enhancements/pull/1003) which is now closed.
|
||||
|
||||
## User-assigned managed identity deleted and recreated with the same name in Azure
|
||||
|
||||
When the user-assigned managed identities have been deleted and re-created in Azure with the same name, the changes aren't automatically reflected in the identities on the underlying VM/VMSS. `az <vm|vmss> identity show -g <resource group> -n <VM/VMSS name>` command output will show the identity with `null` principalID and clientID. Token request for this identity will fail with "identity not found" error.
|
||||
|
||||
```json
|
||||
{
|
||||
"principalId": null,
|
||||
"tenantId": null,
|
||||
"type": "UserAssigned",
|
||||
"userAssignedIdentities": {
|
||||
"/subscriptions/<sub>/resourcegroups/<resource group>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<identity name>": {
|
||||
"clientId": "null",
|
||||
"principalId": "null"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
Steps to take if the identity was deleted and re-created with same name -
|
||||
|
||||
1. Remove identity manually from the VM/VMSS by running `az <vm|vmss> identity remove -g <rg> -n <VM/VMSS name> --identities <identity resource id>`
|
||||
2. Update the `AzureIdentity` with the new clientID for the recreated identity
|
||||
|
||||
MIC will detect the change in `AzureIdentity` and reassign the identity. This reassignment will ensure the identity with correct clientID exists on the underlying VM/VMSS.
|
||||
|
|
@ -1,43 +0,0 @@
|
|||
# Pod Identity in Managed mode
|
||||
> Available from 1.6.0 release
|
||||
|
||||
## Introduction
|
||||
|
||||
Starting from 1.6.0 release, 2 modes of operation are supported for pod-identity
|
||||
- Standard Mode
|
||||
- Managed Mode
|
||||
|
||||
### Standard Mode
|
||||
|
||||
This is the default mode in which pod-identity will be deployed. In this mode, there are 2 components, MIC (Managed Identity Controller) and NMI (Node Managed Identity). MIC handles the identity assignment/removal from the underlying vm/vmss when new pods using the identity are created/deleted.
|
||||
|
||||
### Managed Mode
|
||||
|
||||
In this mode, there is only the NMI component deployed in the cluster. The identity assignment needs to be manually performed.
|
||||
|
||||
Deploy `aad-pod-identity` components to an RBAC-enabled cluster in managed mode:
|
||||
|
||||
- This installs NMI in managed mode in the kube-system namespace
|
||||
|
||||
```bash
|
||||
kubectl apply -f https://raw.githubusercontent.com/Azure/aad-pod-identity/master/deploy/infra/managed-mode-deployment.yaml
|
||||
```
|
||||
|
||||
**NOTE** Managed mode is only supported in namespaced mode. This ensures pods in namespace are only matched with `AzureIdentity` and `AzureIdentityBinding` in the same namespace.
|
||||
|
||||
To assign the identity to the VM, run the following command -
|
||||
|
||||
```shell
|
||||
az vm identity assign -g <VM resource group name> -n <VM name> --identities <resource ID of managed identity>
|
||||
```
|
||||
|
||||
To assign the identity to VMSS, run the following command -
|
||||
|
||||
```shell
|
||||
az vmss identity assign -g <VM resource group name> -n <VM name> --identities <resource ID of managed identity>
|
||||
```
|
||||
|
||||
## Why use Managed mode
|
||||
|
||||
- Identity assignment on VM takes 10-20s and 40-60s in case of VMSS. In case of cronjobs or applications that require access to the identity and can't tolerate the assignment delay, it's best to use managed mode as the identity is manually pre-assigned to the VM/VMSS.
|
||||
- In standard mode, MIC requires write permissions on VM/VMSS and Managed Identity Operator permission on all user assigned MSIs. While running in managed mode, since there is no MIC, the role assignments are not required.
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
# Features
|
||||
|
||||
1. [Match Pods in the Namespace](README.namespaced.md)
|
||||
2. [Non cluster credentials for MIC](README.noazure-json.md)
|
||||
3. [Application exception](README.app-exception.md)
|
||||
4. [Validation using gatekeeper](README.validation.md)
|
||||
5. [Feature flags](README.featureflags.md)
|
||||
6. [Managed mode](README.managed-mode.md)
|
||||
7. [Monitoring with Prometheus](README.monitoring.md)
|
||||
|
||||
# Others
|
||||
|
||||
1. [Pod Security Policy (PSP)](README.pod-security-policy.md)
|
||||
2. [Troubleshooting](README.troubleshooting.md)
|
||||
3. [Role Assignment](README.role-assignment.md)
|
||||
4. [Known Issues](README.known-issues.md)
|
||||
5. [Best Practices](README.best-practices.md)
|
||||
|
|
@ -1,78 +0,0 @@
|
|||
# Azure Identity Monitoring
|
||||
|
||||
## Introduction
|
||||
|
||||
AAD pod identity is a foundational service that other applications depend upon, it is recommended to monitor the same.
|
||||
|
||||
Liveliness probe and Prometheus metrics are available in both Managed Identity Controller (MIC) and the Node Managed Identity (NMI) components.
|
||||
|
||||
## Liveliness Probe
|
||||
|
||||
MIC and NMI exposes /healthz endpoint with content of "Active/Not Active" state.
|
||||
State "Active" is being returned if the component has started successfully and "Not Active" otherwise.
|
||||
|
||||
## Prometheus Metrics
|
||||
|
||||
[Prometheus](https://github.com/prometheus/prometheus) is a systems and service monitoring system. It collects metrics from configured targets at given intervals, evaluates rule expressions,displays the results, and can trigger alerts if some condition is observed to be true.
|
||||
|
||||
The following [OpenCensus](https://opencensus.io/) metrics are exposed in AAD pod identity system via prometheus exporter.
|
||||
|
||||
**1. aadpodidentity_assigned_identity_addition_duration_seconds**
|
||||
|
||||
Histogram that tracks the duration (in seconds) it takes for Assigned identity addition operations.
|
||||
|
||||
**2. aadpodidentity_assigned_identity_addition_count**
|
||||
|
||||
Counter that tracks the cumulative number of assigned identity addition operations.
|
||||
|
||||
**3. aadpodidentity_assigned_identity_deletion_duration_seconds**
|
||||
|
||||
Histogram that tracks the duration (in seconds) it takes for Assigned identity deletion operations.
|
||||
|
||||
**4. aadpodidentity_assigned_identity_deletion_count**
|
||||
|
||||
Counter that tracks the cumulative number of assigned identity deletion operations.
|
||||
|
||||
**5. aadpodidentity_nmi_operations_duration_seconds**
|
||||
|
||||
Histogram that tracks the latency (in seconds) of NMI operations to complete. Broken down by operation type, status code.
|
||||
|
||||
**6. aadpodidentity_mic_cycle_duration_seconds**
|
||||
|
||||
Histogram that tracks the duration (in seconds) it takes for a single cycle in MIC.
|
||||
|
||||
**7. aadpodidentity_mic_cycle_count**
|
||||
|
||||
Counter that tracks the number of cycles executed in MIC.
|
||||
|
||||
**8. aadpodidentity_mic_new_leader_election_count**
|
||||
|
||||
Counter that tracks the cumulative number of new leader election in MIC.
|
||||
|
||||
**9. aadpodidentity_cloud_provider_operations_errors_count**
|
||||
|
||||
Counter that tracks the cumulative number of cloud provider operations errors. Broken down by operation type.
|
||||
|
||||
**10. aadpodidentity_cloud_provider_operations_duration_seconds**
|
||||
|
||||
Histogram that tracks the duration (in seconds) it takes for cloud provider operations. Broken down by operation type.
|
||||
|
||||
**11. aadpodidentity_kubernetes_api_operations_errors_count**
|
||||
|
||||
Counter that tracks the cumulative number of kubernetes api operations errors. Broken down by operation type.
|
||||
|
||||
**12. aadpodidentity_imds_operations_errors_count**
|
||||
|
||||
Counter that tracks the cumulative number of imds token operation errors. Broken down by operation type.
|
||||
|
||||
**13. aadpodidentity_imds_operations_duration_seconds**
|
||||
|
||||
Histogram that tracks the duration (in seconds) it takes for IMDS token operations. Broken down by operation type.
|
||||
|
||||
### Prometheus Metrics Endpoints
|
||||
|
||||
| Component | Default Metric Port | Metric Path |
|
||||
|:---------:|---------------------|-------------|
|
||||
| `NMI` | `9090` | `/metrics` |
|
||||
| `MIC` | `8888` | `/metrics` |
|
||||
|
||||
|
|
@ -1,40 +0,0 @@
|
|||
# Match Pods in the Namespace
|
||||
> Available from [1.3.0-mic-1.4.0-nmi release](https://github.com/Azure/aad-pod-identity/releases/tag/1.3.0-mic-1.4.0-nmi)
|
||||
|
||||
By default, AAD Pod Identity matches pods to identities across namespaces. To match only pods in the namespace containing `AzureIdentity`, use one of these techniques:
|
||||
|
||||
* Attach a `aadpodidentity.k8s.io/Behavior: namespaced` [annotation] to each `AzureIdentity` resource.
|
||||
|
||||
Here is the `AzureIdentity` manifest from the previous step with this annotation added:
|
||||
|
||||
```yaml
|
||||
apiVersion: "aadpodidentity.k8s.io/v1"
|
||||
kind: AzureIdentity
|
||||
metadata:
|
||||
name: <a-idname>
|
||||
annotations:
|
||||
aadpodidentity.k8s.io/Behavior: namespaced
|
||||
spec:
|
||||
type: 0
|
||||
resourceID: /subscriptions/<subid>/resourcegroups/<resourcegroup>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<name>
|
||||
clientID: <clientId>
|
||||
```
|
||||
|
||||
* Add the `--forceNamespaced` command line argument or set the `FORCENAMESPACED=true` environment variable when starting both the MIC and NMI components.
|
||||
|
||||
Here is a section from the MIC deployment which adds *both* the command line argument and the environment variable for illustration. Pick one approach and use it to update both the MIC deployment and the NMI daemon set.
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
containers:
|
||||
- name: mic
|
||||
image: "mcr.microsoft.com/k8s/aad-pod-identity/mic:1.3"
|
||||
imagePullPolicy: Always
|
||||
args:
|
||||
- "--cloudconfig=/etc/kubernetes/azure.json"
|
||||
- "--logtostderr"
|
||||
- "--forceNamespaced"
|
||||
env:
|
||||
- name: FORCENAMESPACED
|
||||
value: "true"
|
||||
```
|
||||
|
|
@ -1,56 +0,0 @@
|
|||
# Deploy AAD Pod Identity with a dedicated service principal
|
||||
> Available from 1.5 release
|
||||
|
||||
## The why
|
||||
|
||||
Goal: To enable user to use a separate service principal (aad-pod-identity admin service principal) other than the cluster service princial and to move away from `/etc/kubernetes/azure.json`.
|
||||
|
||||
Users now have the option to deploy aad-pod-identity with a separate service principal which is together with its secret and other configurations stored in a Kubernetes secret object.
|
||||
|
||||
## Permissions
|
||||
|
||||
The permission of the admin service principal needs to be 'Contributor' role over the scope of node resource group starting with "MC_".
|
||||
|
||||
Create a new service principal with the permission:
|
||||
|
||||
```
|
||||
az ad sp create-for-rbac -n "<sp_name>" --role "Contributor" --scopes "/subscriptions/<subscription-id>/resourceGroups/<MC_node_resource_group>"
|
||||
```
|
||||
|
||||
> Note the `appId` (client id), `password` (secret) and `tenant` from the resulting json, which will be used in creating the admin secret.
|
||||
|
||||
Or assign the permission for an existing service principal:
|
||||
|
||||
```
|
||||
az role assignment create --role "Contributor" --assignee <sp_id> --scope "/subscriptions/<subscription-id>/resourceGroups/<MC_node_resource_group>"
|
||||
```
|
||||
|
||||
For any subsequent user assigned managed identity that's intended for a pod, it's also required to grant the service principal 'Managed Identity Operator' permission (also stated [here](../../../README.md#6-set-permissions-for-mic)):
|
||||
|
||||
```
|
||||
az role assignment create --role "Managed Identity Operator" --assignee <sp_id> --scope <resource id of the managed identity>
|
||||
```
|
||||
|
||||
## Create the admin secret
|
||||
|
||||
The `aadpodidentity-admin-secret` contains the following fields:
|
||||
|
||||
* Cloud: `<base64-encoded-cloud>`
|
||||
* 'Cloud' should be chosen from the following case-insensitive values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud` (values taken from [here](https://raw.githubusercontent.com/Azure/go-autorest/master/autorest/azure/environments.go)).
|
||||
* SubscriptionID: `<base64-encoded-subscription-id>`
|
||||
* ResourceGroup: `<base64-encoded-resource-group>`
|
||||
* 'ResourceGroup' is the node resource group where the actual virtual machines or virtual machine scale set resides.
|
||||
* VMType: `<base64-encoded-vm-type>`
|
||||
* 'VMType' is optional and can be one of these values: `standard` for normal virtual machine nodes, and `vmss` for cluster deployed with a virtual machine scale set.
|
||||
* TenantID: `<base64-encoded-tenant-id>`
|
||||
* ClientID: `<base64-encoded-client-id>`
|
||||
* ClientSecret: `<base64-encoded-client-secret>`
|
||||
* 'TenantID', 'ClientID' and 'ClientSecret' are service principal's `tenant`, `appId`, `password` respectively.
|
||||
|
||||
> Use `echo -n 'secret-content' | base64` to create a base64 encoded string.
|
||||
|
||||
Fill out those secret values in the /deploy/infra/noazurejson/deployment.yaml or /deploy/infra/noazurejson/deployment-rbac.yaml before executing `kubectl create -f ./deploy/infra/noazurejson/deployment.yaml` or `kubectl create -f ./deploy/infra/noazurejson/deployment-rbac.yaml`.
|
||||
|
||||
> Note that if not use the above yaml's, `aadpodidentity-admin-secret` must be created before deploying `mic` and `mic` must reference the secret as shown in the yaml's.
|
||||
|
||||
The secret will be injected as an environment variable into `mic` upon pod creation and cannot be updated during the lifecycle of `mic`. However, redeploying `mic` should pick up the updated service principal's information should they change.
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
# Policy to allow aad-pod-identity to work in PSP enabled clusters
|
||||
|
||||
The NMI component of aad-pod-identity runs on `hostNetwork` and in `privileged` mode. If the cluster has Pod Security Policies (PSP) enabled that block `hostNetwork` and `privileged` mode, then the aad-pod-identity will be unable to run. The following step will create a PSP that allows the required access for aad-pod-identity components only in the desired namespace -
|
||||
|
||||
|
||||
```bash
|
||||
kubectl apply -f https://raw.githubusercontent.com/Azure/aad-pod-identity/master/examples/psp-podidentity.yaml
|
||||
```
|
||||
|
|
@ -1,85 +0,0 @@
|
|||
# Role Assignment
|
||||
|
||||
AKS and aks-engine clusters require an identity to communicate with Azure. This identity can be either a **managed identity** (in the form of system-assigned identity or user-assigned identity) or a **service principal**. This section explains various role assignments that need to be performed before using AAD Pod Identity. Without the proper role assignments, your Azure cluster will not have the correct permission to assign and un-assign identities from the underlying virtual machines (VM) or virtual machine scale sets (VMSS).
|
||||
|
||||
## TL;DR
|
||||
|
||||
Run the following commands to help you set up the appropriate role assignments for your cluster identity before deploying aad-pod-identity (assuming you are running an AKS cluster):
|
||||
|
||||
```bash
|
||||
export SUBSCRIPTION_ID="<SubscriptionID>"
|
||||
export RESOURCE_GROUP="<AKSResourceGroup>"
|
||||
export CLUSTER_NAME="<AKSClusterName>"
|
||||
export CLUSTER_LOCATION="<AKSClusterLocation>"
|
||||
|
||||
# if you are planning to deploy your user-assigned identities in a separate resource group
|
||||
export IDENTITY_RESOURCE_GROUP="<IdentityResourceGroup>"
|
||||
|
||||
./hack/role-assignment.sh
|
||||
```
|
||||
|
||||
> Note: `<AKSResourceGroup>` is where your AKS cluster is deployed to.
|
||||
|
||||
## Introduction
|
||||
|
||||
Currently, [MIC](../../README.md#managed-identity-controller) uses one of the following two ways to authenticate with Azure:
|
||||
|
||||
1. [Managed Identity](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) (system-assigned identity or user-assigned identity)
|
||||
2. [Service Principal](https://docs.microsoft.com/en-us/azure/aks/kubernetes-service-principal) through `/etc/kubernetes/azure.json`, which is available in every node, or credentials defined by environment variables;
|
||||
|
||||
> Clusters with managed identity are only compatible with AAD Pod Identity 1.5+.
|
||||
|
||||
## More on authentication methods
|
||||
|
||||
[`/etc/kubernetes/azure.json`](https://github.com/kubernetes-sigs/cloud-provider-azure/blob/master/docs/cloud-provider-config.md#auth-configs) is a well-known JSON file in each node that provides the details about which method MIC uses for authentication:
|
||||
|
||||
| Authentication method | `/etc/kubernetes/azure.json` fields used |
|
||||
|----------------------------------------|---------------------------------------------------------------------------------------------|
|
||||
| System-assigned managed identity | `useManagedIdentityExtension: true` and `userAssignedIdentityID:""` |
|
||||
| User-assigned managed identity | `useManagedIdentityExtension: true` and `userAssignedIdentityID:"<UserAssignedIdentityID>"` |
|
||||
| Service principal (default) | `aadClientID: "<AADClientID>"` and `aadClientSecret: "<AADClientSecret>"` |
|
||||
|
||||
## Obtaining the ID of the managed identity / service principal
|
||||
|
||||
After your cluster is provisioned, depending on your cluster identity configuration, run one of the following commands to retrieve the **ID** of your managed identity or service principal, which will be used for role assignment in the next section:
|
||||
|
||||
| Cluster configuration | Command |
|
||||
|--------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| AKS cluster with service principal | `az aks show -g <AKSResourceGroup> -n <AKSClusterName> --query servicePrincipalProfile.clientId -otsv` |
|
||||
| AKS cluster with managed identity | `az aks show -g <AKSResourceGroup> -n <AKSClusterName> --query identityProfile.kubeletidentity.clientId -otsv` |
|
||||
| aks-engine cluster with service principal | Use the client ID of the service principal defined in the API model |
|
||||
| aks-engine cluster with system-assigned identity | `az <vm\|vmss> identity show -g <ClusterResourceGroup> -n <VM\|VMSS Name> --query principalId -otsv` |
|
||||
| aks-engine cluster with user-assigned identity | `az <vm\|vmss> identity show -g <ClusterResourceGroup> -n <VM\|VMSS Name> --query userAssignedIdentities -otsv`, then copy the `clientID` of the selected user-assigned identity |
|
||||
|
||||
## Performing role assignments
|
||||
|
||||
The roles [**Managed Identity Operator**](https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#managed-identity-operator) and [**Virtual Machine Contributor**](https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-contributor) must be assigned to the cluster managed identity or service principal, identified by the **ID** obtained above, before deploying AAD Pod Identity so that it can assign and un-assign identities from the underlying VM/VMSS.
|
||||
|
||||
> For AKS cluster, the cluster resource group refers to the resource group with a `MC_` prefix, which contains all of the infrastructure resources associated with the cluster like VM/VMSS.
|
||||
|
||||
```bash
|
||||
az role assignment create --role "Managed Identity Operator" --assignee <ID> --scope /subscriptions/<SubscriptionID>/resourcegroups/<ClusterResourceGroup>
|
||||
az role assignment create --role "Virtual Machine Contributor" --assignee <ID> --scope /subscriptions/<SubscriptionID>/resourcegroups/<ClusterResourceGroup>
|
||||
```
|
||||
|
||||
> RBAC and non-RBAC clusters require the same role assignments.
|
||||
|
||||
## User-assigned identities that are not within the cluster resource group
|
||||
|
||||
There are additional role assignments required if you wish to assign user-assigned identities that are not within the cluster resource group. You can run the following command to assign the **Managed Identity Operator** role with the identity resource group scope:
|
||||
|
||||
```bash
|
||||
az role assignment create --role "Managed Identity Operator" --assignee <ID> --scope /subscriptions/<SubscriptionID>/resourcegroups/<IdentityResourceGroup>
|
||||
```
|
||||
|
||||
To enable fine-grained control on which user-assigned identity the cluster has access to, run the following command:
|
||||
|
||||
```bash
|
||||
az role assignment create --role "Managed Identity Operator" --assignee <ID> --scope /subscriptions/<SubscriptionID>/resourcegroups/<IdentityResourceGroup>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<IdentityName>
|
||||
```
|
||||
|
||||
## Useful links
|
||||
|
||||
- [Use managed identities in AKS](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity)
|
||||
- [Service principals with AKS](https://docs.microsoft.com/en-us/azure/aks/kubernetes-service-principal)
|
||||
- [What are managed identities for Azure resources?](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview)
|
||||
|
|
@ -1,134 +0,0 @@
|
|||
# Troubleshooting
|
||||
|
||||
## Logging
|
||||
|
||||
Below is a list of commands you can use to view relevant logs of aad-pod-identity [components](../../README.md#components).
|
||||
|
||||
### Isolate errors from logs
|
||||
|
||||
You can use `grep ^E` and `--since` flag from `kubectl` to isolate any errors occurred after a given duration.
|
||||
|
||||
```bash
|
||||
kubectl logs -l component=mic --since=1h | grep ^E
|
||||
kubectl logs -l component=nmi --since=1h | grep ^E
|
||||
```
|
||||
|
||||
> It is always a good idea to include relevant logs from MIC and NMI when opening a new [issue](https://github.com/Azure/aad-pod-identity/issues).
|
||||
|
||||
### Ensure that iptables rule exists
|
||||
|
||||
To ensure that the correct iptables rule is injected to each node via the [NMI](../../README.md#node-managed-identity) pods, the following command ensures that on a given node, there exists an iptables rule where all packets with a destination IP of 169.254.169.254 (IMDS endpoint) are routed to port 2579 of the host network.
|
||||
|
||||
```bash
|
||||
NMI_POD=$(kubectl get pod -l component=nmi -ojsonpath='{.items[?(@.spec.nodeName=="<NodeName>")].metadata.name}')
|
||||
kubectl exec $NMI_POD -- iptables -t nat -S aad-metadata
|
||||
```
|
||||
|
||||
The expected output should be:
|
||||
|
||||
```log
|
||||
-N aad-metadata
|
||||
-A aad-metadata ! -s 127.0.0.1/32 -d 169.254.169.254/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.240.0.34:2579
|
||||
-A aad-metadata -j RETURN
|
||||
```
|
||||
|
||||
### Run a pod to validate your identity setup
|
||||
|
||||
You could run the following commands to validate your identity setup (assuming you have the proper `AzureIdentity` and `AzureIdentityBinding` deployed):
|
||||
|
||||
```bash
|
||||
kubectl run azure-cli -it --image=mcr.microsoft.com/azure-cli --labels=aadpodidbinding=<selector defined in AzureIdentityBinding> /bin/bash
|
||||
|
||||
# within the azure-cli shell
|
||||
az login -i --debug
|
||||
```
|
||||
|
||||
`az login -i` will use the Azure identity bound to the `azure-cli` pod and perform a login to Azure via Azure CLI. If succeeded, you would have an output as below:
|
||||
|
||||
```log
|
||||
urllib3.connectionpool : Starting new HTTP connection (1): 169.254.169.254:80
|
||||
urllib3.connectionpool : http://169.254.169.254:80 "GET /metadata/identity/oauth2/token?resource=https%3A%2F%2Fmanagement.core.windows.net%2F&api-version=2018-02-01 HTTP/1.1" 200 1667
|
||||
msrestazure.azure_active_directory : MSI: Retrieving a token from http://169.254.169.254/metadata/identity/oauth2/token, with payload {'resource': 'https://management.core.windows.net/', 'api-version': '2018-02-01'}
|
||||
msrestazure.azure_active_directory : MSI: Token retrieved
|
||||
MSI: token was retrieved. Now trying to initialize local accounts...
|
||||
...
|
||||
[
|
||||
{
|
||||
"environmentName": "AzureCloud",
|
||||
"homeTenantId": "<REDACTED>",
|
||||
"id": "<REDACTED>",
|
||||
"isDefault": true,
|
||||
"managedByTenants": [],
|
||||
"name": "<REDACTED>",
|
||||
"state": "Enabled",
|
||||
"tenantId": "<REDACTED>",
|
||||
"user": {
|
||||
"assignedIdentityInfo": "MSI",
|
||||
"name": "systemAssignedIdentity",
|
||||
"type": "servicePrincipal"
|
||||
}
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
Based on the logs above, Azure CLI was able to retrieve a token from `http://169.254.169.254:80/metadata/identity/oauth2/token`. Its request is routed to the NMI pod that is running within the same node. Identify which node the Azure CLI pod is scheduled to by running the following command:
|
||||
|
||||
```bash
|
||||
kubectl get pods -owide
|
||||
|
||||
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
|
||||
azure-cli 1/1 Running 1 12s 10.240.0.117 k8s-agentpool1-95854893-vmss000002 <none> <none>
|
||||
```
|
||||
|
||||
Take a note at the node the pod is scheduled to and its IP address. Check the logs of the NMI pod that is scheduled to the same node. You should be able to see a token requested by the azure-cli pod, identified by its pod IP address `10.240.0.117`:
|
||||
|
||||
```bash
|
||||
kubectl logs <nmi pod name>
|
||||
|
||||
...
|
||||
I0821 18:22:50.810806 1 standard.go:72] no clientID or resourceID in request. default/azure-cli has been matched with azure identity default/demo
|
||||
I0821 18:22:50.810895 1 standard.go:178] matched identityType:0 clientid:7eb6##### REDACTED #####a6a9 resource:https://management.core.windows.net/
|
||||
I0821 18:22:51.348117 1 server.go:190] status (200) took 537597287 ns for req.method=GET reg.path=/metadata/identity/oauth2/token req.remote=10.240.0.117
|
||||
...
|
||||
```
|
||||
|
||||
## Common Issues
|
||||
|
||||
Common issues or questions that users have run into when using pod identity are detailed below.
|
||||
|
||||
### Ignoring azure identity \<podns\>/\<podname\>, error: Invalid resource id: "", must match /subscriptions/\<subid\>/resourcegroups/\<resourcegroup\>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/\<name\>
|
||||
|
||||
If you are using MIC v1.6.0+, you will need to ensure the correct capitalization of `AzureIdentity` and `AzureIdentityBinding` fields. For more information, please refer to [this section](../../README.md#v160-breaking-change).
|
||||
|
||||
### LinkedAuthorizationFailed
|
||||
|
||||
If you received the following error message in MIC:
|
||||
|
||||
```log
|
||||
Code="LinkedAuthorizationFailed" Message="The client '<ClientID>' with object id '<ObjectID>' has permission to perform action 'Microsoft.Compute/<VMType>/write' on scope '<VM/VMSS scope>'; however, it does not have permission to perform action 'Microsoft.ManagedIdentity/userAssignedIdentities/assign/action' on the linked scope(s) '<UserAssignedIdentityScope>' or the linked scope(s) are invalid."
|
||||
```
|
||||
|
||||
It means that your cluster service principal / managed identity does not have the correct role assignment to assign the chosen user-assigned identities to the VM/VMSS. For more information, please follow this [documentation](README.role-assignment.md) to allow your cluster service principal / managed identity to perform identity-related operation.
|
||||
|
||||
Past issues:
|
||||
|
||||
- https://github.com/Azure/aad-pod-identity/issues/585
|
||||
|
||||
### Unable to remove `AzureAssignedIdentity` after MIC pods are deleted
|
||||
|
||||
With release `1.6.1`, finalizers have been added to `AzureAssignedIdentity` to ensure the identities are successfully cleaned up by MIC before they're deleted. However, in scenarios where the MIC deployment is force deleted before it has completed the clean up of identities from the underlying node, the `AzureAssignedIdentity` will be left behind as it contains a finalizer.
|
||||
|
||||
To delete all `AzureAssignedIdentity`, run the following command:
|
||||
```bash
|
||||
kubectl get azureassignedidentity -A -o=json | jq '.items[].metadata.finalizers=null' | kubectl apply -f -
|
||||
kubectl delete azureassignedidentity --all
|
||||
```
|
||||
|
||||
To delete only a specific `AzureAssignedIdentity`, run the following command:
|
||||
```bash
|
||||
kubectl get azureassignedidentity <name> -n <namespace> -o=json | jq '.items[].metadata.finalizers=null' | kubectl apply -f -
|
||||
kubectl delete azureassignedidentity <name> -n <namespace>
|
||||
```
|
||||
|
||||
Past issues:
|
||||
- https://github.com/Azure/aad-pod-identity/issues/644
|
||||
|
|
@ -1,152 +0,0 @@
|
|||
# Azure Identity Validation
|
||||
|
||||
## Introduction
|
||||
|
||||
This will help validate various CRDs and the azure resources used in aad-pod-identity.
|
||||
Currently validation of User assigned MSI format in Azure Identity is supported.
|
||||
|
||||
[Gatekeeper](https://github.com/open-policy-agent/gatekeeper) - Policy Controller for Kubernetes, is used to validate the resources.
|
||||
* It is a validating webhook that enforces CRD based policies
|
||||
* Provides admission system which allows to configure policy and rule as constraint
|
||||
|
||||
#### Prerequisite Gatekeeper Installation
|
||||
|
||||
Run the following to deploy a release version of Gatekeeper in your cluster or refer to [Gatekeeper Installation](https://github.com/open-policy-agent/gatekeeper#installation-instructions) for detailed instructions.
|
||||
|
||||
```sh
|
||||
kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/deploy/gatekeeper.yaml
|
||||
```
|
||||
|
||||
## Azure Identity Format Validation
|
||||
|
||||
Policy can be configured as Gatekeeper constraint to ensure the validity of the Resource ID format in the given identity.Request will be rejected by admission controller in case of any violation of the configured constraint.
|
||||
|
||||
Following are the two major resources to enable this check.
|
||||
|
||||
* Constraint Template
|
||||
* Constraint
|
||||
|
||||
### Constraint Template
|
||||
|
||||
`ConstraintTemplate` describes both the [Rego](https://www.openpolicyagent.org/docs/v0.10.7/how-do-i-write-policies/) that enforces the constraint and the schema of the constraint.
|
||||
|
||||
* User assigned MSI is expected to have Resource ID in the given format.
|
||||
|
||||
```
|
||||
/subscriptions/<subid>/resourcegroups/<resourcegroup>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<name>
|
||||
```
|
||||
|
||||
The same can be validate using the following regex pattern. Resource ID that does not match this pattern is considered invalid.
|
||||
|
||||
```
|
||||
(?i)/subscriptions/(.+?)/resourcegroups/(.+?)/providers/Microsoft.ManagedIdentity/(.+?)/(.+)
|
||||
```
|
||||
|
||||
* Policy to ensure Resource ID is following expected pattern can be described via following Constraint template
|
||||
|
||||
```yaml
|
||||
apiVersion: templates.gatekeeper.sh/v1beta1
|
||||
kind: ConstraintTemplate
|
||||
metadata:
|
||||
name: azureidentityformat
|
||||
spec:
|
||||
crd:
|
||||
spec:
|
||||
names:
|
||||
kind: azureidentityformat
|
||||
listKind: azureidentityformatList
|
||||
plural: azureidentityformat
|
||||
singular: azureidentityformat
|
||||
targets:
|
||||
- target: admission.k8s.gatekeeper.sh
|
||||
rego: |
|
||||
package azureidentityformat
|
||||
violation[{"msg": msg}] {
|
||||
input.review.kind.kind == "AzureIdentity"
|
||||
# format of resourceId is checked only for user-assigned MSI
|
||||
input.review.object.spec.type == 0
|
||||
resourceId := input.review.object.spec.resourceID
|
||||
result := re_match(`(?i)/subscriptions/(.+?)/resourcegroups/(.+?)/providers/Microsoft.ManagedIdentity/(.+?)/(.+)`,resourceId)
|
||||
result == false
|
||||
msg := sprintf(`The identity resourceId '%v' is invalid.It must be of the following format: '/subscriptions/<subid>/resourcegroups/<resourcegroup>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<name>'`,[resourceId])
|
||||
}
|
||||
```
|
||||
|
||||
You can install this ConstraintTemplate with the following command:
|
||||
|
||||
```sh
|
||||
kubectl apply -f https://raw.githubusercontent.com/Azure/aad-pod-identity/master/validation/gatekeeper/azureidentityformat_template.yaml
|
||||
```
|
||||
|
||||
### Constraint
|
||||
|
||||
Constraint is used to inform Gatekeeper that the admin wants azureidentityformat ConstraintTemplate to be enforced.
|
||||
|
||||
If the constraint is violated by any request on Kind `AzureIdentity` in apiGroup `aadpodidentity.k8s.io`, request will be rejected via the admission controller.
|
||||
|
||||
```yaml
|
||||
apiVersion: constraints.gatekeeper.sh/v1beta1
|
||||
kind: azureidentityformat
|
||||
metadata:
|
||||
name: azureidentityformatconstraint
|
||||
spec:
|
||||
match:
|
||||
kinds:
|
||||
- apiGroups: ["aadpodidentity.k8s.io"]
|
||||
kinds: ["AzureIdentity"]
|
||||
```
|
||||
|
||||
You can install this Constraint with the following command:
|
||||
|
||||
```sh
|
||||
kubectl apply -f https://raw.githubusercontent.com/Azure/aad-pod-identity/master/validation/gatekeeper/azureidentityformat_constraint.yaml
|
||||
```
|
||||
|
||||
### Examples
|
||||
|
||||
* Following identity will pass the constraint and request will be accepted, as the resource ID is in the correct format.
|
||||
|
||||
```yaml
|
||||
apiVersion: "aadpodidentity.k8s.io/v1"
|
||||
kind: AzureIdentity
|
||||
metadata:
|
||||
name: testidentityvalid
|
||||
spec:
|
||||
type: 0
|
||||
resourceID: /subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/testidentity
|
||||
clientID: 00000000-0000-0000-0000-000000000000
|
||||
```
|
||||
|
||||
* Following identity will violate the constraint and request will be rejected, as resource ID is not of correct format (`resourcegroups/<resourcegroup>` is missing in resourceID).
|
||||
|
||||
```yaml
|
||||
apiVersion: "aadpodidentity.k8s.io/v1"
|
||||
kind: AzureIdentity
|
||||
metadata:
|
||||
name: testidentityinvalid
|
||||
spec:
|
||||
type: 0
|
||||
resourceID: /subscriptions/00000000-0000-0000-0000-000000000000/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myidentity
|
||||
clientID: 00000000-0000-0000-0000-000000000000
|
||||
```
|
||||
|
||||
```sh
|
||||
kubectl apply -f aadpodidentity_test_invalid.yaml
|
||||
Error from server ([denied by azureidentityformatconstraint] The identity resourceId '/subscriptions/00000000-0000-0000-0000-000000000000/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myidentity' is invalid.It must be of the following format: '/subscriptions/<subid>/resourcegroups/<resourcegroup>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<name>'): error when creating "aadpodidentity_test_invalid.yaml": admission webhook "validation.gatekeeper.sh" denied the request: [denied by azureidentityformatconstraint] The identity resourceId '/subscriptions/00000000-0000-0000-0000-000000000000/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myidentity' is invalid.It must be of the following format: '/subscriptions/<subid>/resourcegroups/<resourcegroup>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<name>'
|
||||
```
|
||||
|
||||
|
||||
### Uninstallation
|
||||
|
||||
#### Uninstall Constraint Template & Constraint
|
||||
|
||||
* Delete instances of the constraint resource
|
||||
* Delete the ConstraintTemplate` resource
|
||||
|
||||
Run the following to uninstall / disable validation.
|
||||
|
||||
```sh
|
||||
kubectl delete -f https://raw.githubusercontent.com/Azure/aad-pod-identity/master/validation/gatekeeper/azureidentityformat_constraint.yaml
|
||||
|
||||
kubectl delete -f https://raw.githubusercontent.com/Azure/aad-pod-identity/master/validation/gatekeeper/azureidentityformat_template.yaml
|
||||
```
|
||||
Двоичные данные
docs/tutorial/images/k8s-endpoint-vsts.png
Двоичные данные
docs/tutorial/images/k8s-endpoint-vsts.png
Двоичный файл не отображается.
|
До Ширина: | Высота: | Размер: 12 KiB |
Двоичные данные
docs/tutorial/images/vsts-deploy-tasks.png
Двоичные данные
docs/tutorial/images/vsts-deploy-tasks.png
Двоичный файл не отображается.
|
До Ширина: | Высота: | Размер: 24 KiB |
|
|
@ -12,7 +12,6 @@ production-build: bootstrap
|
|||
hugo --minify
|
||||
|
||||
preview-build: bootstrap
|
||||
npm i
|
||||
hugo \
|
||||
--baseURL $(DEPLOY_PRIME_URL) \
|
||||
--buildDrafts \
|
||||
|
|
|
|||
|
|
@ -117,7 +117,7 @@ github_repo = "https://github.com/Azure/aad-pod-identity"
|
|||
github_project_repo = "https://github.com/Azure/aad-pod-identity/issues/new?assignees=&labels=bug&template=bug_report.md&title="
|
||||
|
||||
# Specify a value here if your content directory is not in your repo's root directory
|
||||
github_subdir = "userguide"
|
||||
github_subdir = "website"
|
||||
|
||||
time_format_blog = "Monday, January 02, 2006"
|
||||
time_format_default = "January 2, 2006"
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ linkTitle = "Azure AD Pod Identity"
|
|||
|
||||
{{< blocks/cover title="Microsoft's Azure AD Pod Identity Project" image_anchor="top" height="full" color="blue" >}}
|
||||
<div class="mx-auto">
|
||||
<a class="btn btn-lg btn-secondary mr-3 mb-4" href="/docs/">
|
||||
<a class="btn btn-lg btn-secondary mr-3 mb-4" href="{{< relref "/docs" >}}">
|
||||
Get Started </i>
|
||||
</a>
|
||||
<p class="lead mt-5">An Azure Compute OSS Upstream Team project that enables Kubernetes applications to access cloud resources securely with Azure Active Directory (AAD).</p>
|
||||
|
|
@ -37,4 +37,3 @@ Find out about new features and how our users are using Docsy.
|
|||
-->
|
||||
|
||||
{{< /blocks/section >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -104,7 +104,7 @@ metadata:
|
|||
|
||||
By default, aad-pod-identity matches pods with `AzureIdentities` across all namespaces. That means that a malicious pod could assign itself an unauthorized pod identity label and acquire a token with that particular `AzureIdentity`. This scenario can be mitigated by performing the following:
|
||||
|
||||
- Deploy aad-pod-identity with [namespaced mode](README.namespaced.md). This will restrict pods from binding with `AzureIdentities` across different namespaces. Note that `AzureIdentities` and `AzureIdentityBindings` must be deployed to the same namespace as your workload when using namespaced mode.
|
||||
- Deploy aad-pod-identity with [namespaced mode](../configure/match_pods_in_namespace/). This will restrict pods from binding with `AzureIdentities` across different namespaces. Note that `AzureIdentities` and `AzureIdentityBindings` must be deployed to the same namespace as your workload when using namespaced mode.
|
||||
|
||||
- Set up Kubernetes-native RBAC to restrict access and creation of `AzureIdentities` across sensitive namespaces.
|
||||
|
||||
|
|
|
|||
|
|
@ -23,10 +23,10 @@ spec:
|
|||
app: custom
|
||||
```
|
||||
|
||||
Use the [sample template](../../examples/azurepodidentityexception.yaml), replace the podLabels with a list of desired values and then create the resource on the cluster:
|
||||
Use the [sample template](https://github.com/Azure/aad-pod-identity/blob/master/examples/azurepodidentityexception.yaml), replace the podLabels with a list of desired values and then create the resource on the cluster:
|
||||
|
||||
```shell
|
||||
kubectl apply -f examples/aadpodidentityexception.yaml
|
||||
kubectl apply -f https://raw.githubusercontent.com/Azure/aad-pod-identity/master/examples/azurepodidentityexception.yaml
|
||||
```
|
||||
|
||||
When creating application pods that will not be using aad-pod-identity for calls to Azure Instance Metadata endpoint, include at least one of the labels in `spec.template.metadata.labels`.
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ Following are the two major resources to enable this check.
|
|||
|
||||
### Constraint Template
|
||||
|
||||
`ConstraintTemplate` describes both the [Rego](https://www.openpolicyagent.org/docs/v0.10.7/how-do-i-write-policies/) that enforces the constraint and the schema of the constraint.
|
||||
`ConstraintTemplate` describes both the [Rego](https://www.openpolicyagent.org/docs/latest/policy-language/) that enforces the constraint and the schema of the constraint.
|
||||
|
||||
* User assigned MSI is expected to have Resource ID in the given format.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: "Deploy AAD Pod Identity with a Dedicated Service Principle"
|
||||
linkTitle: "Deploy AAD Pod Identity with a Dedicated Service Principle"
|
||||
title: "Deploy AAD Pod Identity with a Dedicated Service Principal"
|
||||
linkTitle: "Deploy AAD Pod Identity with a Dedicated Service Principal"
|
||||
weight: 2
|
||||
description: >
|
||||
To enable user to use a separate service principal (aad-pod-identity admin service principal) other than the cluster service princial and to move away from /etc/kubernetes/azure.json.
|
||||
|
|
@ -32,7 +32,7 @@ Or assign the permission for an existing service principal:
|
|||
az role assignment create --role "Contributor" --assignee <sp_id> --scope "/subscriptions/<subscription-id>/resourceGroups/<MC_node_resource_group>"
|
||||
```
|
||||
|
||||
For any subsequent user assigned managed identity that's intended for a pod, it's also required to grant the service principal 'Managed Identity Operator' permission (also stated [here](../../../README.md#6-set-permissions-for-mic)):
|
||||
For any subsequent user assigned managed identity that's intended for a pod, it's also required to grant the service principal 'Managed Identity Operator' permission (also stated [here](../../getting-started/role-assignment/)):
|
||||
|
||||
```
|
||||
az role assignment create --role "Managed Identity Operator" --assignee <sp_id> --scope <resource id of the managed identity>
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ description: >
|
|||
|
||||
By default, AAD Pod Identity matches pods to identities across namespaces. To match only pods in the namespace containing `AzureIdentity`, use one of these techniques:
|
||||
|
||||
* Attach a `aadpodidentity.k8s.io/Behavior: namespaced` [annotation] to each `AzureIdentity` resource.
|
||||
* Attach a `aadpodidentity.k8s.io/Behavior: namespaced` annotation to each `AzureIdentity` resource.
|
||||
|
||||
Here is the `AzureIdentity` manifest from the previous step with this annotation added:
|
||||
|
||||
|
|
|
|||
|
|
@ -33,4 +33,4 @@ End-to-end testing tests whether the flow of aad-pod-identity from start to fini
|
|||
|
||||
- Define test spec reflecting real user workflow, e.g. [creation of AzureIdentity, AzureIdentityBinding and a pod that consumes the identity](https://github.com/Azure/aad-pod-identity/blob/5c9c5e541d6612c31af4d09dc0ec7654388cc076/test/e2e/single_identity_test.go#L33-L96).
|
||||
|
||||
See [test/e2e/README.md](./test/e2e/README.md) on how to run the aad-pod-identity e2e test suite locally.
|
||||
See [test/e2e/README.md](https://github.com/Azure/aad-pod-identity/blob/master/test/e2e/README.md) on how to run the aad-pod-identity e2e test suite locally.
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ az login
|
|||
az account set -s "${SUBSCRIPTION_ID}"
|
||||
```
|
||||
|
||||
> For AKS clusters, there are two resource groups that you need to be aware of - the resource group where you deploy your AKS cluster to (denoted by the environment variable `RESOURCE_GROUP`), and the cluster resource group (`MC_<AKSResourceGroup>_<AKSClusterName>_<AKSClusterLocation>`). The latter contains all of the infrastructure resources associated with the cluster like VM/VMSS and VNet. Depending on where you deploy your user-assigned identities, you might need additional role assignments. Please refer to [Role Assignment](#role-assignment) for more information. For this demo, it is recommended to deploy the demo identity to your cluster resource group (the one with `MC_` prefix).
|
||||
> For AKS clusters, there are two resource groups that you need to be aware of - the resource group where you deploy your AKS cluster to (denoted by the environment variable `RESOURCE_GROUP`), and the cluster resource group (`MC_<AKSResourceGroup>_<AKSClusterName>_<AKSClusterLocation>`). The latter contains all of the infrastructure resources associated with the cluster like VM/VMSS and VNet. Depending on where you deploy your user-assigned identities, you might need additional role assignments. Please refer to [Role Assignment](../../getting-started/role-assignment/) for more information. For this demo, it is recommended to deploy the demo identity to your cluster resource group (the one with `MC_` prefix).
|
||||
|
||||
### 1. Deploy aad-pod-identity
|
||||
|
||||
|
|
@ -53,7 +53,7 @@ helm install aad-pod-identity aad-pod-identity/aad-pod-identity
|
|||
|
||||
For a list of overwritable values when installing with Helm, please refer to [this section](https://github.com/Azure/aad-pod-identity/tree/master/charts/aad-pod-identity#configuration).
|
||||
|
||||
> Important: For AKS clusters with limited [egress-traffic], Please install pod-identity in `kube-system` namespace using the [helm charts].
|
||||
> Important: For AKS clusters with [limited egress traffic](https://docs.microsoft.com/en-us/azure/aks/limit-egress-traffic), Please install aad-pod-identity in `kube-system` namespace using the helm charts.
|
||||
|
||||
```bash
|
||||
helm install aad-pod-identity aad-pod-identity/aad-pod-identity --namespace=kube-system
|
||||
|
|
@ -96,7 +96,7 @@ EOF
|
|||
|
||||
### 4. (Optional) Match pods in the namespace
|
||||
|
||||
For matching pods in the namespace, please refer to the [namespaced documentation](docs/readmes/README.namespaced.md).
|
||||
For matching pods in the namespace, please refer to the [namespaced documentation](../../configure/match_pods_in_namespace/).
|
||||
|
||||
### 5. Deploy `AzureIdentityBinding`
|
||||
|
||||
|
|
@ -116,7 +116,7 @@ EOF
|
|||
|
||||
### 6. Deployment and Validation
|
||||
|
||||
For a pod to match an identity binding, it needs a [label] with the key `aadpodidbinding` whose value is that of the `selector:` field in the `AzureIdentityBinding`. Deploy a pod that validates the functionality:
|
||||
For a pod to match an identity binding, it needs a label with the key `aadpodidbinding` whose value is that of the `selector:` field in the `AzureIdentityBinding`. Deploy a pod that validates the functionality:
|
||||
|
||||
```bash
|
||||
cat << EOF | kubectl apply -f -
|
||||
|
|
@ -152,7 +152,7 @@ spec:
|
|||
EOF
|
||||
```
|
||||
|
||||
> `mcr.microsoft.com/oss/azure/aad-pod-identity/demo` is an image that demostrates the use of AAD pod identity. The source code can be found [here](./cmd/demo/main.go).
|
||||
> `mcr.microsoft.com/oss/azure/aad-pod-identity/demo` is an image that demostrates the use of AAD pod identity. The source code can be found [here](https://github.com/Azure/aad-pod-identity/blob/master/cmd/demo/main.go).
|
||||
|
||||
To verify that the pod is indeed using the identity correctly:
|
||||
|
||||
|
|
|
|||
|
|
@ -12,17 +12,13 @@ This tutorial is based on [this repository](https://github.com/xtellurian/aad-po
|
|||
|
||||
- [Azure Account](https://azure.microsoft.com/en-us/free/)
|
||||
|
||||
In this tutorial we are going to be using the Azure CLI, bash scripts, and kubectl. There are three sections, and each section contains several scripts to run. You'll find all the scripts in the `/scripts` directory.
|
||||
|
||||
Lines like `./scripts/path/to/script.sh` indicate you should execute that script.
|
||||
In this tutorial we are going to be using the Azure CLI, bash scripts, and kubectl. There are three sections, and each section contains several scripts to run. You'll find all the scripts in the `tutorial` directory.
|
||||
|
||||
To begin, clone this repository
|
||||
|
||||
```sh
|
||||
|
||||
git clone https://github.com/Azure/aad-pod-identity
|
||||
cd aad-pod-identity/docs/tutorial
|
||||
|
||||
cd aad-pod-identity/tutorial
|
||||
```
|
||||
|
||||
### Using Azure CLI, kubectl and bash
|
||||
|
|
@ -39,7 +35,7 @@ You can install kubectl via the Azure CLI, or by [another method](https://kubern
|
|||
|
||||
### 1.1. Register the required resource types
|
||||
|
||||
`./scripts/1-init-aks/1-azure-provider-registration.sh`
|
||||
`./1-init-aks/1-azure-provider-registration.sh`
|
||||
|
||||
AKS requires the following resources: Microsoft.Network, Microsoft.Storage, Microsoft.Compute, Microsoft.ContainerService. Register them on your subscription with the above script.
|
||||
|
||||
|
|
@ -52,17 +48,15 @@ Set an environment variable in your shell, for the name of your resource group.
|
|||
|
||||
This resource group is for your AKS cluster. Create it with this command.
|
||||
|
||||
`./scripts/1-init-aks/2-create-rg.sh`
|
||||
`./1-init-aks/2-create-rg.sh`
|
||||
|
||||
### 1.3. Create Azure Kubernetes Service
|
||||
|
||||
This will create an AKS instance in the resource group created above. It may take a couple of minutes to complete. Set the name of the this command in the shell.
|
||||
|
||||
```sh
|
||||
|
||||
K8S_NAME="Cluster-Name"
|
||||
./scripts/1-init-aks/3-create-aks.sh
|
||||
|
||||
./1-init-aks/3-create-aks.sh
|
||||
```
|
||||
|
||||
|
||||
|
|
@ -70,16 +64,14 @@ K8S_NAME="Cluster-Name"
|
|||
|
||||
With `kubectl` installed, run the following script
|
||||
|
||||
`./scripts/1-init-aks/4-configure-cli.sh`
|
||||
`./1-init-aks/4-configure-cli.sh`
|
||||
|
||||
Now the `kubectl` command should control your AKS cluster. Try it out, it should look similar to below:
|
||||
|
||||
```sh
|
||||
|
||||
$ kubectl get nodes
|
||||
NAME STATUS ROLES AGE VERSION
|
||||
aks-nodepool1-15831963-0 Ready agent 01h v1.9.6
|
||||
|
||||
```
|
||||
|
||||
## 2. Configure AKS with required infrastructure on the cluster
|
||||
|
|
@ -91,7 +83,7 @@ Pod Identity requires two components:
|
|||
|
||||
Deploy the infrastructure with the following command to deploy MIC, NMI, and MIC CRDs.
|
||||
|
||||
`./scripts/2-config-aks/2-deploy-infra.sh`
|
||||
`./2-config-aks/2-deploy-infra.sh`
|
||||
|
||||
NOTE: If you have RBAC enabled, use the following deployment instead:
|
||||
|
||||
|
|
@ -117,7 +109,7 @@ Then set the environment variable
|
|||
|
||||
Run the following to create an azure id
|
||||
|
||||
`./scripts/3-deploy-demo/1-create-azure-id.sh`
|
||||
`./3-deploy-demo/1-create-azure-id.sh`
|
||||
|
||||
### 3.2. Deploy demo
|
||||
|
||||
|
|
@ -131,7 +123,7 @@ It automatically adds the following values from your environment:
|
|||
|
||||
Run the following to deploy the demo
|
||||
|
||||
`./scripts/3-deploy-demo/2-deploy-demo.sh`
|
||||
`./3-deploy-demo/2-deploy-demo.sh`
|
||||
|
||||
### 3.3. Deploy Azure Id to Kubernetes
|
||||
|
||||
|
|
@ -139,7 +131,7 @@ We need to tell the cluster about the Id we created, so it can bind it to the po
|
|||
|
||||
Run the following to deploy the Azure ID to Kubernetes:
|
||||
|
||||
`./scripts/3-deploy-demo/3-deploy-id-to-k8s.sh`
|
||||
`./3-deploy-demo/3-deploy-id-to-k8s.sh`
|
||||
|
||||
### 3.4. Bind the Id to our demo pod
|
||||
|
||||
|
|
@ -147,7 +139,7 @@ Last thing we need to do is bind the Id we created in step 1, and deployed in st
|
|||
|
||||
Deploy the binding with the following
|
||||
|
||||
`./scripts/3-deploy-demo/4-deploy-id-binding.sh`
|
||||
`./3-deploy-demo/4-deploy-id-binding.sh`
|
||||
|
||||
## Did it work?
|
||||
|
||||
|
|
@ -156,13 +148,11 @@ You'll need to check the logs of each pod to know if everything worked.
|
|||
First, get the pod names with the following command:
|
||||
|
||||
```sh
|
||||
|
||||
$ kubectl get pods
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
demo-757967c54-64pzr 1/1 Running 0 1h # the demo pod
|
||||
mic-64ddcf5f65-h4hft 1/1 Running 0 19h # the MIC pod
|
||||
nmi-b9xbg 1/1 Running 0 1h # the NMI pod
|
||||
|
||||
```
|
||||
|
||||
### Check the Managed Identity Controller pod
|
||||
|
|
@ -170,7 +160,6 @@ nmi-b9xbg 1/1 Running 0 1h # the NMI pod
|
|||
Check the logs of the MIC controller and see the binding successfully applied on the node.
|
||||
|
||||
```sh
|
||||
|
||||
$ kubectl logs mic-64ddcf5f65-h4hft
|
||||
....
|
||||
I0606 23:19:45.867711 1 crd.go:123] Got id podid to assign
|
||||
|
|
@ -179,7 +168,6 @@ I0606 23:19:45.874002 1 cloudprovider.go:170] Find aks-nodepool1-15831963-
|
|||
I0606 23:20:11.051552 1 cloudprovider.go:162] Underlying cloud provider operation took 25.04421296s
|
||||
I0606 23:20:11.051846 1 mic.go:259] Sync took: 25.220821436s
|
||||
I0606 23:20:11.052905 1 event.go:218] Event(v1.ObjectReference{Kind:"AzureIdentityBinding", Namespace:"default", Name:"myIdBinding", UID:"19a07e0e-69e0-11e8-9e9f-4addade2df92", APIVersion:"aadpodidentity.k8s.io/v1", ResourceVersion:"89529", FieldPath:""}): type: 'Normal' reason: 'binding applied' Binding myIdBinding applied on node aks-nodepool1-15831963-0 for pod demo-5788d95785-ghzwv-default-podid
|
||||
|
||||
```
|
||||
|
||||
### Check the Node Managed Identity pod
|
||||
|
|
@ -187,12 +175,10 @@ I0606 23:20:11.052905 1 event.go:218] Event(v1.ObjectReference{Kind:"Azure
|
|||
Check the logs of the NMI pod to see only info level logging and 200 responses. If you see 403 or 404 responses, then something is wrong.
|
||||
|
||||
```sh
|
||||
|
||||
$ kubectl logs nmi-b9xbg
|
||||
...
|
||||
time="2018-06-07T01:30:04Z" level=info msg="Status (200) took 55422159 ns" req.method=GET req.path=/metadata/identity/oauth2/token req.remote=10.244.0.25
|
||||
time="2018-06-07T01:30:04Z" level=info msg="matched identityType:0 clientid:a40e83f9-6198-4633-afae-d860eb5b7f7c resource:https://management.azure.com/" req.method=GET req.path=/metadata/identity/oauth2/token req.remote=10.244.0.25
|
||||
|
||||
```
|
||||
|
||||
### Check the demo pod
|
||||
|
|
@ -200,14 +186,12 @@ time="2018-06-07T01:30:04Z" level=info msg="matched identityType:0 clientid:a40e
|
|||
The demo pod should be reporting on the virtual machines in the resource group. If you see intermittant 403 responses, that is OK.
|
||||
|
||||
```sh
|
||||
|
||||
$ kubectl logs demo-757967c54-64pzr
|
||||
...
|
||||
time="2018-06-07T01:32:30Z" level=error msg="failed list all vm compute.VirtualMachinesClient#List: Failure responding to request: StatusCode=403 -- Original Error: autorest/azure: Service returned an error. Status=403 Code=\"AuthorizationFailed\" Message=\"The client '48affddb-9972-4b7e-a82b-c5d32d2a3dd5' with object id '48affddb-9972-4b7e-a82b-c5d32d2a3dd5' does not have authorization to perform action 'Microsoft.Compute/virtualMachines/read' over scope '/subscriptions/c5760548-23c2-4223-b41e-5d68a8320a0c/resourceGroups/MC_k8s-test_clusterFrank_eastus/providers/Microsoft.Compute'.\"" podip=10.244.0.25 podname=demo-757967c54-64pzr podnamespace=demo-757967c54-64pzr
|
||||
time="2018-06-07T01:32:30Z" level=info msg="successfully acquired a token using the MSI, msiEndpoint(http://169.254.169.254/metadata/identity/oauth2/token)" podip=10.244.0.25 podname=demo-757967c54-64pzr podnamespace=demo-757967c54-64pzr
|
||||
time="2018-06-07T01:32:30Z" level=info msg="successfully acquired a token, userAssignedID MSI, msiEndpoint(http://169.254.169.254/metadata/identity/oauth2/token) clientID(a40e83f9-6198-4633-afae-d860eb5b7f7c)" podip=10.244.0.25 podname=demo-757967c54-64pzr podnamespace=demo-757967c54-64pzr
|
||||
time="2018-06-07T01:32:30Z" level=info msg="successfully made GET on instance metadata, {\"compute\":{\"location\":\"eastus\",\"name\":\"aks-nodepool1-15831963-0\",\"offer\":\"UbuntuServer\",\"osType\":\"Linux\",\"placementGroupId\":\"\",\"platformFaultDomain\":\"0\",\"platformUpdateDomain\":\"0\",\"publisher\":\"Canonical\",\"resourceGroupName\":\"MC_k8s-test_clusterFrank_eastus\",\"sku\":\"16.04-LTS\",\"subscriptionId\":\"c5760548-23c2-4223-b41e-5d68a8320a0c\",\"tags\":\"acsengineVersion:v0.17.0-aks;creationSource:aks-aks-nodepool1-15831963-0;orchestrator:Kubernetes:1.9.6;poolName:nodepool1;resourceNameSuffix:15831963\",\"version\":\"16.04.201805090\",\"vmId\":\"3fea4c7e-4aaf-400f-a588-2a851f6fd0cf\",\"vmSize\":\"Standard_DS1_v2\"},\"network\":{\"interface\":[{\"ipv4\":{\"ipAddress\":[{\"privateIpAddress\":\"10.240.0.4\",\"publicIpAddress\":\"\"}],\"subnet\":[{\"address\":\"10.240.0.0\",\"prefix\":\"16\"}]},\"ipv6\":{\"ipAddress\":[]},\"macAddress\":\"000D3A13DEE3\"}]}}" podip=10.244.0.25 podname=demo-757967c54-64pzr podnamespace=demo-757967c54-64pzr
|
||||
|
||||
```
|
||||
|
||||
### Check the descriptions
|
||||
|
|
@ -216,39 +200,6 @@ time="2018-06-07T01:32:30Z" level=info msg="successfully made GET on instance me
|
|||
|
||||
`kubectl describe azureidentitybinding`
|
||||
|
||||
### Video
|
||||
### AAD Pod Identity In Action
|
||||
|
||||
[](https://www.youtube.com/watch?v=BXhIMJYDO4w)
|
||||
|
||||
## Continuous Deployment with VSTS
|
||||
|
||||
This section is optional.
|
||||
|
||||
It shows how to deploy the same pods and infrastructure as above using [VSTS Continuous Integration](https://www.visualstudio.com/team-services/continuous-integration/).
|
||||
|
||||
### Configure Kubernetes Connection in VSTS
|
||||
|
||||
Give VSTS permission to use your Kubernetes cluster by adding the endpoint to your project. Click the Cog Wheel, and go to Services. Add a new endpoint, and choose Kubernetes. See [this tutorial](https://almvm.azurewebsites.net/labs/vstsextend/kubernetes/) for a more details.
|
||||
|
||||
|
||||
|
||||
### Release Definition
|
||||
|
||||
Create a new empty Release Definition, and add this repository and a source with alias `_aad_pods`
|
||||
|
||||
Add a Task of type 'Deploy to Kubernetes'. Create one of these tasks for each of the following:
|
||||
|
||||
> The command of each is `apply`, and the each below shows the reqired arguments.
|
||||
|
||||
- `-f _aad-pods/deploy/infra/deployment.yaml`
|
||||
- `-f _aad-pods/deploy/demo/deployment.yaml`
|
||||
- `-f _aad-pods/deploy/demo/aadpodidentity.yaml`
|
||||
- `-f _aad-pods/deploy/demo/aadpodidentitybinding.yaml`
|
||||
|
||||
The result should look like this
|
||||
|
||||
|
||||
|
||||
### Customising each Deployment
|
||||
|
||||
You probably don't want to deploy the same Demo every time. To customise the Kubernetes deployment, use the [YAML Writer](https://marketplace.visualstudio.com/items?itemName=jakkaj.vsts-yaml-writer) extension, and edit the values in the YAML files.
|
||||
|
|
@ -4,9 +4,11 @@ linkTitle: "Design"
|
|||
weight: 3
|
||||
date: 2020-10-04
|
||||
description: >
|
||||
An overview of all the Kubernetes components and thier relationship.
|
||||
An overview of all the Kubernetes components and their relationship.
|
||||
---
|
||||
|
||||
|
||||
|
||||
## AAD and Kubernetes
|
||||
|
||||
The relationship between kubernetes and AAD is covered in three main areas:
|
||||
|
|
@ -21,19 +23,19 @@ The relationship between kubernetes and AAD is covered in three main areas:
|
|||
|
||||
## Use cases
|
||||
|
||||
1. kubernetes applications depending on other applications that use AAD as an identity provider. These applications include Azure 1st party services (such as ARM, Azure sql or Azure storage) or user applications running on Azure (including same cluster) and or on premises.
|
||||
1. Kubernetes applications depending on other applications that use AAD as an identity provider. These applications include Azure first party services such as ARM, Azure SQL, and Azure KeyVault.
|
||||
|
||||
> Azure 1st party services are all moving to use AAD as the primary identity provider.
|
||||
> Azure 1st party services are all moving to use AAD as the primary identity provider.
|
||||
|
||||
2. Delegating authorization to user familiar tools such as AAD group memberships.
|
||||
2. Delegating authorization to tools such as AAD group memberships.
|
||||
|
||||
3. Enable identity rotation without application interruption.
|
||||
|
||||
> Example: rotating a service principal password/cert without having to edit secrets assigned directly to applications.
|
||||
> Example: rotating a service principal password/cert without having to edit secrets assigned directly to applications.
|
||||
|
||||
4. Provide a framework to enable time-boxed identity assignment. Manually triggered or automated. The same framework can be used for (jit sudo style access with automation tools).
|
||||
|
||||
> Example: a front end application can have access to centralized data store between midnight and 1 AM during business days only.
|
||||
> Example: a front end application can have access to centralized data store between midnight and 1 AM during business days only.
|
||||
|
||||
## Guiding Principles
|
||||
|
||||
|
|
@ -41,11 +43,9 @@ The relationship between kubernetes and AAD is covered in three main areas:
|
|||
|
||||
2. Favor little to no change in the way users create kubernetes application specs (favor declarative approach). This enables users to focus their development and debugging experience in code they wrote, not code imposed on them.
|
||||
|
||||
> Example: favor annotation and labels over side-cars (even dynamically injected).
|
||||
> Example: favor annotation and labels over side-cars (even dynamically injected).
|
||||
|
||||
3. Prep for SPIFFE work currently in progress by the wider community.
|
||||
|
||||
4. Separate identities from `identity assignment` applications enables users to swap identities used by the applications.
|
||||
3. Separate identities from `identity assignment` applications enables users to swap identities used by the applications.
|
||||
|
||||
## Processes
|
||||
|
||||
|
|
@ -53,17 +53,7 @@ The relationship between kubernetes and AAD is covered in three main areas:
|
|||
|
||||
- Cluster operators create instances of `crd:azureIdentity`. Each instance is a kubernetes object representing Azure AAD identity that can be EMSI or service principal (with password).
|
||||
|
||||
- Cluster operators create instances of `crd:azureIdentityBinding`. Each instance represents binding between `pod` and `crd:azureIdentity`. The binding initially will use (one of)
|
||||
1. Selectors
|
||||
2. Explicit assignment to applications (?)
|
||||
3. Weight (used in case of a single pod matched by multiple identities)
|
||||
|
||||
At later phases, the binding will use:
|
||||
|
||||
1. Expiration time (static: bind until Jan 1/1/2019. Dynamic: for 10 mins).
|
||||
2. ...?
|
||||
|
||||
> All identity bindings actions are logged as `events` to `crd:azureIdentity`. Allowing clusters operators to track how the system assigned identities to various apps.
|
||||
- Cluster operators create instances of `crd:azureIdentityBinding`. Each instance represents binding between `pod` and `crd:azureIdentity`.
|
||||
|
||||
- A Controller will run to create `crd:azureAssignedIdentity` based on `crd:azureIdentityBinding` linking `pod` with `crd:azureIdentity`.
|
||||
|
||||
|
|
@ -72,70 +62,7 @@ At later phases, the binding will use:
|
|||
> for reference please read [Azure VM Managed Service Identity (MSI)](https://docs.microsoft.com/en-us/azure/active-directory/managed-service-identity/how-to-use-vm-token) and [Assign a Managed Service Identity](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/howto-assign-access-portal)
|
||||
|
||||
1. Kubernetes applications (pods) will default to use MSI endpoint.
|
||||
|
||||
2. All traffic to MSI endpoint is routed via `iptables` to a daemon-set that will use `sourceIp` to identify pod, then find an appropriate `crd:azureIdentityBinding`. The daemon-set mimics all the REST api offered by MSI endpoint. All tokens are presented to pods on MSI endpoint irrespective of the identity used to back this request (EMSI or service principal).
|
||||
|
||||
> As SPIFFE becomes more mature pod identity assertion is expected to use SPIFFE pod identity.
|
||||
|
||||
3. All token issuance will be logged as events attached to `crd:azureIdentityBinding` for audit purposes.
|
||||
|
||||
## Controllers
|
||||
|
||||
A single `azureIdentityController` controller is use to:
|
||||
|
||||
1. Create instances of `azureAssignedIdentity` as a result of `crd:azureIdentityBinding` matching.
|
||||
2. Assign EMSI to nodes where pods are scheduled to run. Assignment are logged to `crd:azureIdentity` as events.
|
||||
|
||||
> The controller can later expose an endpoint for analysis where operators can request analysis of identities, pod assignment.
|
||||
|
||||
## RBAC
|
||||
<<POD/azureAssignedIdentity>> ??
|
||||
|
||||
## Api
|
||||
|
||||
### azureIdentity
|
||||
|
||||
A custom resource definition object that represents either
|
||||
|
||||
1. Explicit Managed Service Identity (EMSI).
|
||||
2. Service Principal.
|
||||
|
||||
```yaml
|
||||
<<Object details>>
|
||||
type: <EMSI/Principal>
|
||||
secretRef: <Principal Password>
|
||||
```
|
||||
|
||||
> Identities are created separately by azure cli. ARM RBAC and data plane specific role assignment is done on each service, application or resource.
|
||||
|
||||
### azureIdentityBinding
|
||||
|
||||
A custom resource definition object used to describe `azureIdentity` is assigned to pod.
|
||||
|
||||
```yaml
|
||||
<<object details>>
|
||||
azureIdentityRef: xxx
|
||||
type: <Explicit/Selector>
|
||||
weight: ??
|
||||
timeBox: <<future time box details>>
|
||||
```
|
||||
|
||||
### azureAssignedIdentity
|
||||
|
||||
A custom resource definition object. Each instance represents linking `pod` to `azureIdentity`
|
||||
|
||||
```yaml
|
||||
<<object details>>
|
||||
azureIdentityRef: xxx
|
||||
podRef: xxx
|
||||
```
|
||||
|
||||
## Plan
|
||||
|
||||
### Phase 1
|
||||
|
||||
1. Api, controller and daemon set (excluding time boxed assignment).
|
||||
|
||||
### Phase 2
|
||||
|
||||
1. Time box assignment
|
||||
2. SPIFFE integration
|
||||
|
До Ширина: | Высота: | Размер: 46 KiB После Ширина: | Высота: | Размер: 46 KiB |
|
|
@ -27,14 +27,4 @@ export IDENTITY_RESOURCE_GROUP="<IdentityResourceGroup>"
|
|||
|
||||
> Note: `<AKSResourceGroup>` is where your AKS cluster is deployed to.
|
||||
|
||||
For more details, please refer to the [role assignment](./docs/readmes/README.role-assignment.md) documentation.
|
||||
|
||||
|
||||
## What's next?
|
||||
|
||||
* [Add content and customize your site](/docs/adding-content/)
|
||||
* Get some ideas from our [Example Site](https://github.com/google/docsy-example) and other [Examples](/docs/examples/).
|
||||
* [Publish your site](/docs/deployment/).
|
||||
|
||||
|
||||
|
||||
For more details, please refer to the [role assignment](role-assignment) documentation.
|
||||
|
|
|
|||
|
|
@ -8,13 +8,13 @@ description: >
|
|||
|
||||
### Managed Identity Controller
|
||||
|
||||
The Managed Identity Controller (MIC) is a Kubernetes [custom resource] that watches for changes to pods, `AzureIdentity` and `AzureIdentityBindings` through the Kubernetes API server. When it detects a relevant change, the MIC adds or deletes `AzureAssignedIdentity` as needed.
|
||||
The Managed Identity Controller (MIC) is a Kubernetes controller that watches for changes to pods, `AzureIdentity` and `AzureIdentityBindings` through the Kubernetes API server. When it detects a relevant change, the MIC adds or deletes `AzureAssignedIdentity` as needed.
|
||||
|
||||
Specifically, when a pod is scheduled, the MIC assigns the identity on Azure to the underlying VM/VMSS during the creation phase. When the pod is deleted, it removes the identity from the underlying VM/VMSS on Azure. The MIC takes similar actions when `AzureIdentity` or `AzureIdentityBinding` are created or deleted.
|
||||
|
||||
### Node Managed Identity
|
||||
|
||||
The authorization request to fetch a Service Principal Token from an MSI endpoint is sent to Azure Instance Metadata Service (IMDS) endpoint (169.254.169.254), which is redirected to the NMI pod. The redirection is accomplished by adding iptable rules to redirect all non-host traffic with IMDS endpoint on port 80 as destination to the NMI endpoint. The NMI server identifies the pod based on the remote address of the request and then queries Kubernetes (through MIC) for a matching Azure identity. NMI then makes an Azure Active Directory Authentication Library ([ADAL]) request to get the token for the client ID and returns it as a response. If the request had client ID as part of the query, it is validated against the admin-configured client ID.
|
||||
The authorization request to fetch a Service Principal Token from an MSI endpoint is sent to Azure Instance Metadata Service (IMDS) endpoint (169.254.169.254), which is redirected to the NMI pod. The redirection is accomplished by adding iptable rules to redirect all non-host traffic with IMDS endpoint on port 80 as destination to the NMI endpoint. The NMI server identifies the pod based on the remote address of the request and then queries Kubernetes (through MIC) for a matching Azure identity. NMI then makes an Azure Active Directory Authentication Library ([ADAL](https://docs.microsoft.com/en-us/azure/active-directory/azuread-dev/active-directory-authentication-libraries)) request to get the token for the client ID and returns it as a response. If the request had client ID as part of the query, it is validated against the admin-configured client ID.
|
||||
|
||||
Here is an example cURL command that will fetch an access token to access ARM within a pod identified by an AAD-Pod-Identity selector:
|
||||
|
||||
|
|
@ -32,4 +32,4 @@ Here is an example cURL command:
|
|||
curl http://127.0.0.1:2579/host/token/?resource=https://vault.azure.net -H "podname: nginx-flex-kv-int" -H "podns: default"
|
||||
```
|
||||
|
||||
For more information, please refer to the [design documentation](./docs/design/concept.md).
|
||||
For more information, please refer to the [design documentation](../../design).
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ export IDENTITY_RESOURCE_GROUP="<IdentityResourceGroup>"
|
|||
|
||||
## Introduction
|
||||
|
||||
Currently, [MIC](../../README.md#managed-identity-controller) uses one of the following two ways to authenticate with Azure:
|
||||
Currently, [MIC](../components/#managed-identity-controller) uses one of the following two ways to authenticate with Azure:
|
||||
|
||||
1. [Managed Identity](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) (system-assigned identity or user-assigned identity)
|
||||
2. [Service Principal](https://docs.microsoft.com/en-us/azure/aks/kubernetes-service-principal) through `/etc/kubernetes/azure.json`, which is available in every node, or credentials defined by environment variables;
|
||||
|
|
@ -35,7 +35,7 @@ Currently, [MIC](../../README.md#managed-identity-controller) uses one of the fo
|
|||
|
||||
## More on authentication methods
|
||||
|
||||
[`/etc/kubernetes/azure.json`](https://github.com/kubernetes-sigs/cloud-provider-azure/blob/master/docs/cloud-provider-config.md#auth-configs) is a well-known JSON file in each node that provides the details about which method MIC uses for authentication:
|
||||
[`/etc/kubernetes/azure.json`](https://kubernetes-sigs.github.io/cloud-provider-azure/install/configs/) is a well-known JSON file in each node that provides the details about which method MIC uses for authentication:
|
||||
|
||||
| Authentication method | `/etc/kubernetes/azure.json` fields used |
|
||||
|----------------------------------------|---------------------------------------------------------------------------------------------|
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ description: >
|
|||
|
||||
## Logging
|
||||
|
||||
Below is a list of commands you can use to view relevant logs of aad-pod-identity [components](../../README.md#components).
|
||||
Below is a list of commands you can use to view relevant logs of aad-pod-identity [components](../getting-started/components/).
|
||||
|
||||
### Isolate errors from logs
|
||||
|
||||
|
|
@ -24,7 +24,7 @@ kubectl logs -l component=nmi --since=1h | grep ^E
|
|||
|
||||
### Ensure that iptables rule exists
|
||||
|
||||
To ensure that the correct iptables rule is injected to each node via the [NMI](../../README.md#node-managed-identity) pods, the following command ensures that on a given node, there exists an iptables rule where all packets with a destination IP of 169.254.169.254 (IMDS endpoint) are routed to port 2579 of the host network.
|
||||
To ensure that the correct iptables rule is injected to each node via the [NMI](../getting-started/components/#node-managed-identity) pods, the following command ensures that on a given node, there exists an iptables rule where all packets with a destination IP of 169.254.169.254 (IMDS endpoint) are routed to port 2579 of the host network.
|
||||
|
||||
```bash
|
||||
NMI_POD=$(kubectl get pod -l component=nmi -ojsonpath='{.items[?(@.spec.nodeName=="<NodeName>")].metadata.name}')
|
||||
|
|
@ -105,7 +105,7 @@ Common issues or questions that users have run into when using pod identity are
|
|||
|
||||
### Ignoring azure identity \<podns\>/\<podname\>, error: Invalid resource id: "", must match /subscriptions/\<subid\>/resourcegroups/\<resourcegroup\>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/\<name\>
|
||||
|
||||
If you are using MIC v1.6.0+, you will need to ensure the correct capitalization of `AzureIdentity` and `AzureIdentityBinding` fields. For more information, please refer to [this section](../../README.md#v160-breaking-change).
|
||||
If you are using MIC v1.6.0+, you will need to ensure the correct capitalization of `AzureIdentity` and `AzureIdentityBinding` fields. For more information, please refer to [this section](../#v160-breaking-change).
|
||||
|
||||
### LinkedAuthorizationFailed
|
||||
|
||||
|
|
@ -115,7 +115,7 @@ If you received the following error message in MIC:
|
|||
Code="LinkedAuthorizationFailed" Message="The client '<ClientID>' with object id '<ObjectID>' has permission to perform action 'Microsoft.Compute/<VMType>/write' on scope '<VM/VMSS scope>'; however, it does not have permission to perform action 'Microsoft.ManagedIdentity/userAssignedIdentities/assign/action' on the linked scope(s) '<UserAssignedIdentityScope>' or the linked scope(s) are invalid."
|
||||
```
|
||||
|
||||
It means that your cluster service principal / managed identity does not have the correct role assignment to assign the chosen user-assigned identities to the VM/VMSS. For more information, please follow this [documentation](README.role-assignment.md) to allow your cluster service principal / managed identity to perform identity-related operation.
|
||||
It means that your cluster service principal / managed identity does not have the correct role assignment to assign the chosen user-assigned identities to the VM/VMSS. For more information, please follow this [documentation](../getting-started/role-assignment/) to allow your cluster service principal / managed identity to perform identity-related operation.
|
||||
|
||||
Past issues:
|
||||
|
||||
|
|
|
|||
|
|
@ -7,13 +7,13 @@ menu:
|
|||
weight: 20
|
||||
---
|
||||
|
||||
AAD Pod Identity enables Kubernetes applications to access cloud resources securely with [Azure Active Directory] (AAD).
|
||||
AAD Pod Identity enables Kubernetes applications to access cloud resources securely with [Azure Active Directory](https://azure.microsoft.com/en-us/services/active-directory/).
|
||||
|
||||
Using Kubernetes primitives, administrators configure identities and bindings to match pods. Then without any code modifications, your containerized applications can leverage any resource in the cloud that depends on AAD as an identity provider.
|
||||
|
||||
## v1.6.0 Breaking Change
|
||||
|
||||
With https://github.com/Azure/aad-pod-identity/pull/398, the [client-go](https://github.com/kubernetes/client-go) library is upgraded to v0.17.2, where CRD [fields are now case sensitive](https://github.com/kubernetes/kubernetes/issues/64612). If you are upgrading MIC and NMI from v1.x.x to v1.6.0, MIC v1.6.0+ will upgrade the fields of existing `AzureIdentity` and `AzureIdentityBinding` on startup to the new format to ensure backward compatibility. A configmap called `aad-pod-identity-config` is created to record and confirm the successful type upgrade.
|
||||
With [Azure/aad-pod-identity#398](https://github.com/Azure/aad-pod-identity/pull/398), the [client-go](https://github.com/kubernetes/client-go) library is upgraded to v0.17.2, where CRD [fields are now case sensitive](https://github.com/kubernetes/kubernetes/issues/64612). If you are upgrading MIC and NMI from v1.x.x to v1.6.0, MIC v1.6.0+ will upgrade the fields of existing `AzureIdentity` and `AzureIdentityBinding` on startup to the new format to ensure backward compatibility. A configmap called `aad-pod-identity-config` is created to record and confirm the successful type upgrade.
|
||||
|
||||
However, for future `AzureIdentity` and `AzureIdentityBinding` created using v1.6.0+, the following fields need to be changed:
|
||||
|
||||
|
|
@ -42,5 +42,3 @@ However, for future `AzureIdentity` and `AzureIdentityBinding` created using v1.
|
|||
## Ready to get started?
|
||||
|
||||
To get started, see the [Getting Started](./getting-started/) page, or you can visit the [GitHub repo](https://github.com/Azure/aad-pod-identity).
|
||||
|
||||
|
||||
|
|
|
|||
Загрузка…
Ссылка в новой задаче