da Agency

Seamless cost reporting and analysis for Enterprise customers: now in preview

I’m thrilled to announce the preview release of Enterprise Cost Management within the Azure portal. With today’s release, Azure Enterprise Agreement (EA) users can view and analyze their subscription costs across different pivots, within the Azure portal. This addresses a top ask from our EA customers to empower subscription admins with visibility into their costs. We’ve also heard you on the need for more granular cost reporting by resource group and tag.

This is an initial step in our commitment to providing best-in-class cost management experiences within the Azure portal. Over the next few months, you will continue to see us roll out new capabilities to help you better manage your Azure costs and services.

In the remainder of this post, I walk you through some of the new features we’ve made available.

Try it today

All you have to do is sign in to the Azure portal at https://portal.azure.com. Go to Browse -> Subscriptions and click on your subscription. You’ll see the below charts in the Overview blade.

 

The pie chart on the left gives you a quick idea of the top resources contributing to your costs. The burn rate chart on the right tells you your month-to-date costs and provides a forecast, enabling you to take corrective action early.

Click into the pie chart or on Cost analysis in the Resource menu. This launches the Costs by resource report that gives you a breakdown of your costs by resource. Here you can filter costs by Resource Group, Tag, or Resource Type. If you spot excessive spend, you can right-click to navigate to a resource and view its activity logs or take corrective action. You can also download the results into a CSV file for offline analysis.

Further, left-clicking into any resource will launch the Cost history report. This enables you to spot trends and spikes in costs. You can get cost history for a resource group or resource, and group the results so you can easily identify what’s contributing to costs.

Note: in order to access these subscription-level costs in the Azure portal, the user needs to be a Billing Reader, Reader, Contributor, or Owner at the Subscription level.

To learn more about these capabilities, visit our help documentation here.

As mentioned above, this preview is just an early step in our efforts to build rich cost management experiences in the Azure portal, for Enterprise customers. Over the next few months, you will continue to see us roll out new capabilities to help you better manage your Azure costs and services. As always, we’d love to hear from you. Send us your feedback here.
Quelle: Azure

da Agency

Meet Compute Engine’s new managed instance group updater

By Pawel Siarkiewicz, Product Manager

A key feature of Google Compute Engine is managed instance groups, which allows you to manage collections of identical instances as a unit, to quickly deploy new VMs and ensure they’re consistently configured. Today, we’re pleased to announce a new managed instance group updater, to help you update your Compute Engine VMs programmatically and at scale. The updater is in beta and fully integrated into managed instance groups, making it easier than ever to update the software on your instances, patch and update them, and roll out staged and test deployments.

Specifically, the new managed instance group updater allows you to:

Programmatically update your instances from one instance template to another 
Specify how many instances to update at a time: one, several or all 
Deploy additional instances (temporarily) to maintain capacity while old instances are being replaced 
Restart, or recreate, all instances in the managed instance group without changing the template 
Control the rate of deployment by configuring a pause between instance updates 

At first glance, all these options can be a bit overwhelming. Instead of explaining them one by one, let’s explore three typical use cases:

Deploying a simple update 
Deploying a canary test update 
Recreating all instances 

We’ll show you how to use the managed instance group updater from the UI and gcloud command line, but you can also use it through the API.

Simple update 
Let’s start with the basics and deploy an update to the entire managed instance group, one instance at a time. The instance group my-instance-group starts with every instance running the template myapp-version-a, and we want to deploy myapp-version-b because we’re deploying a new version of our software (we could also be doing so to patch/update the underlying OS).

gcloud beta compute instance-groups managed rolling-action
start-update my-instance-group –version template=myapp-version-b

The managed instance group deploys myapp-version-b by first deleting an instance with myapp-version-a, while simultaneously creating an instance with myapp-version-b, waiting for that new instance to be healthy and then proceeding to the next instance until all of the instances are updated. If you want to roll back the update, just run the same command, but this time specify myapp-version-a as the target template.

gcloud beta compute instance-groups managed rolling-action
start-update my-instance-group –version template=myapp-version-a
This is the default behavior for the updater, and it works really well for many typical deployments. If your managed instance group is large, however, updating one instance at a time might take too long. Let’s try this again, but this time, let’s update a quarter of the instances at a time.

gcloud beta compute instance-groups managed rolling-action
start-update my-instance-group –version template=myapp-version-b
–max-unavailable 25%

Note the new parameter, max-unavailable. It tells the updater how many instances can be taken offline at the same time, to be updated to the new template. Whether you have tens, hundreds or thousands of instances, the update proceeds at the rate you specify. If you’re wondering whether you can update all instances at the same time, the answer is yes. Just set max-unavailable to 100% and the managed instance group updates everything at once. This is a great option when consistent uptime doesn’t matter, for example in a testing environment or for batch computations.

