We would like to move a bitnami vm to the Elastic cloud offering on Azure.
We've created an instance in a resource group - And as the owner I can login and start managing this cluster.
Now I would like to invite other people to this cluster. We don't have the organization option in the Settings (elastic docs: Organizations are currently not supported for Azure Marketplace accounts.).
Therefore I added a user in "Stack Management > Security > Users", but that user can't login, can't reset a password, ...
Am I wrong by adding Users in the Stack Management, can we manage this in Azure AD?
Thanks!
Related
I'm currently using AWS IAM to provision access to the AWS resources for the users. Recently I created an AWS Organization to separate the Dev & Prod environments. While doing this I supposed to create another IAM user for all users for the Dev AWS Organization Account. so there is 2 IAM user for every user so that all users can access the resources in both Dev & Prod environments. (Yes, its conditional access, not all AWS resources is provisioned).
We started to implement AWS SSO using SAML & came to know about the IAM Identity Center, using which a single user can access resources in both the AWS accounts (Organizations) with a single username itself which is good.
I've some queries regarding the AWS SSO,
Question 1
AWS SSO requires AWS Organization to be enabled by default with an message. What does this means? Once AWS SSO is enabled I can't create new additional/sub organizations?
After you create an organization, you cannot join this account to
another organization until you delete its current organization
Question 2
Once I setup AWS Organization & AWS SSO and changed the identity source it syncs the groups & users to the AWS root account using which we can provision the resources. Will it remove/delete the existing IAM user & role?
If NO, can I still be able to login with the IAM username & password other than this AWS SSO?
Question 3
While I change the identity source using the AWS SSO it warns that the MFA configurations will be deleted. Will it delete the MFA for the root account and the IAM users? or Just the users inside the AWS SSO?
IAM Identity Center will delete your current multi-factor authentication (MFA) configuration.
Question 4
Why I can't setup the AWS SSO from an organization account? Is there any specific reason?
Final Question
Did I understood the AWS SSO (IAM Identity Center) Properly?
We've been told by Microsoft support that Azure DevOps Services supports tenant restrictions. While we have tenant restrictions enabled on a number of other services, it does't seem to apply to DevOps. Not only can we still log in to organizations outside of our tenant, we can also log in to our own organization and, if our corp email is added as a user in that org, the organization also shows up. I'd expect that our users would be blocked from logging into or accessing any external orgs.
I'm a little confused about why this isn't just working as expected and despite them saying Azure DevOps Services supports tenant restrictions, I'm not finding much documentation to back that up.
Have you been able to migrate to Azure DevOps Services and ensure that your users are only able to access orgs within your own tenant? How?
Azure DevOps Service supports the Azure Active Directory (Azure AD) tenant policy to restrict users from creating an organization in Azure DevOps. This policy is turned off, by default. You must be an Azure DevOps Administrator in Azure AD to manage this policy.
Check following link for more details:
https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/azure-ad-tenant-policy-restrict-org-creation?view=azure-devops
Notice:
This policy is supported only for company owned (Azure Active
Directory) organizations. Users creating organization using their
personal account (MSA or GitHub) have no restrictions.
https://devblogs.microsoft.com/devops/policy-support-to-restrict-creating-new-azure-devops-organizations/
We finally received a more concrete answer to this question from Premier Support. Sounds like this wasn't entirely clear internally either. Azure DevOps Services supports TRv1 which provides tenant restrictions from client to proxy, but does not support TRv2 tenant restrictions which provides server to server restrictions. TRv1 will prevent you from authenticating against an org outside your tenant directly but does nothing to prevent the background authentication that happens if your account is configured to be able to access a secondary tenant's org. The server to server connection strips off the header information necessary to restrict you from accessing the secondary tenant. While this feature may be on their radar there is no expectation or firm timeline for it's release at this time.
I'm following the instructions on how to connect from GKE to Cloud SQL: https://cloud.google.com/sql/docs/postgres/connect-kubernetes-engine
It talks about YOUR-GSA-NAME. Google cloud creates "Compute Engine default service account" by default. Should I pick this one or create another service account for GKE only? What is the recommended way?
The Compute Engine default service account won't be able to connect to Cloud SQL out of the box, you'll have to add permissions to it (Cloud SQL Client role) for it to be able to connect.
I would create a new one however, as you likely don't want all GCE instances to be able to connect to Cloud SQL, and for permissions, best practice is to limit access. So just create a new SA (service account) with the Cloud SQL Client role (and any other permissions you might need GKE to access) and use that one.
This is all found in IAM -> Service Accounts in the console.
I have created a space and a BigInsight cluster on Bluemix. In order to test Knox, I need multiple users for authentication. Is it possible to create users in Bluemix Biginsight service? The ID that is provided to access the cluster does not have root access. Also, it would be helpful if someone can explain in detail how the admin-related task(adding more components like Hue,Drill using yum commands) could be performed in Bluemix Biginsights service. Thanks in advance.
I am guessing here that you have created a Bluemix Biginsights Basic (Beta) plan.
This service is a single user service and cannot have multiple users.
In addition this service is a managed service and installation of software by the user is not allowed.
This service comes with preconfigured settings and pre-installed softwares that is fixed. If you do need something apart from this, I would suggest to open a Biginsights service ticket through Bluemix Support page with a request for it and why you need the software.
The product management team will look at it and see if they can be preinstalled in the future release.
These installations will not be done on a any Basic (Beta) plan for individual clusters.
I would like to find out what the best practices are for managing developers' access to a sub-set of resources on a client's subscription?
I've searched Google and the Azure documentation looking for definitive answers, but I have yet to come across an article that puts it all together. Because Azure is still developing so rapidly I often find it difficult to determine whether a particular article may still be relevant.
To sum up our situation:
I've been tasked with researching and implementing the Azure infrastructure for a web site our company is developing for a client. At the moment our manager and I have access to the client's entire subscription on the Azure Portal by means of the Service Administrator's credentials, even though we're managing only:
Azure Cloud Service running a Web-Role (2-instances with Production and Staging environments).
Azure SQL Database.
Azure Blob Storage for deployments, diagnostics etc.
We're now moving into a phase where more of the developers in the team will require access to perform maintenance type tasks such as performing a VIP swap, retrieving diagnostic info etc.
What is the proper way to manage developer's access on such a project?
The approach I've taken was to implement Role Based Access Control (https://azure.microsoft.com/en-us/documentation/articles/role-based-access-control-configure/)
Move 1, 2, and 3 above into a new Resource Group according to http://blog.kloud.com.au/2015/03/24/moving-resources-between-azure-resource-groups/
Creating a new User Group for our company, say "GroupXYZ".
Adding the "GroupXYZ" to the Contributor role.
Adding the particular developer's company accounts to "GroupXYZ"
Motivation for taking the role-based approach
From what I understand giving everyone access as a Co-Administrator would mean that they have full access to every subscription in the portal.
Account-based authentication is preferable to certificate-based authentication due to the complexity added by managing the certificates.
What caused me to question my approach was the fact that I could not perform a VIP swap against the Cloud Service using PowerShell; I received an error message stating that a certificate could not be found.
Do such role-based accounts only have access to Azure by means of the Resource Manager Commandlets?
I had to switch PowerShell to the Azure Service Manager (ASM) Mode before having access to the Move-AzureDeployment commandlet.
Something else I'm not sure of is whether or not Visual Studio will have access to those resources (in the Resource Group) when using Role Based Access Control.
When you apply RBAC to Azure as you have or just in general, give access to an account via RBAC, then those accounts can only access Azure via the Azure Resource Manager APIs, whether that's PowerShell, REST or VS.
VS 2015 can access Azure resources via RBAC when using the 2.7 SDK. VS 2013 will have support for it soon.