You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- Only the AZ modules 'Az.Accounts' and 'Az.Resources' are required.
54
+
- Only the AZ modules 'Az.Accounts' and 'Az.Resources' are required.
58
55
59
56
### Install the module
60
57
@@ -76,29 +73,29 @@ To install the **GuestConfiguration** module in PowerShell:
76
73
77
74
## Background information regarding Guest Configuration artifacts and policy for Linux
78
75
79
-
Even in Linux environments, Guest Configuration utilizes Desired State Configuration as a language abstraction.
80
-
The implementation is based in native code (C++) so it does not require loading PowerShell at this time.
81
-
However, it does require a configuration MOF file describing basic details about the environment. DSC is acting as a "wrapper" for InSpec to standardize how it is executed, how parameters are provided from Azure Resource Manager, and how output is captured and returned to the service.
82
-
Little knowledge of DSC is required
83
-
when working with custom InSpec content.
76
+
Even in Linux environments, Guest Configuration utilizes Desired State Configuration as a language
77
+
abstraction. The implementation is based in native code (C++) so it does not require loading
78
+
PowerShell at this time. However, it does require a configuration MOF file describing basic details
79
+
about the environment. DSC is acting as a "wrapper" for InSpec to standardize how it is executed,
80
+
how parameters are provided from Azure Resource Manager, and how output is captured and returned to
81
+
the service. Little knowledge of DSC is required when working with custom InSpec content.
84
82
85
83
#### Configuration requirements
86
84
87
-
The only requirement for Guest Configuration to use a custom configuration file is for the name of the
88
-
configuration to be consistent everywhere it's used. This name requirement includes the name of the
89
-
.zip file for the content package, the configuration name in the MOF file stored inside the content
90
-
package, and the configuration name used in a Resource Manager template as the guest assignment
91
-
name.
85
+
The only requirement for Guest Configuration to use a custom configuration file is for the name of
86
+
the configuration to be consistent everywhere it's used. This name requirement includes the name of
87
+
the .zip file for the content package, the configuration name in the MOF file stored inside the
88
+
content package, and the configuration name used in a Resource Manager template as the guest
89
+
assignment name.
92
90
93
91
### Custom Guest Configuration configuration on Linux
94
92
95
-
Guest Configuration on Linux uses the `ChefInSpecResource` resource to
96
-
provide the engine with the name of the [InSpec profile](https://www.inspec.io/docs/reference/profiles/). **Name**
97
-
is the only required resource property. Create a YaML file and a Ruby script file, as detailed below.
93
+
Guest Configuration on Linux uses the `ChefInSpecResource` resource to provide the engine with the
94
+
name of the [InSpec profile](https://www.inspec.io/docs/reference/profiles/). **Name** is the only
95
+
required resource property. Create a YaML file and a Ruby script file, as detailed below.
98
96
99
-
First, create the YaML file used by InSpec.
100
-
The file provides basic information about the environment.
101
-
An example is given below:
97
+
First, create the YaML file used by InSpec. The file provides basic information about the
98
+
environment. An example is given below:
102
99
103
100
```YaML
104
101
name: linux-path
@@ -123,8 +120,8 @@ end
123
120
124
121
Save this file in a new folder named `controls` inside the `linux-path` directory.
125
122
126
-
Finally, create a configuration, import the **GuestConfiguration**
127
-
resource module, and use the `ChefInSpecResource` resource to set the name of the InSpec profile.
123
+
Finally, create a configuration, import the **GuestConfiguration** resource module, and use the
124
+
`ChefInSpecResource`resource to set the name of the InSpec profile.
128
125
129
126
```powershell
130
127
# Define the configuration and import GuestConfiguration
The `Node AuditFilePathExists` command is not technically required but it produces a file named `AuditFilePathExists.mof` rather than the default, `localhost.mof`. Having the .mof file name follow the configuration makes it easy to organize many files when operating at scale.
145
+
The `Node AuditFilePathExists` command is not technically required but it produces a file named
146
+
`AuditFilePathExists.mof`rather than the default, `localhost.mof`. Having the .mof file name follow
147
+
the configuration makes it easy to organize many files when operating at scale.
149
148
150
149
You should now have a project structure as below:
151
150
@@ -159,10 +158,11 @@ You should now have a project structure as below:
159
158
linux-path.rb
160
159
```
161
160
162
-
The supporting files must be packaged together. The completed package is
163
-
used by Guest Configuration to create the Azure Policy definitions.
161
+
The supporting files must be packaged together. The completed package is used by Guest Configuration
162
+
to create the Azure Policy definitions.
164
163
165
-
The `New-GuestConfigurationPackage` cmdlet creates the package. Parameters of the `New-GuestConfigurationPackage` cmdlet when creating Linux content:
164
+
The `New-GuestConfigurationPackage` cmdlet creates the package. Parameters of the
165
+
`New-GuestConfigurationPackage` cmdlet when creating Linux content:
166
166
167
167
- **Name**: Guest Configuration package name.
168
168
- **Configuration**: Compiled configuration document full path.
@@ -186,7 +186,8 @@ module includes a cmdlet `Test-GuestConfigurationPackage` that loads the same ag
186
186
development environment as is used inside Azure machines. Using this solution, you can perform
187
187
integration testing locally before releasing to billed cloud environments.
188
188
189
-
Since the agent is actually evaluating the local environment, in most cases you need to run the Test- cmdlet on the same OS platform as you plan to audit.
189
+
Since the agent is actually evaluating the local environment, in most cases you need to run the
190
+
Test- cmdlet on the same OS platform as you plan to audit.
190
191
191
192
Parameters of the `Test-GuestConfigurationPackage` cmdlet:
192
193
@@ -208,7 +209,9 @@ The cmdlet also supports input from the PowerShell pipeline. Pipe the output of
The next step is to publish the file to blob storage. The script below contains a function you can use to automate this task. The commands used in the `publish` function require the `Az.Storage` module.
212
+
The next step is to publish the file to blob storage. The script below contains a function you can
213
+
use to automate this task. The commands used in the `publish` function require the `Az.Storage`
214
+
module.
212
215
213
216
```azurepowershell-interactive
214
217
function publish {
@@ -339,12 +342,14 @@ means that the values in the MOF file in the package don't have to be considered
339
342
override values are provided through Azure Policy and don't impact how the Configurations are
340
343
authored or compiled.
341
344
342
-
With InSpec, parameters are typically handled as input either at runtime or as code using attributes.
343
-
Guest Configuration obfuscates this process so input can be provided to Azure Resource Manager when policy is assigned.
344
-
An attributes file is automatically created within the machine. You do not need to create and add a file in your project.
345
-
There are two steps to adding parameters to your Linux audit project.
345
+
With InSpec, parameters are typically handled as input either at runtime or as code using
346
+
attributes. Guest Configuration obfuscates this process so input can be provided to Azure Resource
347
+
Manager when policy is assigned. An attributes file is automatically created within the machine. You
348
+
do not need to create and add a file in your project. There are two steps to adding parameters to
349
+
your Linux audit project.
346
350
347
-
Define the input in the Ruby file where you script what to audit on the machine. An example is given below.
351
+
Define the input in the Ruby file where you script what to audit on the machine. An example is given
352
+
below.
348
353
349
354
```Ruby
350
355
attr_path = attribute('path', description:'The file path to validate.')
@@ -359,7 +364,8 @@ parameter named **Parameters**. This parameter takes a hashtable definition incl
359
364
about each parameter and automatically creates all the required sections of the files used to create
360
365
each Azure Policy definition.
361
366
362
-
The following example creates an Azure Policy to audit a file path, where the user provides the path at the time of Policy assignment.
367
+
The following example creates an Azure Policy to audit a file path, where the user provides the path
0 commit comments