Canary testing 

Now it’s time to consider a more advanced use case. Deploying new software to a subset of instances before committing fully is known as canary testing and is a best practice for managing robust, highly available systems. It allows you to test new software in a real environment while minimizing the impact of any issues.

For our example, let’s deploy myapp-version-b to just one instance.

gcloud beta compute instance-groups managed rolling-action
start-update my-instance-group –version template=myapp-version-a
–canary-version template=myapp-version-b,target-size=1

Here, the managed instance group deletes one instance of myapp-version-a and creates one instance of myapp-version-b. The update does not proceed further. If the instance group needs to scale up or down, it retains that one instance of myapp-version-b so that you can test it and make sure that it works as intended. When you’re ready, you can deploy it to a larger group, for example one half of the instances.

gcloud beta compute instance-groups managed rolling-action
start-update my-instance-group –version template=myapp-version-a
–canary-version template=myapp-version-b,target-size=50%

The managed instance group replaces instances running myapp-version-a with instances running myapp-version-b until the balance is 50/50. If autoscaling adds or removes instances, the managed instance group maintains this ratio, keeping the canary deployment at the level you set.

When you’re ready to commit to your new deployment, simply tell the updater that you want all of your instances to be running myapp-version-b. This is identical to what we previously did in the simple update.

gcloud beta compute instance-groups managed rolling-action
start-update my-instance-group –version template=myapp-version-b

Recreating all instances 
Sometimes you don’t want to apply a new template, you just want to replace all of your instances, but keep the current template. This is a common pattern if you’re using image families and want to make sure that your instances are using the latest version of an image. Starting a rolling replace of all instances follows the same pattern as starting an update.

gcloud beta compute instance-groups managed rolling-action replace
my-instance-group –max-unavailable=10%

Notice that the replace action uses the same controls as max-unavailable that our earlier simple update example used to control how many instances to take offline at the same time.

Next steps 

We think these are the most common use cases for the managed instance groups updater, but realistically, we’ve just scratched the surface of everything that’s possible with it. Thanks to flexible controls like max-unavailable and max-surge, support for canary updates and different actuation commands such as start-update, restart and recreate, you now have a lot of options for maintaining your managed instance groups fleet. For more information, please see the documentation, and feel free to reach out to us with questions and feedback in the GCE discussion group.

You can try out the new managed instance group updater today in the console. If you’re new to Google Cloud Platform (GCP) you can also sign up to automatically get $300 worth of GCP credit to try out Compute Engine and the managed instance group updater.
Quelle: Google Cloud Platform

da Agency

Writing a SELinux policy from the ground up

SELinux is a mechanism that implements mandatory access controls in Linux systems.
This article shows how to create a SELinux policy that confines a standard service:

Limit its network interfaces,
Restrict its system access, and
Protect its secrets.

Mandatory access control

By default, unconfined processes use discretionary access controls (DAC).
A user has all the permissions over its objects, for example the
owner of a log file can modify it or make it world readable.

In contrast, mandatory access control (MAC) enables more fine grained controls,
for example it can restrict the owner of a log file to only append operations.
Moreover, MAC can also be used to reduce the capability of a regular
process, for example by denying debugging or networking capabilities.

This is great for system security, but is also a powerful tool
to control and better understand an application.
Security policies reduce services’ attack surface and describes
service system operations in depth.

Policy module files

A SELinux policy is composed of:

A type enforcement file (.te): describes the policy type and access control,
An interface file (.if): defines functions available to other policies,
A file context file (.fc): describes the path labels, and
A package spec file (.spec): describes how to build and install the policy.

The packaging is optional but highly recommended since it’s a standard
method to distribute and install new pieces on a system.

Under the hood, these files are written using macros processors:

A policy file (.pp) is generated using: make NAME=targeted -f “/usr/share/selinux/devel/Makefile”
An intermediary file (.cil) is generated using: /usr/libexec/selinux/hll/pp

Policy developpment workflow:

The first step is to get the services running in a confined domain.
Then we define new labels to better protect the service.
Finally the service is run in permissive mode to collect the access it needs.

As an example, we are going to create a security policy for the scheduler
service of the Zuul program.

Confining a Service

To get the basic policy definitions, we use the
sepolicy generate
command to generate a bootstrap zuul-scheduler policy:

sepolicy generate –init /opt/rh/rh-python35/root/bin/zuul-scheduler

The –init argument tells the command to generate a service policy. Other
types of policy could be generated such as user application, inetd daemon
or confined administrator.

The .te file contains:

