Azure has given all the possibility to integrate with the custom applications with an identity provider ( Azure AD ).
we dont need to develop a custom identity manager/provider for each and every application that we develop.
Application security : Registrations permissions ( several choices) , scopes ( formely known as permissions) and consent ( allowing apps to work for you ).
(users can use their existing Azure AD credentials to access these applications. No more secondary logins for LOB applications ).
Scopes : a set of permissions that can be used to divide the functionality of that resource into smaller chunks.
user and application permissions are used with scopes to maintain fine grain control over resource data as well as safeguard API exposure.
How to register an application ?
First step : Click on Azure AD Blade
Second Step: App registrations > New registration > created.
scopes are permissions used to define what actions an application can perform on behalf of the user against a resource.
we use the term in other ways. specifically, permissions define what a user or an app can directly access in Azure.
User and app permissions are defined via roles. These roles use role based access control, or RBAC to determine privileges to resources.
A user may have privileges to write to the global directory, but the defined scope of permissions for an application may only require read permissions. So what happens ? The user is only allowed read permissions when using the application. This is due to the concept of effective permissions.
For delegated permissions, the effective permissions of your app will be the least privileged b/w the delegated permissions granted to the app (via consent) and the privileges of the currently signed-in user.
what is consent ?
In order for an application to perform a task on your behalf, you have to agree to let it do so.
Consent occurs at sign-in
There are many kinds of consents
1) Individual user consent
2) administrator consent
For application permissions, the effective permissions of your app will be the full level of privileges granted to the app. These are used by apps that run without a signed-in user.
Monday, April 27, 2020
What is Identity Provider IdP and with some examples ?
Microsoft AAD - is the first preference.
How it is acting ?
Multi-cloud usage
Simple workflow to revise
How to add an Identity source ?
what is SSO in one single flow ?
Idp and Sp
Sunday, April 26, 2020
security is primary aspect for azure resources and its individual components
Going through the Azure Security Technologies.
User identities ( How ? )
Using Technologies such as MFA and conditional access.
Azure AD PIM ( Privileged Identity Management ) : Restricted evaluated privileges as needed bases.
Azure Monitor (formerly in some ways known as the Log Analytics as well as the vulnerability scanning)
Azure Information Protection : This is a data securing tool ( I can say this in short and easy to remember). Encryption of storages and databases and Azure KeyVault.
Active Directory User management:
Azure AD or Azure Active Directory is the Microsoft cloud based identity and access management service.
As a App developer Azure AD gives you a standard base approach for Adding Single Sign on to your app allowing it to work with your pre-existing credentials.
User Account can be any one of the following types:
A cloud-based user account (Azure Active Directory) otherwise knows as the cloud account.
A synchronized on-prem directory account ( AD ---> AAD ) via Azure AD Connect.
A guest user, also known as a B2B collaboration guest.
We can also gives this User an elevated directory role.
what is directory role ?
some of the example of directory role,
1) User
2) Global administrator
3) Limited administrator.
User can be assigned to any directory role based on the organization level decision.
Azure Active Directory (AD) groups:
Groups examining group and membership types.
There are two types of groups,
1. Security groups ( This way you can give a set of permission to all members at once instead of having to individually add permissions to each member ).
2. Office365 ( provide collaboration by giving members access to a shared mailbox, calendar, sharepoint site, files and more.
When we create a group, we have further options which we can configure.
Specifically, it is membership type, there are three types of the membership types:
1. Assigned
2. Dynamic User
3. Dynamic Device ( security groups only ).
Assigned membership types are static in nature,. The administrator determines group membership. To add or remove members from the group.
with the dynamic membership type,
we can determine group membership by the attribute values or a set of attribute values that exist on a user or a device. We can inbuilt build the queries inside the active directory groups. that determines who will become the member of that group.
if a user or device matches that query, its added to that group. if the attribute changes or removed then the account is removed from the group.
we have to add the query and show that how our membership is built.
we can write/frame using two kinds of the ruler editors,
1. Simple rule
2. advanced rule
Basic points,
1. when using dynamic user or dynamic device membership types, you can only use one at a time.
2. when creating a dynamic device membership type, attributes for the specific devices are examined to determine membership, not the attributes for the devices owner.
what is nested group ?
add a security group to another security group.
there are few limitations for the nested groups.
if you have an existing group with the Assigned membership type
can be converted to the dynamic user membership type.
for example :
you have a group named kaushik
when you click on properties,
group name : kaushik
group type : security group
membership type : Assigned
How to create a group ?
New-AzADGroup -DisplayName "kaushik" -MailNickname "kaushik"
az ad group create --display-name "kaushik" --mail-nickname "kaushik"
we can create group in many ways.
User identities ( How ? )
Using Technologies such as MFA and conditional access.
Azure AD PIM ( Privileged Identity Management ) : Restricted evaluated privileges as needed bases.
Azure Monitor (formerly in some ways known as the Log Analytics as well as the vulnerability scanning)
Azure Information Protection : This is a data securing tool ( I can say this in short and easy to remember). Encryption of storages and databases and Azure KeyVault.
Configuring Active Directory:
1. AD Users
2. AAD Connect
3. AD Groups
4. Application Security (Registration, Permissions, Scopes and Consent).
5. Authentication (Password sync, pass-through authentication)
6. Azure MFA
7. Conditional Access
8. Azure Active Directory Identity Protection.
Azure AD PIM
1. Overall and Activation
2. Configuration, Access requests and approval (security wizard, role settings and more).
3. Reviewing access (auditing and access reviews).
Active Directory User management:
Azure AD or Azure Active Directory is the Microsoft cloud based identity and access management service.
As a App developer Azure AD gives you a standard base approach for Adding Single Sign on to your app allowing it to work with your pre-existing credentials.
User Account can be any one of the following types:
A cloud-based user account (Azure Active Directory) otherwise knows as the cloud account.
A synchronized on-prem directory account ( AD ---> AAD ) via Azure AD Connect.
A guest user, also known as a B2B collaboration guest.
We can also gives this User an elevated directory role.
what is directory role ?
some of the example of directory role,
1) User
2) Global administrator
3) Limited administrator.
User can be assigned to any directory role based on the organization level decision.
Azure Active Directory (AD) groups:
Groups examining group and membership types.
There are two types of groups,
1. Security groups ( This way you can give a set of permission to all members at once instead of having to individually add permissions to each member ).
2. Office365 ( provide collaboration by giving members access to a shared mailbox, calendar, sharepoint site, files and more.
When we create a group, we have further options which we can configure.
Specifically, it is membership type, there are three types of the membership types:
1. Assigned
2. Dynamic User
3. Dynamic Device ( security groups only ).
Assigned membership types are static in nature,. The administrator determines group membership. To add or remove members from the group.
with the dynamic membership type,
we can determine group membership by the attribute values or a set of attribute values that exist on a user or a device. We can inbuilt build the queries inside the active directory groups. that determines who will become the member of that group.
if a user or device matches that query, its added to that group. if the attribute changes or removed then the account is removed from the group.
we have to add the query and show that how our membership is built.
we can write/frame using two kinds of the ruler editors,
1. Simple rule
2. advanced rule
Basic points,
1. when using dynamic user or dynamic device membership types, you can only use one at a time.
2. when creating a dynamic device membership type, attributes for the specific devices are examined to determine membership, not the attributes for the devices owner.
what is nested group ?
add a security group to another security group.
there are few limitations for the nested groups.
if you have an existing group with the Assigned membership type
can be converted to the dynamic user membership type.
for example :
you have a group named kaushik
when you click on properties,
group name : kaushik
group type : security group
membership type : Assigned
How to create a group ?
New-AzADGroup -DisplayName "kaushik" -MailNickname "kaushik"
az ad group create --display-name "kaushik" --mail-nickname "kaushik"
we can create group in many ways.
Saturday, April 18, 2020
How Azure Webapp can retrieve secrets from an Azure Keyvault ?
1. Go to your Webapp
2. Select the option Identity
3. There are two kinds of Identity : 1) System assign and 2) User assign
4. Click on System assign option and enable/ON it. (system assigned managed identity).
( once it is registered, can be granted permissions to access resources protected by Azure AD).
5. Now the Azure Webapps can able to retrieve secrets from the Azure Keyvaults.
2. Select the option Identity
3. There are two kinds of Identity : 1) System assign and 2) User assign
4. Click on System assign option and enable/ON it. (system assigned managed identity).
( once it is registered, can be granted permissions to access resources protected by Azure AD).
5. Now the Azure Webapps can able to retrieve secrets from the Azure Keyvaults.
what is feature flag ? and an example in Azure DevOps services
Feature Flag : A feature flag is also known as a feature toggle, feature switch, feature flipper or conditional feature. They were popularized by Martin Fowler. Feature flags support a customer-first DevOps mindset, to enable ( expose ) and disable (hide) features in a solution, even before they are complete and ready for release.
Feature Flag Feature in Azure DevOps --------> is called as Preview features.
This Preview feature has enable and disable option. ( This is from Azure DevOps Services).
Feature Flag Feature in Azure DevOps --------> is called as Preview features.
This Preview feature has enable and disable option. ( This is from Azure DevOps Services).
Purely a customer choice whether to use the feature or not.
Merge types in the Source Code Management ( few merge types in the Azure DevOps services ).
There are four types of the merge types:
1. Merge ( no fast forward ) : Non-linear history preserving all commits.
2. Squash merge ( commit ) : Linear history with only a single commit on the target.
3. Rebase and fast-forward : Rebase source commits onto target and fast-forward.
4. Semi-linear merge : Rebase source commits onto targets and create a two-parent merge.
1. Merge ( no fast forward ) : Non-linear history preserving all commits.
2. Squash merge ( commit ) : Linear history with only a single commit on the target.
3. Rebase and fast-forward : Rebase source commits onto target and fast-forward.
4. Semi-linear merge : Rebase source commits onto targets and create a two-parent merge.
what are the kinds of webapp in the azure cloud services ?
There are four kinds of webapps: ( Important while learning Az300 ).
1. Azure Function Apps ( this is a kind of webapp, Example: Trigger function ( serverless architecture, this is similar like AWS lambda function ).
2. Azure Webapp ( this is a kind of webapp, Example: host your app to the outside world ).
3. Azure Logicapp ( this is a kind of webapp, Example: logic based, Send Email / Mobile notifications ).
4. Event Grid ( topics ) ( this is a kind of webapp, Example: contain events, events may be created P1,P2,P3 priority based ( basic flow : Priority > ticket > assigned to particular app ).
The below procedure is same for every webapp:
>>>>>>
Example:
Azure Functions :
What is Serverless Architecture and a good example for that ?
> Go to Azure function app, and
1. Search for functionapp and Create a function app.
2. Created with the access URL : https://abc.azurewebsites.net
3. simple way to identify whether it is a webapp or not , using this https://*.azurewebsites.net (if it has the azurewebsites in it is a webapp).
4. every function app can be a part of the Azure App service plan.
Example:
abcfunctionapp to upgrade the functions automatically whenever new code is committed to the master branch.
how to do that ?
1. Create a functionapp named abcfunctionapp.
2. Click on the abcfunctionapp and select the Deployment center and integrate the sourcecode repository ( git, azure repos ).
3. Application ( Dockerfile path, port and Docker build context ).
4. Resources.
1. Azure Function Apps ( this is a kind of webapp, Example: Trigger function ( serverless architecture, this is similar like AWS lambda function ).
2. Azure Webapp ( this is a kind of webapp, Example: host your app to the outside world ).
3. Azure Logicapp ( this is a kind of webapp, Example: logic based, Send Email / Mobile notifications ).
4. Event Grid ( topics ) ( this is a kind of webapp, Example: contain events, events may be created P1,P2,P3 priority based ( basic flow : Priority > ticket > assigned to particular app ).
The below procedure is same for every webapp:
>>>>>>
Example:
Azure Functions :
What is Serverless Architecture and a good example for that ?
> Go to Azure function app, and
1. Search for functionapp and Create a function app.
2. Created with the access URL : https://abc.azurewebsites.net
3. simple way to identify whether it is a webapp or not , using this https://*.azurewebsites.net (if it has the azurewebsites in it is a webapp).
4. every function app can be a part of the Azure App service plan.
Example:
abcfunctionapp to upgrade the functions automatically whenever new code is committed to the master branch.
how to do that ?
1. Create a functionapp named abcfunctionapp.
2. Click on the abcfunctionapp and select the Deployment center and integrate the sourcecode repository ( git, azure repos ).
3. Application ( Dockerfile path, port and Docker build context ).
4. Resources.
Friday, April 17, 2020
linux-based containers
The Azure pipelines systems requires a few things in linux-based containers:
Bash
glibc-based
can run Node.js ( which the agent provides )
Does not define an ENTRYPOINT
Bash
glibc-based
can run Node.js ( which the agent provides )
Does not define an ENTRYPOINT
Azure DevOps Test Plans
Azure Test Plans or the Test hub in TFS provides three main types of test management artifact: test plans, test suites and test cases. These are stored in your work repository as special type of work items, allowing you to export and share them with your team, and benefit from close integration for all of your DevOps tasks.
Test plans are used to group together test suites and individual test cases. This includes static test suites, requirement-based suites and query-based suites.
Test suites are used to group test cases into separate testing scenarios within a single test plan.This makes it easier to see which scenarios are complete.
Test cases are used to validate individual parts of your code or app deployment to ensure it performs correctly, has no errors, and meets business and customer requirements. You can add individual test cases to a test plan without creating a test suite if you wish. Test cases can be referenced in more than one test suite and test plan, meaning you can effectively reuse them without needing to opy or clone them for each suite or plan.
Test plans are used to group together test suites and individual test cases. This includes static test suites, requirement-based suites and query-based suites.
Test suites are used to group test cases into separate testing scenarios within a single test plan.This makes it easier to see which scenarios are complete.
Test cases are used to validate individual parts of your code or app deployment to ensure it performs correctly, has no errors, and meets business and customer requirements. You can add individual test cases to a test plan without creating a test suite if you wish. Test cases can be referenced in more than one test suite and test plan, meaning you can effectively reuse them without needing to opy or clone them for each suite or plan.
Thursday, April 16, 2020
what is squash merge ?
Square merging is a merge option that allows you to condense the Git history of topic branches when you complete a pull request. Instead of each commit on the topic branch being added to the history of the default branch, a square merge takes all the file changes and adds them to a single new commit on the default branch.
A simple way to think about this is that squash merge gives you just the file changes, and a regular merge gives you the file changes and the commit history.
Note:
Squash merging keeps your default branch histories clean and easy to follow without demanding any workflow changes on your team. Contributors to the topic branch work how they want in the topic branch, and the default branches keep a linear history through the use of squash merges. The commit history of a master branch updated with squash merges will have one commit for each merged branch. You can step through this history commit by commit to find out exactly when work was done.
References:
https://docs.microsoft.com/en-us/azure/devops/repos/git/merging-with-squash
A simple way to think about this is that squash merge gives you just the file changes, and a regular merge gives you the file changes and the commit history.
Note:
Squash merging keeps your default branch histories clean and easy to follow without demanding any workflow changes on your team. Contributors to the topic branch work how they want in the topic branch, and the default branches keep a linear history through the use of squash merges. The commit history of a master branch updated with squash merges will have one commit for each merged branch. You can step through this history commit by commit to find out exactly when work was done.
References:
https://docs.microsoft.com/en-us/azure/devops/repos/git/merging-with-squash
What is Continuous Assurance for the Project ?
Implementation Continuous Assurance for the project:
The basic idea behind Continuous Assurance ( CA ) is to setup the ability to check for "drift" from what is considered a secure snapshot of a system. Support for Continuous Assurance lets us treat security truly as a 'state' as opposed to a 'point in time' achievement. This is particularly important in todays context when 'continuous change' has become a norm.
There can be two types of drift:
Drift involving 'baseline' configuration: This involves settings that have a fixed number of possible states ( often predefined/statically determined ones ). For instance, a SQL DB can have TDE encryption turned ON or OFF or a storage account may have auditing turned ON however the log retention period may be less than 365 days.
Drift involving 'stateful' configuration: There are settings which cannot be constrained within a finite set of well-known states. For instance, the IP addresses configured configured to have access to a SQL DB can be any ( arbitrary ) set of IP addresses. In such scenarios, usually human judgement is intially required to determined whether a particular configuration should be considered 'secure' or not. However, once that is done, it is important to ensure that there is no "stateful drift" from the attested configuration. ( E.g. if in a troubleshooting session, someone adds the IP address of a developer machines to the list, the Continuous Assurance feature should be able to identify the drift and generate notifications/alerts or even trigger 'auto-remediation' depending on the severity of the change ).
Reference :
https://azsk.azurewebsites.net/04-Continous-Assurance/Readme.html
The basic idea behind Continuous Assurance ( CA ) is to setup the ability to check for "drift" from what is considered a secure snapshot of a system. Support for Continuous Assurance lets us treat security truly as a 'state' as opposed to a 'point in time' achievement. This is particularly important in todays context when 'continuous change' has become a norm.
There can be two types of drift:
Drift involving 'baseline' configuration: This involves settings that have a fixed number of possible states ( often predefined/statically determined ones ). For instance, a SQL DB can have TDE encryption turned ON or OFF or a storage account may have auditing turned ON however the log retention period may be less than 365 days.
Drift involving 'stateful' configuration: There are settings which cannot be constrained within a finite set of well-known states. For instance, the IP addresses configured configured to have access to a SQL DB can be any ( arbitrary ) set of IP addresses. In such scenarios, usually human judgement is intially required to determined whether a particular configuration should be considered 'secure' or not. However, once that is done, it is important to ensure that there is no "stateful drift" from the attested configuration. ( E.g. if in a troubleshooting session, someone adds the IP address of a developer machines to the list, the Continuous Assurance feature should be able to identify the drift and generate notifications/alerts or even trigger 'auto-remediation' depending on the severity of the change ).
Reference :
https://azsk.azurewebsites.net/04-Continous-Assurance/Readme.html
Sunday, April 12, 2020
Deployment Patterns very useful in Azure DevOps certification
Traditional approach:
Blue-green deployment pattern
In Azure, creating the Traffic Manager profiles in Azure Traffic loadbalancer and link the endpoints ( Blue, Green ).
Modern approaches :
1. Canary deployment pattern :
Canary release: It comes from the mining industry and in coal mines, miners used to take the canary cage down, it is very sensitive to the toxic gases it could be down the mines and a portion of it would die before the human.
The miners will see this, they will understand there are in trouble.
Blue-green deployment pattern
In Azure, creating the Traffic Manager profiles in Azure Traffic loadbalancer and link the endpoints ( Blue, Green ).
Modern approaches :
1. Canary deployment pattern :
Canary release: It comes from the mining industry and in coal mines, miners used to take the canary cage down, it is very sensitive to the toxic gases it could be down the mines and a portion of it would die before the human.
The miners will see this, they will understand there are in trouble.
[ A canary release is a way to identify potential problems as soon as possible without exposing all of your end users to the issue ].
Examples on Canary in coal mines :
Examples on Canary in coal mines :
The concept in IT : It is new feature or functionality in the application infront of a small number of ppl, if you find issues with it, we can find out early with the lowest impact.
In this methodology we have three main user types :
1. Canaries : Users that voluntarily test bleeding edge features as soon as they are available.
2.Early adopters: Users that voluntarily preview releases that are considered more refined than canary releases.
3. Users: Consume the products after they pass through the canaries and early adopters.
2.Progressive Exposure Deployments: Progressive Exposure Deployments also called Ring-based deployment was first discussed in Jez Humbles book "continuous delivery".
They support the production-first DevOps mindset and limit the impact on end users, while deploying and validating changes in production. Impact ( also called the blast radius ) , is evaluated through observation, testing, analysis of telemetry, and user feedback.
Rings are, in essence, an extension of the canary stage. The canary release releases to a stage to measure the impact. Adding another ring is essentially the same thing.
Scale a Release pipeline to Deploy to Multiple Endpoints.
3. Deploy to Multiple Endpoints and Environments
Deployment Group : is a logical set of deployment target machines that have agents installed on each one. They can represent normal environments ( Dev, QA, TEST , PROD ). A deployment group is another grouping of agents, much like an agent pool.
A Good Examples on DSC ( Desired State Configuration )
Very useful resources for the Azure DevOps,
This is just an example,
https://docs.microsoft.com/en-us/archive/blogs/ashleymcglone/use-the-new-powershell-cmdlet-convert-string-to-parse-email-addresses
This is just an example,
https://docs.microsoft.com/en-us/archive/blogs/ashleymcglone/use-the-new-powershell-cmdlet-convert-string-to-parse-email-addresses
Sunday, April 5, 2020
Azure Boards a small part of Azure Devops platform
Consider Agile is the father of Scrum, similarly it appiles for all other methodologies.
Similarly, these are the methodology projects under the waterfall model. Consider Waterfall model is the father of the CMMI
What is Green field means ?
Green field ( Plain green grass ) ( yet to be started the project from scratch ) -Agile Methodology.
What is Brown field means ?
Brown field ( project is long running ) - Water fall Methodology
Fundamentals for the Azure Devops exam. These key points will be helpful for the quick glance during the exam.
Subscribe to:
Posts (Atom)