validator-plugin-azure

validator-plugin-azure

The Azure validator plugin ensures that your Azure environment matches a user-configurable expected state.

Description

The Azure validator plugin reconciles AzureValidator custom resources to perform the following validations against your Azure environment:

1. Compare the Azure RBAC permissions associated with a security principal against an expected permission set.
2. Verify that images in community image galleries exist.

Each AzureValidator CR is (re)-processed every two minutes to continuously ensure that your Azure environment matches the expected state.

See the samples directory for example AzureValidator configurations. Some samples require you to add data to the rules configured in them such as the Azure subscription to use.

Rules

RBAC rule

This rule compares the Azure RBAC permissions associated with a security principal against an expected permission set.

It checks if an Azure security principal (e.g., users, service principals) has the required Azure RBAC permissions. In Azure RBAC, permissions are applied to principals by a role assignment being created that links a role (which can be a BuiltInRole or a CustomRole) to the principal at a particular scope. API operations at that scope or lower (e.g. operations against a subscription or against a resource group within the subscription) are permitted but operations outside of that scope are not.

Validation is successful if the principal has the necessary permissions, either from one role assignment or a combination of role assignments.

The list of permissions defined in the spec cannot have an action or data action with a wildcard. However, the roles that provide the permissions (via role assignments) may have wildcards in their actions and data actions.

Note that you must use the correct ID when configuring the principalId in the spec for the principal. For a service principal, this is the "application object ID" found in the Azure portal under Entra ID > application registration > managed application page > "object ID". Note that this is different from the tenant ID, client ID, and object ID of the application registration.

Service principal example:

See azurevalidator-rbac-one-permission-set-all-actions-permitted-by-one-role.yaml for an example rule spec.

Community image gallery rule

This rule verifies that images in community image galleries exist.

See azurevalidator-communitygalleryimages-one-image.yaml for an example rule spec.

Authn & Authz

Authentication details for the Azure validator controller are provided within each AzureValidator custom resource. Azure authentication can be configured either implicitly or explicitly:

• Implicit (AzureValidator.auth.implicit == true)
  • Workload identity
    • In this scenario, a valid ServiceAccount must be specified during plugin installation. See values.yaml for details.
• Explicit (AzureValidator.auth.implicit == false && AzureValidator.auth.secretName != "")
  • Environment variables

[!NOTE] See values.yaml for additional configuration details for each authentication option.

Minimal Azure RBAC permissions by validation type

For validation to succeed, certain Azure RBAC permissions must be assigned to the principal used via role assignments. The minimal required operations that must be listed under Actions in the role assignments, by rule, are as follows.

RBAC rule

Create a custom role with the following permissions:

Microsoft.Authorization/denyAssignments/read
Microsoft.Authorization/roleAssignments/read
Microsoft.Authorization/roleDefinitions/read

Alternatively, you can use the built-in Managed Identity Operator role, which includes these permissions.

Community gallery image rule

Create a custom role with the permission Microsoft.Compute/locations/communityGalleries/images/read.

If you prefer to use a built-in role, the Virtual Machine Contributor role includes the necessary permissions to read community gallery images. However, be aware that this role also grants permissions to modify and delete virtual machines and other compute resources. If you only need read-only access, consider creating a custom role as described above.

Connecting to Azure Government or Azure in China

By default, the plugin connects the Azure SDK to the public Azure cloud. Override azureEnvironment to change which cloud is connected to, using the following values.

Installation

The Azure validator plugin is meant to be installed by validator (via a ValidatorConfig), but it can also be installed directly as follows:

helm repo add validator-plugin-azure https://validator-labs.github.io/validator-plugin-azure
helm repo update
helm install validator-plugin-azure validator-plugin-azure/validator-plugin-azure -n validator-plugin-azure --create-namespace

Development

You’ll need a Kubernetes cluster to run against. You can use kind to get a local cluster for testing, or run against a remote cluster.

Note: Your controller will automatically use the current context in your kubeconfig file (i.e. whatever cluster kubectl cluster-info shows).

Running on the cluster

1. Install Instances of Custom Resources:

kubectl apply -f config/samples/

1. Build and push your image to the location specified by IMG:

make docker-build docker-push IMG=<some-registry>/validator-plugin-azure:tag

1. Deploy the controller to the cluster with the image specified by IMG:

make deploy IMG=<some-registry>/validator-plugin-azure:tag

Uninstall CRDs

To delete the CRDs from the cluster:

make uninstall

Undeploy controller

UnDeploy the controller from the cluster:

make undeploy

How it works

This project aims to follow the Kubernetes Operator pattern.

It uses Controllers, which provide a reconcile function responsible for synchronizing resources until the desired state is reached on the cluster.

Test It Out

1. Install the CRDs into the cluster:

make install

1. Run your controller (this will run in the foreground, so switch to a new terminal if you want to leave it running):

make run

NOTE: You can also run this in one step by running: make install run

Modifying the API definitions

If you are editing the API definitions, generate the manifests such as CRs or CRDs using:

make manifests

Contributing

All contributions are welcome! Feel free to reach out on the Spectro Cloud community Slack.

Make sure pre-commit is installed.

Install the pre-commit scripts:

pre-commit install --hook-type commit-msg
pre-commit install --hook-type pre-commit

NOTE: Run make --help for more information on all potential make targets

More information can be found via the Kubebuilder Documentation

License

Copyright 2024.

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.