A new zuul_scheduler_t domain,
A new zuul_scheduler_exec_t file label,
A domain transition from systemd to zuul_scheduler_t when the zuul_scheduler_exec_t is executed, and
Miscellaneous definitions such as the ability to read localization settings.

The .fc file contains regular expressions to match a file path with a label:
/bin/zuul-scheduler is associated with zuul_scheduler_exec_t.

The .if file contains methods (macros) that enable role extension. For example,
we could use the zuul_scheduler_admin method to authorize a staff role to administrate
the zuul service. We won’t use this file because the admin user (root) is unconfined
by default and it doesn’t need special permission to administrate the service.

To install the zuul-scheduler policy we can run the provided script:
$ sudo ./zuul_scheduler.sh
Building and Loading Policy
+ make -f /usr/share/selinux/devel/Makefile zuul_scheduler.pp
Creating targeted zuul_scheduler.pp policy package
+ /usr/sbin/semodule -i zuul_scheduler.pp
Restarting the service should show (using “ps Zax”) that it is now
running with the system_u:system_r:zuul_scheduler_t:s0 context instead of
the system_u:system_r:unconfined_service_t:s0.

And looking at the audit.log, it should show many “avc: denied error” because no
permissions have yet been defined. Note that the service is running fine because
this initial policy defines the zuul_scheduler_t domain as permissive.

Before authorizing the service’s access, let’s define the zuul resources.

Define the service resources

The service is trying to access /etc/opt/rh/rh-python35/zuul and
/var/opt/rh/rh-python35/lib/zuul which inherited the etc_t and var_lib_t labels.
Instead of giving zuul_scheduler_t access to etc_t and var_lib_t,
we will create new types. Moreover the zuul-scheduler manages secret keys
we could isolate from its general home directory and it requires two tcp ports.

In the .fc file, define the new paths:
/var/opt/rh/rh-python35/lib/zuul/keys(/.*)? gen_context(system_u:object_r:zuul_keys_t,s0)
/etc/opt/rh/rh-python35/zuul(/.*)? gen_context(system_u:object_r:zuul_conf_t,s0)
/var/opt/rh/rh-python35/lib/zuul(/.*)? gen_context(system_u:object_r:zuul_var_lib_t,s0)
/var/opt/rh/rh-python35/log/zuul(/.*)? gen_context(system_u:object_r:zuul_log_t,s0)

In the .te file, declare the new types:
# System files
type zuul_conf_t;
files_type(zuul_conf_t)
type zuul_var_lib_t;
files_type(zuul_var_lib_t)
type zuul_log_t;
logging_log_file(zuul_log_t)

# Secret files
type zuul_keys_t;
files_type(zuul_keys_t)

# Network label
type zuul_gearman_port_t;
corenet_port(zuul_gearman_port_t)
type zuul_webapp_port_t;
corenet_port(zuul_webapp_port_t);

Note that the file_type() macro is important since it provides unconfined access to
the new types. Without it, even the admin user could not access the file.

In the .spec file, add the new path and setup the tcp port labels:
%define relabel_files()
restorecon -R /var/opt/rh/rh-python35/lib/zuul/keys
…

# In the %post section, add
semanage port -a -t zuul_gearman_port_t -p tcp 4730
semanage port -a -t zuul_webapp_port_t -p tcp 8001

# In the %postun section, add
for port in 4730 8001; do semanage port -d -p tcp $port; done

