​AOL, Yahoo, and Verizon (using the same email server) are now requiring that SPF, DKIM, and DMARC be enabled for emails sent to those addresses. I saw a report that Google will soon require this too. My problem is that to enable DKIM, I have to create 2 CNAME records. I have created these records on 4 accounts on 4 different providers. I have another account that actually works, but DKIM was enabled even without the CNAMES. I also passed the DMARC check on that account, so I know that I have managed to put in the correct entries in the CNAME records. But, I still get the error message about needing the CNAME records before enabling DKIM. Another curiosity is that on none of my accounts can I detect CNAME records, even CNAMEs that were already there? What do I have to do to enable DKIM on these accounts (a total of 6 accounts on 4 different hosts)?  Read More

​

Hello, 

We have been trying for many months now to publish our PowerApps canvas apps as a SaaS offer, thereby allowing us to have transactable, licensed customers. 

Through a lot of effort, we managed to get some support where we were told quite vaguely how to achieve this, but without any meaningful guidance we are struggling as we are a small ISV with expertise in our actual business, and Power Platform. We are not, however, experts in SQL (that’s being generous) or in creating APIs which seem to be a requirement to keep track of user licenses and feeding the data to our canvas app. 

If anyone here has any info on this, or how they might have achieved it themselves it would be massively appreciated, as we can’t seem to get there by ourselves and MS support is very difficult to find. 

It does feel as though the app development part is so much simpler than getting it onto the marketplace, which is surely the wrong way round. 

Thank you,

Craig 

​Hello, We have been trying for many months now to publish our PowerApps canvas apps as a SaaS offer, thereby allowing us to have transactable, licensed customers.  Through a lot of effort, we managed to get some support where we were told quite vaguely how to achieve this, but without any meaningful guidance we are struggling as we are a small ISV with expertise in our actual business, and Power Platform. We are not, however, experts in SQL (that’s being generous) or in creating APIs which seem to be a requirement to keep track of user licenses and feeding the data to our canvas app.  If anyone here has any info on this, or how they might have achieved it themselves it would be massively appreciated, as we can’t seem to get there by ourselves and MS support is very difficult to find.  It does feel as though the app development part is so much simpler than getting it onto the marketplace, which is surely the wrong way round.  Thank you,Craig   Read More

​

Hello everyone!

I just won a PRO ticket for the Paris RAISE Summit 2024.
The ticket price on the official website is €799, and I want to sell it for half price.
Can you please help me with where I can sell it, or maybe someone from here wants to buy it?

​Hello everyone!I just won a PRO ticket for the Paris RAISE Summit 2024.The ticket price on the official website is €799, and I want to sell it for half price.Can you please help me with where I can sell it, or maybe someone from here wants to buy it?  Read More

​

Welcome to the third installment of this series simplifying azure Kubernetes service authentication. Part two is here Part 2  .In this third part we’ll continue from where we left off and set up cert manager, create a CA issuer, upgrade our ingress routes, register our app, and create secrets and a cookie for authentication. You can also refer to the official documentation here for some of the steps TLS with an ingress controller.

Install cert-manager Let’s Encrypt

In the previous post we uploaded cert manager images to our ACR. Now lets install the cert manager images by running the following:

# Set variable for ACR location to use for pulling images
$AcrUrl = (Get-AzContainerRegistry -ResourceGroupName $ResourceGroup -Name $RegistryName).LoginServer

# Label the ingress-basic namespace to disable resource validation
kubectl label namespace ingress-basic cert-manager.io/disable-validation=true

# Add the Jetstack Helm repository
helm repo add jetstack https://charts.jetstack.io

# Update your local Helm chart repository cache
helm repo update

# Install the cert-manager Helm chart
helm install cert-manager jetstack/cert-manager –namespace ingress-basic –version $CertManagerTag –set installCRDs=true –set nodeSelector.”kubernetes.io/os”=linux –set image.repository=”${AcrUrl}/${CertManagerImageController}” –set image.tag=$CertManagerTag –set webhook.image.repository=”${AcrUrl}/${CertManagerImageWebhook}” –set webhook.image.tag=$CertManagerTag –set cainjector.image.repository=”${AcrUrl}/${CertManagerImageCaInjector}” –set cainjector.image.tag=$CertManagerTag

You should get some output and make sure the READY column is set to True.

Create a CA Issuer

