I am confused by tenant in openstack and swift.
I have multiple machines on C3 under tenant called myTenant. Here tenant is the same with project. I cannot understand what do tenant and project mean here.
I also have a swift container, which I can access by tenantID and username, password and storageUrl. what are the differences between tenant here and myTenant mentioned above.
I used swift stat -v <containerName> and got the Account of the container is KEY_<tenantId>. here what is the difference between tenant, user and Account?
The storageUrl looks like http://ip/KEY_<tenantId>, which is the endpoint of one container. So, tenantId is limited to only one container here?
Thanks. Any hints welcomed.
For historical reasons (and the fact that it is impossible to retrospectively fix N years of legacy documentation, blogs, Q&A sites and other web-searchable stuff), some of the OpenStack terminology is a bit confusing.
The terms "tenant" and "project" mean the same thing; see this Q&A on the "Ask OpenStack" site:
https://ask.openstack.org/en/question/84073/tenant-vs-project/
The term "tenant" is being phased out ... slowly.
So to answer your questions:
I have multiple machines on C3 under tenant called myTenant. Here tenant is the same with project. I cannot understand what do tenant and project mean here.
See above.
I also have a swift container, which I can access by tenantID and username, password and storageUrl. what are the differences between tenant here and myTenant mentioned above.
A "tenant" (or "project") has a name and an ID. Your "myTenant" is a project name. The tenant ID or project ID is a long unique identifier. You can lookup the ID for a project using the openstack command; e.g. openstack project show myTenant.
I used swift stat -v <containerName> and got the Account of the container is KEY_<tenantId>. here what is the difference between tenant, user and Account?
A "tenant" or "project" in Keystone corresponds to an "account" in Swift. A "user" in Keystone corresponds to a "user" in Swift.
(Strictly speaking the concepts are not identical. It is possible to run Swift with TempAuth middleware which gets identity information from local configs rather than from a Keystone service. But that approach is designed for stand-alone testing, not production.)
Related
I want to use the Azure Resource Graph API to get the role assignments of a resource (who are owners, contributors, etc.). That is, I want to create a query that finds the role assignments for a specific resource id that I provide. I've been going through the documentation, but I haven't found any way to get this information.
The only thing I found was this question from a couple of years ago, where it is mentioned as something that could be done somehow ("query the RBAC of each one of those resources").
Could anyone point me to how this could be done? Or is it not possible to do in Resource Graph API, and I need to use the Management API or something else?
I searched through the Azure Resource Graph table and resource type reference and the Advanced Resource Graph query samples, but didn't find an answer
I tried to reproduce the same in my environment and got the results like below:
I created Azure AD Application and added API permissions:
I generated an access token by using below parameters:
https://login.microsoftonline.com/TenantID/oauth2/v2.0/token
client_id:xxxxxx-xxx-xxx-xxxx-xxxxxxxx
client_secret:ClientSecret
scope:https://management.azure.com//.default
grant_type:client_credentials
To list the Role assignments in the subscription scope, I used the below query:
GET https://management.azure.com/subscriptions/subscriptionId/providers/Microsoft.Authorization/roleAssignments?api-version=2022-04-01
Based on your requirement you can change the scope and add the filter to get the role assignments. Refer the below MsDoc:
List Azure role assignments using the REST API - Azure RBAC
Currently it is not feasible to retrieve the role assignments via Azure Resource Graph. Alternatively, you can make use of Azure PowerShell or Azure CLI.
Get-AzRoleAssignment -Scope "/subscriptions/SubscriptionId/resourcegroups/RGName/providers/Providername/ResourceType/Resource"
How to add Azure custom Policy for Azure Data Factory to only use Azure Key Vault during the Linked Service Creation for fetching the Data Store Credentials instead of credentials being put up directly in ADF Linked Service. Please suggest ARM or PowerShell methods for the policy implementation.
As of yesterday, the Data Factory Azure Policy integration is available which means you can now find some built-in policies that can be assigned to ADF.
One of those is exactly what you're asking for as you can see in the image below. You can find more information here
Edit: Based on your comment, I'm editing this answer with the info you want. When it comes to custom policies, it's pretty much up to you to come up with them and create what fits your needs. In your particular case, I've created one policy that does what you want, please see here.
This policy will audit your data factory linked services and check if they're using a self-hosted integration runtime. Currently, that check is only done for a few types of integration runtimes (if you look at the policy, you can see 5 of them) which means that if you want to check more types of linked services, you'll need to add them to the list of allowed values and select them when assigning the policy definition.
Bear in mind that for some linked services types, such as Key Vault, that check won't make sense since that service can't use a self-hosted IR
I'm using Microsoft Graph SDK for .NET Core. I'm trying to get a list of all Office 365 plans in all Azure Active Directory groups within my organization.
I have been reading through a lot of questions, but haven't found a clear answer to my problem: As it's stated in the official documentation, you cannot list plans in a group using client credentials (application permissions), which is the exact authentication method I'm using. Given this, how can I achieve my objective?
As per documentation, the only way to list plans in groups is to use Delegated Permissions, but in that case, and according to the Microsoft Graph permissions:
either the user or an administrator consents to the permissions that the app requests and the app can act as the signed-in user when making calls to Microsoft Graph.
If the signed-in user is a regular user then the application will only access the groups that user is a member of. Bear in mind that there may not be a single user that is a member of all groups.
Is there a way to get my application to list all plans in all groups within my organization?
You can now use application permissions.
Outdated Reply:
Planner currently does not support application permissions. Depending
on what your scenario is, you have couple of options. One option is to
create a user account to be used by your app, and add that user to all
the groups. Then you'll be able to query the plans with the
credentials of that user.
I am trying stream data from the AWS API Gateway to DynamoDB in AWS (directly, without something like lambda). I have looked for several tutorials, such as [1] and [2], who describe exactly this scenario. All of these assume that the right policies and roles are in place. Normally, I play and hack around till I get a working proof of concept, after which I rebuild a proper model, but with access rights I want to make sure I understand what I am doing. For [2], I also found a stack overflow question at [3] from somebody with the same problem that got solved, but not sure exactly how. I also looked at [4], describing API Gateway with Lambda.
Here is my guess:
Create a policy that allows calling from the API Gateway.
"AmazonAPIGatewayInvokeFullAccess" fits the name, but might not
be necessary + overkill with too much access
Create a policy that allows access to dynamoDB.
Here, "AmazonDynamoDBFullAccess" might be appropriate, even
though it might be overkill (too much access), and might only work
from the Management Console
Create a role that has those two policies attached.
Here, I run into the trouble that when I click create role, and
select AWS service, I can not find the correct "service that will use
this role" that has the policies I described above behind it. For
example, when clicking dynamoDB, I get the following "use-cases", none of which seem to relate to the dynamoDB full access policy:
Amazon DynamoDB Accelerator (DAX) - DynamoDB access
DynamoDB - Global Tables
DynamoDB Accelerator (DAX) - Cluster management
My main question is: How do I set the right minimal set of roles and policies to connect AWS API Gateway to DynamoDB (read and write), as described in [1]?
[1] https://sanderknape.com/2017/10/creating-a-serverless-api-using-aws-api-gateway-and-dynamodb/
[2] https://aws.amazon.com/blogs/compute/using-amazon-api-gateway-as-a-proxy-for-dynamodb/
[3] API Gateway does not have permission to assume the provided role DynamoDB
[4] https://docs.aws.amazon.com/apigateway/latest/developerguide/permissions.html
What you need to do is create an IAM Service Role that allows API Gateway to assume this role. You can easily do this through the UI. When you create a new role, the "Service Role" is selected by default and below the "Choose the service that will use this role" header, you can select API Gateway.
A role is a container of permissions that can be assumed by a certain entity (in our case, an API Gateway API resource). Your role needs "permissions" for the role to have any use. You add this permissions by adding policies to your role. This is explained more in depth here: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html
Be sure to read the AWS Service Role part. You say that you need to "Create a policy that allows calling from the API Gateway" but this is incorrect: you need to create a role that can be assumed by API Gateway.
In your case, you'll want specific DynamoDB permissions for your role. Following the least-privilege principle as you mention, you should only add the specific actions for the specific DynamoDB table. The list of possible permissions can be found here: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/api-permissions-reference.html
Let's say you only want API Gateway to get items from a specific table. Your policy might look something like this then:
{
"Effect": "Allow",
"Action": "dynamodb:GetItem",
"Resource": "arn:aws:dynamodb:eu-west-1:[aws_account_id]:table/[table_name]"
}
Hope this helps!
This recent new tutorial by ankana likhita sri priya includes starting off in high detail/screenshots of IAM (Policy, Role, etc.): https://medium.com/#likhita507/using-api-gateway-to-get-data-from-dynamo-db-using-without-using-aws-lambda-e51434a4f5a0
All,
OpenStack API issues token after successful authentication. However, it is only valid for 1 hour.
Is there any workaround or possibility to extend token's lifespan?
Thanks & Regards,
Ganesh.
You may want to take a look at the solutions used by Heat, the OpenStack orchestration engine.
Heat needs to be able to execute actions on behalf of a user at some point in the future. Heat cannot simply store a token because, as you have stated, tokens expire.
Heat offers two solutions to "deferred authentication".
Keystone Trusts
Stored passwords
There are lots of details about how Heat handles this here and here.
There are some API examples of keystone trusts on the eNovance blog, and some more over here.