Rebuild and install the package:
sudo ./zuul_scheduler.sh && sudo rpm -ivh ./noarch/*.rpm

Check that the new types are installed using “ls -Z” and “semanage port -l”:
$ ls -Zd /var/opt/rh/rh-python35/lib/zuul/keys/
drwx——. zuul zuul system_u:object_r:zuul_keys_t:s0 /var/opt/rh/rh-python35/lib/zuul/keys/
$ sudo semanage port -l | grep zuul
zuul_gearman_port_t tcp 4730
zuul_webapp_port_t tcp 8001

Update the policy

With the service resources now declared, let’s restart the service and start
using it to collect all the access it needs.

After a while, we can update the policy using “./zuul_scheduler.sh –update”
which basically does: “ausearch -m avc –raw | audit2allow -R”.
This collects all the permissions denied to generates type enforcement rules.

We can repeat this steps until all the required accesses are collected.

Here’s what looks like the resulting zuul-scheduler rules:

allow zuul_scheduler_t gerrit_port_t:tcp_socket name_connect;
allow zuul_scheduler_t mysqld_port_t:tcp_socket name_connect;
allow zuul_scheduler_t net_conf_t:file { getattr open read };
allow zuul_scheduler_t proc_t:file { getattr open read };
allow zuul_scheduler_t random_device_t:chr_file { open read };
allow zuul_scheduler_t zookeeper_client_port_t:tcp_socket name_connect;
allow zuul_scheduler_t zuul_conf_t:dir getattr;
allow zuul_scheduler_t zuul_conf_t:file { getattr open read };
allow zuul_scheduler_t zuul_exec_t:file getattr;
allow zuul_scheduler_t zuul_gearman_port_t:tcp_socket { name_bind name_connect };
allow zuul_scheduler_t zuul_keys_t:dir getattr;
allow zuul_scheduler_t zuul_keys_t:file { create getattr open read write };
allow zuul_scheduler_t zuul_log_t:file { append open };
allow zuul_scheduler_t zuul_var_lib_t:dir { add_name create remove_name write };
allow zuul_scheduler_t zuul_var_lib_t:file { create getattr open rename write };
allow zuul_scheduler_t zuul_webapp_port_t:tcp_socket name_bind;

Once the service is no longer being denied permissions, we can remove the
“permissive zuul_scheduler_t;” declaration and deploy it in production. To avoid
issues, the domain can be set to permissive at first using:

$ sudo semanage permissive -a zuul_scheduler_t

Too long, didn’t read

In short, to confine a service:

Use sepolicy generate
Declare the service’s resources
Install the policy and restart the service
Use audit2allow

Here are some useful documents:

The reference policy
Object Classes and Permissions
Dan Walsh’s Blog
Writing SELinux Policy presentation by Miroslav Grepl

Quelle: RDO

da Agency

Azure IoT Hub Device Provisioning Service preview automates device connection and configuration!

Today we're announcing the public preview of the Azure IoT Hub Device Provisioning Service! The Device Provisioning Service is new service that works with Azure IoT Hub to enable customers to configure zero-touch device provisioning to their IoT hub. With the Device Provisioning Service, you can provision millions of devices in a secure and scalable manner, automating a process that has historically been time and resource intensive for manufacturers and companies managing volumes of connected devices. The Device Provisioning Service is the only cloud service to provide complete automated provisioning, including both registering the device to the cloud as well as configuring the device. Device Provisioning Service is available in East US, West Europe, and Southeast Asia starting today, and eventually will be available globally.

Without a provisioning service, connecting devices to Azure IoT Hub requires manual work. Each device needs a unique identity to enable per-device access revocation in case the device is compromised. Doing this manually works for very few devices, but at IoT scale, you have to individually place connection credentials on each of millions of devices.

A naïve way to go about solving the connection problem is to hardcode IoT Hub connection information in the device at manufacture time, but this only works in some scenarios. In many cases, complete provisioning requires information that was not available when the device was manufactured, such as who purchased the device or what the device is to be used for.

Even once the device is connected it still needs to be configured with its desired twin state and software and/or firmware updates. This is yet more work to account for when planning device deployments.

This is where the Device Provisioning Service saves customers a lot of time, helping get devices configured automatically during registration to IoT Hub. Device Provisioning Service contains all the information needed to provision a device, and the information can easily be updated later in the supply chain without having to unbox and re-flash the device.

Here are some of the provisioning scenarios the Device Provisioning Service enables:

Zero-touch provisioning to a single IoT solution without requiring hardcoded IoT Hub connection information in the factory (initial setup).
Automatically configuring devices based on solution-specific needs.
Load balancing devices across multiple hubs.
Connecting devices to their owner’s IoT solution based on sales transaction data (multitenancy).
Connecting devices to a particular IoT solution depending on use-case (solution isolation).
Connecting a device to the IoT hub with the nearest geo-location.
Re-provisioning based on a change in the device such as a change in ownership or location.

All these scenarios are achievable today through the Device Provisioning Service using the same basic flow:

 

Device Provisioning Service works best with devices using Hardware Security Modules (HSMs) to securely store their keys. HSMs provide the maximum amount of security for key storage, and the updated device SDK makes it incredibly easy to establish a root of trust between the device and the cloud using an HSM. Microsoft has partnerships with several HSM manufacturers, and you can read about the partnerships and HSM options we have on the Azure blog. Even if your device is incapable of using an HSM, it can still connect to Device Provisioning Service. You can learn about how to use a simulated TPM or a software-based x509 certificate here.

Learn more about all the technical concepts involved in device provisioning.

Azure IoT is committed to offering you services which take the pain out of deploying and managing an IoT solution in a secure, reliable way. You can create your own Device Provisioning Service on the Azure portal, and you can check out the device SDK on GitHub. Learn all about the Device Provisioning Service and how to use it in the documentation center. We would love to get your feedback on secure device registration (that's the point of the preview!), so please continue to submit your suggestions through the Azure IoT User Voice forum.
Quelle: Azure