A certificate authority (CA) validates the identities of entities (such as websites, email addresses, companies, or individual persons) and binds them to cryptographic keys through the issuance of digital certificates. We are using the letsencrypt CA. We can create a CA by applying a ClusterIssuer to our ingress-basic namespace. Create the following cluster-issuer.yaml file:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
email: MY_EMAIL_ADDRESS
privateKeySecretRef:
name: letsencrypt
solvers:
– http01:
ingress:
class: nginx
podTemplate:
spec:
nodeSelector:
“kubernetes.io/os”: linux

Now apply this yaml file by running the following kubectl command:

kubectl apply -f cluster-issuer.yaml –namespace ingress-basic

Update your ingress route

In the previous part of this series we created a FQDN which enabled us to route to our apps in the web browser via a URL. We need to update our ingress routes to handle this change. Update the hello-world-ingress.yaml as follows:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: hello-world-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /$2
nginx.ingress.kubernetes.io/use-regex: “true”
cert-manager.io/cluster-issuer: letsencrypt
spec:
ingressClassName: nginx
tls:
– hosts:
– hello-world-ingress.MY_CUSTOM_DOMAIN
secretName: tls-secret
rules:
– host: hello-world-ingress.MY_CUSTOM_DOMAIN
http:
paths:
– path: /hello-world-one(/|$)(.*)
pathType: Prefix
backend:
service:
name: aks-helloworld-one
port:
number: 80
– path: /hello-world-two(/|$)(.*)
pathType: Prefix
backend:
service:
name: aks-helloworld-two
port:
number: 80
– path: /(.*)
pathType: Prefix
backend:
service:
name: aks-helloworld-one
port:
number: 80
—
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: hello-world-ingress-static
annotations:
nginx.ingress.kubernetes.io/ssl-redirect: “false”
nginx.ingress.kubernetes.io/rewrite-target: /static/$2
spec:
ingressClassName: nginx
tls:
– hosts:
– hello-world-ingress.MY_CUSTOM_DOMAIN
secretName: tls-secret
rules:
– host: hello-world-ingress.MY_CUSTOM_DOMAIN
http:
paths:
– path: /static(/|$)(.*)
pathType: Prefix
backend:
service:
name: aks-helloworld-one
port:
number: 80

Then apply the update:

kubectl apply -f hello-world-ingress.yaml –namespace ingress-basic

You should get some output and make sure the READY column is set to True.

Register your app in Entra ID and create a client secret

An Azure Active Directory (AAD) App referred to as Entra ID now, is an application registered in Entra ID, which allows it to interact with Azure services and authenticate users. We can then use the Entra ID App to obtain a client secret for authentication purposes. Perform the following actions to register an app and create a client secret.

In the Azure portal search for Microsoft Entra ID
Click App registrations in the left side navigation
Click new registration button
Add a name and enter your redirect URL (Web) https://FQDN/oauth2/callback
Register and take note of your Application (client) ID
Click Certificates and Secrets and click New client secret and take note of the Secret Value

Create a cookie secret and set Kubernetes secrets

Now register the following client-id, client-secret, and cookie secret. Remember this series is for educational purposes and thus may not meet all security requirements. If you need to store your secrets in a more secure location you can also refer to how to use Key Vault to do so here Key Vault. Run the following commands in PowerShell:

$cookie_secret=“$(openssl rand -hex 16)”

# or with python
python -c ‘import os,base64; print(base64.urlsafe_b64encode(os.urandom(32)).decode())’

kubectl create secret generic client-id –from-literal=oauth2_proxy_client_id=<APPID> -n ingress-basic
kubectl create secret generic client-secret –from-literal=oauth2_proxy_client_secret=<SECRETVALUE> -n ingress-basic
kubectl create secret generic cookie-secret –from-literal=oauth2_proxy_cookie_secret=<COOKIESECRET> -n ingress-basic

Create a Redis Password

 Azure uses large cookies when authenticating over Oauth2, thus it is recommended to setup Redis to handle these large cookies. For now we will create a Redis password and set the Kubernetes secret. In the next post we will install and setup Redis. Run the following command in PowerShell:

$REDIS_PASSWORD=“<YOUR_PASSWORD>”
kubectl create secret generic redis-password –from-literal=redis-password=$REDIS_PASSWORD -n ingress-basic

This ends the third post in our series. Look out for the fourth and final post.

​Microsoft Tech Community – Latest Blogs –Read More